Connection-less Lightweight X.500 Directory Access Protocol
RFC 1798
| Document | Type |
RFC - Historic
(June 1995; No errata)
Obsoleted by RFC 3352
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 1798 (Historic) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Patrik Fältström | ||
| Send notices to | <lmm@acm.org>, <montulli@netscape.com>, <koen.holtman@cern.ch>, <andy_mutz@hp.com> | ||
Network Working Group A. Young
Request for Comments: 1798 ISODE Consortium
Category: Standards Track June 1995
Connection-less Lightweight X.500 Directory Access Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
X.500
The protocol described in this document is designed to provide access
to the Directory while not incurring the resource requirements of the
Directory Access Protocol (DAP) [3]. In particular, it is aimed at
avoiding the elapsed time that is associated with connection-oriented
communication and it facilitates use of the Directory in a manner
analagous to the DNS [5,6]. It is specifically targeted at simple
lookup applications that require to read a small number of attribute
values from a single entry. It is intended to be a complement to DAP
and LDAP [4]. The protocol specification draws heavily on that of
LDAP.
1. Background
The Directory can be used as a repository for many kinds of
information. The full power of DAP is unnecessary for applications
that require simple read access to a few attribute values.
Applications addressing is a good example of this type of use where
an application entity needs to determine the Presentation Address
(PA) of a peer entity given that peer's Application Entity Title
(AET). If the AET is a Directory Name (DN) then the required result
can be obtained from the PA attribute of the Directory entry
identified by the AET. This is very similar to DNS.
Young Standards Track [Page 1]
RFC 1798 CLDAP June 1995
Use of DAP to achieve this functionality involves a significant
number of network exchanges:
___________________________________________________________
|_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
| 1| N-Connect.request -> |
| 2| <- N-Connect.response |
| 3| T-Connect.request -> |
| 4| <- T-Connect.response |
| | S-Connect.request, |
| | P-Connect.request, |
| | A-Associate.request, |
| 5| DAP-Bind.request -> |
| | S-Connect.response, |
| | P-Connect.response, |
| | A-Associate.response, |
| 6| <- DAP-Bind.response |
| 7| DAP-Read.request -> |
| 8| <- DAP-Read.response |
| | S-Release.request, |
| | P-Release.request, |
| | A-Release.request, |
| 9| DAP-Unbind.request -> |
| | S-Release.response, |
| | P-Release.response, |
| | A-Release.response, |
| 10| <- DAP-Unbind.response |
| | T-Disconnect.request, |
| 11| N-Disconnect.request -> |
| | T-Disconnect.response,|
| 12| <- N-Disconnect.response |
|___|______________________________________________________|
Young Standards Track [Page 2]
RFC 1798 CLDAP June 1995
This is 10 packets before the application can continue, given that it
can probably do so after issuing the T-Disconnect.request. (Some
minor variations arise depending upon the class of Network and
Transport service that is being used; for example use of TP4 over
CLNS reduces the packet count by two.) LDAP is no better in the case
where the LDAP server uses full DAP to communicate with the
Directory:
____________________________________________________________________
|__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
| 1 | TCP SYN -> |
| 2 | <- TCP SYN ACK |
| 3 | BindReq -> |
Show full document text