rfc1798.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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      ->                                             |
 |  4 |                     N-Connect.req      ->                    |
 |  5 |                                        <-    N-Connect.res   |
 |  6 |                     T-Connect.req      ->                    |
 |  7 |                                        <-    T-Connect.res   |
 |  8 |                     DAP-Bind.req       ->                    |
 |  9 |                                        <-    DAP-Bind.res    |
 | 10 |               <-    BindRes                                  |
 | 11 |  SearchReq    ->                                             |
 | 12 |                     DAP-Search.req     ->                    |
 | 13 |                                        <-    DAP-Search.res  |
 | 14 |               <-    SearchRes                                |
 | 15 |  TCP FIN      ->                                             |
 | 16 |                     DAP-Unbind.req     ->                    |
 | 17 |                                        <-    DAP-Unbind.res  |
 | 18 |                     N-Disconnect.req   ->                    |
 | 19 |                                        <-    N-Disconnect.res|
 |____|______________________________________________________________|





















Young                       Standards Track                     [Page 3]

RFC 1798                         CLDAP                         June 1995


   Here there are 14 packets before the application can continue.  Even
   if the LDAP server is on the same host as the DSA (so packet delay is
   negligible), or if the DSA supports LDAP directly, then there are
   still 6 packets.

                  ____________________________________
                 | #|   Client     LDAP   LDAP server|
                 |__|________________________________|
                 | 1|  TCP SYN      ->               |
                 | 2|               <-    TCP SYN ACK|
                 | 3|  BindReq      ->               |
                 | 4|               <-    BindRes    |
                 | 5|  SearchReq    ->               |
                 |_6|_______________<-____SearchRes__|


   This protocol provides for simple access to the Directory where the
   delays inherent in the above exchanges are unacceptable and where the
   additional functionality provided by connection-mode operation is not
   required.

2.  Protocol Model

   CLDAP is based directly on LDAP [4] and inherits many of the key
   aspects of the LDAP protocol:

   - -  Many protocol data elements are encoding as ordinary strings
        (e.g., Distinguished Names).

   - -  A lightweight BER encoding is used to encode all protocol
        elements.

   It is different to LDAP in that:

   - -  Protocol elements are carried directly over UDP or other
        connection-less transport, bypassing much of the
        session/presentation overhead and that of connections (LDAP uses
        a connection-mode transport service).

   - -  A restricted set of operations is available.

   The definitions of most protocol elements are inherited from LDAP.

   The general model adopted by this protocol is one of clients
   performing protocol operations against servers. In this model, this
   is accomplished by a client transmitting a protocol request
   describing the operation to be performed to a server, which is then
   responsible for performing the necessary operations on the Directory.



Young                       Standards Track                     [Page 4]

RFC 1798                         CLDAP                         June 1995


   Upon completion of the necessary operations, the server returns a
   response containing any results or errors to the requesting client.

   Note that, although servers are required to return responses whenever
   such responses are defined in the protocol, there is no requirement
   for synchronous behaviour on the part of either client or server
   implementations: requests and responses for multiple operations may
   be exchanged by client and servers in any order, as long as servers
   eventually send a response for every request that requires one.

   Also, because the protocol is implemented over a connection-less
   transport service clients must be prepared for either requests or
   responses to be lost.  Clients should use a retry mechanism with
   timeouts in order to achieve the desired level of reliability.  For
   example, a client might send off a request and wait for two seconds.
   If no reply is forthcoming, the request is sent again and the client
   waits four seconds.  If there is still no reply, the client sends it
   again and waits eight seconds, and so on, until some maximun time.
   Such algorithms are widely used in other datagram-based protocol
   implementations, such as the DNS.  It is not appropriate to mandate a
   specific algorithm as this will depend upon the requirments and
   operational environment of individual CLDAP client implementations.

   It is not required that a client abandon any requests to which no