New Internet Draft (CLDAPP

[Steve Kille <[e-mail]>]

This belongs to the OSI-DS group.   Could you install and announce?

thanks


Steve

--- Begin Message ---

Thanks for your comments. Here is an updated draft. Now what do
I do with it?

Alan.

========






Network Working Group                                       Alan Young
INTERNET-DRAFT                               Union Bank of Switzerland
                                                     Expires 20 Apr 93


         Connection-less Lightweight Directory Access Protocol



1.  Status of this Memo

This draft document will be submitted to the RFC Editor as a standards
document. Distribution of this memo is unlimited. Please send comments
to the authors, or the discussion group <[e-mail]>uk>.

This document is an Internet Draft.  Internet Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute working docu-
ments as Internet Drafts).

Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other docu-
ments at any time.  It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."

Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.

2.  Abstract

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).  In particular, it is aimed at avoiding
the elapsed time that is associated with connection-oriented communica-
tion and it facilitates use of the directory in a manner analagous to
the DNS [6,7].  It is specifically targeted at simple lookup applica-
tions 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 [5].
The protocol specification draws heavily on that of LDAP.

3.  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 sim-
ple read access to a few attribute values. Applications addressing is a
good example of this type of use where and application entity needs to



Expires 20 Apr 93                                       [Page 1]





CLDAP                                                       October 1993


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.

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 |
     |___|______________________________________________________|

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 ser-
vice 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:






Expires 20 Apr 93                                       [Page 2]





CLDAP                                                       October 1993


  ____________________________________________________________________
 |  # |   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|
 |____|______________________________________________________________|

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.






Expires 20 Apr 93                                       [Page 3]





CLDAP                                                       October 1993


4.  Protocol Model

CLDAP is based directly on LDAP [5] and inherits most 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).

-    The Bind and Unbind operations are not available.

The definitions of 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.  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 implementa-
tions: 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. 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.  It is not necessary for a client to 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
are not prohibited from doing 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



Expires 20 Apr 93                                       [Page 4]





CLDAP                                                       October 1993


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 direc-
tory abstract service, so it can be cleanly provided by the DAP.

5.  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.  Specifica-
tions for two underlying services are defined here, though others are
also possible.

5.1.  User Datagram Protocol (UDP)

The LDAPMessage 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 with the exception, as an option, that multiple
search responses resulting from a single search request may be sent in a
single datagram.  Server implementations running over the UDP should
provide a protocol listener on port 389.

5.2.  Connection-less Transport Service (CLTS)

Each LDAPMessage PDU is mapped directly onto T-Unit-Data with the excep-
tion that multiple search responses resulting from a single search
request may be sent in a single T-Unit-Data.

6.  Elements of Protocol

The protocol is the same as LDAP with the restriction that Bind and
Unbind and not available. The following operations are available:

     Search
     Modify
     Add
     Delete
     ModifyRDN
     Compare
     Abandon

Given the lack of Bind, and the consequent lack of identification of the
Directory User to the Directory Service, one would not generally expect
Modify, Add, Delete or ModifyRDN to be honoured by the Directory Ser-
vice. They are not however, excluded from the protocol.






Expires 20 Apr 93                                       [Page 5]





CLDAP                                                       October 1993


6.1.  Errors

The following error code is added to the LDAPResult.resultCode enumera-
tion of [5]:

                             resultsTooLarge              (70),

This error will be returned when the LDAPMessage PDU containing the
results of an operation are too large to be sent in a single datagram or
PDU or, in the case that the multiple results of a search are to be
returned in a single datagram or PDU, that these combined results are
too large.

6.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                            |
   |__|___________________________________________________________|


7.  Implementation Considerations

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

7.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 not be too keen to unbind from the Directory during
     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 expli-
     cit) and the lack of a dontUseCopy service control in the protocol.


Expires 20 Apr 93                                       [Page 6]





CLDAP                                                       October 1993


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

7.2.  Client Implementations

For simple lookup applications, use of a retry algorithm with multiple
servers similar to that commonly used in DNS stub resolver implementa-
tions 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.

8.  Security Considerations

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

9.  Bibliography

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

[2]  Information Processing Systems -- Open Systems Interconnection --
     The Directory: Overview of Concepts, Models and Service.  ISO/IEC
     JTC 1/SC21; International Standard 9594-1, 1988

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

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

[5]  X.500 Lightweight Directory Access Protocol.  W. Yeong, T. Howes,
     S. Kille; RFC 1487, July 1993.

[6]  Domain names - implementation and specification.  P. Mockapetris;
     RFC 1035, November 1987.

[7]  Domain names - concepts and facilities.  P. Mockapetris; RFC 1034,
     November 1987.

10.  Author's Addresses

   Alan Young
   Union Bank of Switzerland
   VA213- EFTS-YON
   Postfach
   CH-8021 Zurich



Expires 20 Apr 93                                       [Page 7]





CLDAP                                                       October 1993


   [phone]
   [e-mail]
   G=ALAN; S=YOUNG; OU=ZH014; O=UBS; P=UBS; A=ARCOM; C=CH
















































Expires 20 Apr 93                                       [Page 8]

--- End Message ---