rfc1798.txt

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

   response has been received and for which a reply is no longer
   required (because the request has been timed out), but they may do
   so.

   Consistent with the model of servers performing protocol operations
   on behalf of clients, it is also to be noted that protocol servers
   are expected to handle referrals without resorting to the return of
   such referrals to the client. This protocol makes no provisions for
   the return of referrals to clients, as the model is one of servers
   ensuring the performance of all necessary operations in the
   Directory, with only final results or errors being returned by
   servers to clients.

   Note that this protocol can be mapped to a strict subset of the
   Directory abstract service, so it can be cleanly provided by the DAP.

3.  Mapping Onto Transport Services

   This protocol is designed to run over connection-less transports,
   with all 8 bits in an octet being significant in the data stream.
   Specifications for two underlying services are defined here, though
   others are also possible.





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


3.1.  User Datagram Protocol (UDP)

   The CLDAPMessage PDUs are mapped directly onto UDP datagrams.  Only
   one request may be sent in a single datagram. Only one response may
   be sent in a single datagram.  Server implementations running over
   the UDP should provide a protocol listener on port 389.

3.2.  Connection-less Transport Service (CLTS)

   Each LDAPMessage PDU is mapped directly onto T-Unit-Data.

4.  Elements of Protocol

   CLDAP messages are defined by the following ASN.1:

    CLDAPMessage ::= SEQUENCE {
        messageID       MessageID,
        user            LDAPDN,         -- on request only --
        protocolOp      CHOICE {
                        searchRequest   SearchRequest,
                        searchResponse  SEQUENCE OF
                                            SearchResponse,
                        abandonRequest  AbandonRequest
        }
    }

   where MessageID, LDAPDN, SearchRequest, SearchResponse and
   AbandonRequest are defined in the LDAP protocol.

   The 'user' element is supplied only on requests (it should be zero
   length and is ignored in responses). It may be used for logging
   purposes but it is not required that a CLDAP server implementation
   apply any particular semantics to this field.

   Editorial note:
       There has been some discussion about the desirability of
       authentication with CLDAP requests and the addition of the fields
       necessary to support this. This might take the form of a clear
       text password (which would go against the current IAB drive to
       remove such things from protocols) or some arbitrary credentials.
       Such a field is not included.  It is felt that, in general,
       authentication would incur sufficient overhead to negate the
       advantages of the connectionless basis of CLDAP. If an
       application requires authenticated access to the Directory then
       CLDAP is not an appropriate protocol.






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


   Within a searchResponse all but the last SearchResponse has choice
   'entry' and the last SearchResponse has choice 'resultCode'.  Within
   a searchResponse, as an encoding optimisation, the value of the
   objectName LDAP DN may use a trailing '*' character to refer to the
   baseObject of the corresponding searchRequest.  For example, if the
   baseObject is specified as "o=UofM, c=US", then the following
   objectName LDAPDNs in a response would have the indicated meanings

          objectName returned   actual LDAPDN denoted
          ____________________________________________________
          "*"                   "o=UofM, c=US"
          "cn=Babs Jensen, *"   "cn=Babs Jensen, o=UofM, c=US"

4.1.  Errors

The following error code is added to the LDAPResult.resultCode
enumeration of [4]:

                             resultsTooLarge              (70),

   This error is returned when the LDAPMessage PDU containing the
   results of an operation are too large to be sent in a single
   datagram.

4.2.  Example

   A simple lookup can be performed in 4 packets. This is reduced to 2
   if either the DSA implements the CLDAP protocol, the CLDAP server has
   a cache of the desired results, or the CLDAP server and DSA are co-
   located such that there is insignificant delay between them.

    _______________________________________________________________
   |_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
   | 1|  SearchReq    ->                                          |
   | 2|                      DAP-Search.req   ->                  |
   | 3|                                       <-    DAP-Search.res|
   | 4|               <-     SearchRes                            |
   |__|___________________________________________________________|

5.  Implementation Considerations

   The following subsections provide guidance on the implementation of
   clients and servers using the CLDAP protocol.








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


5.1.  Server Implementations

   Given that the goal of this protocol is to minimise the elapsed time
   between making a Directory request and receiving the response, a
   server which uses DAP to access the directory should use techniques
   that assist in this.

   - -  A server should remain bound to the Directory during reasonably
        long idle periods or should remain bound permanently.

   - -  Cacheing of results is highly desirable but this must be
        tempered by the need to provide up-to-date results given the
        lack of a cache invalidation protocol in DAP (either implicit
        via timers or explicit) and the lack of a dontUseCopy service
        control in the protocol.

   Of course these issues are irrelevant if the CLDAP protocol is
   directly supported by a DSA.

5.2.  Client Implementations

   For simple lookup applications, use of a retry algorithm with
   multiple servers similar to that commonly used in DNS stub resolver
   implementations is recommended.  The location of a CLDAP server or
   servers may be better specified using IP addresses (simple or
   broadcast) rather than names that must first be looked up in another
   directory such as DNS.

6.  Security Considerations

   This protocol provides no facilities for authentication. It is
   expected that servers will bind to the Directory either anonymously
   or using simple authentication without a password.

7.  Bibliography

   [1] The Directory: Overview of Concepts, Models and Service.  CCITT
       Recommendation X.500, 1988.

   [2] The Directory: Models.  CCITT Recommendation X.501 ISO/IEC JTC
       1/SC21; International Standard 9594-2, 1988.

   [3] The Directory: Abstract Service Definition.  CCITT Recommendation
       X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.

   [4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
       Access Protocol", RFC 1487, Performance Systems International,
       University of Michigan, ISODE Consortium, July 1993.



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


   [5] Mockapetris, P., "Domain Names - Implementation and
       Specification", STD 13, RFC 1035, USC/Information Sciences
       Institute, November 1987.

   [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
       13, RFC 1034, USC/Information Sciences Institute, November 1987.

8.  Acknowledgements

   Many thanks to Tim Howes and Steve Kille for their detailed comments
   and to other members of the working group.

   This work was initiated by the Union Bank of Switzerland.

9.  Author's Address

   Alan Young
   ISODE Consortium
   The Dome, The Square
   RICHMOND
   GB - TW9 1DT

   Phone: [phone]
   EMail: [e-mail]
   X.400:    i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI


























Young                       Standards Track                     [Page 9]