doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc1798.txt b/doc/rfc/rfc1798.txt
new file mode 100644
index 0000000..24304c8
--- /dev/null
+++ b/doc/rfc/rfc1798.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+   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: +44 81 332 9091
+   EMail: A.Young@isode.com
+   X.400:    i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Young                       Standards Track                     [Page 9]
+