[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
LDAPEXT Working Group                                        Alan Lloyd
INTERNET-DRAFT PROPOSAL                                   OpenDirectory
Intended Category: Standards Track
Expires: TBD


                                                      18 September 1998


             List and Read Operations: LDAP-X.500 Alignment
                  <draft-lloyd-ldap-list-read-00.txt>



1.  Status of this Memo

     This document is a proposal.

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

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

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
     (US West Coast).

LDAP List and Read Operations


2.  Abstract

LDAP was originally developed as a lightweight protocol but through its
development it has added many features to a point where there is very
little difference in terms of simplicity or code size to that of DAP.
However, DAP included features which provided efficient navigation
through a multi server distributed directory systems (List), efficient
retreival (Read)and the ability to provide service controls to select
operation requestpriority, permit/deny chained operations and the
ability to select master/replica data in the operation response.

LDAP is now widely used as the access for X.500 distributed directory
systems, however LDAP in its original form omitted the items (List, Read
and Service Controls) as defined above.
The List/Read requirements were serviced by LDAP through the use of
"pre-selected" Search operations. The Service Controls as per X.511
for distributed operation control have in most part been omitted from
LDAP. (These are the subject of another proposal.)

Experience in the field is showing that not having a List (and to a
lesser degree, Read) operations in LDAP accessing to distributed
directory system causes very inefficient multi server
navigation compared to that of an LDAP Search being used. A Search
operation is the most complicated of directory services, yet in the LDAP
case it is being used for lesser and more efficient functions.
For instance, in the LDAP only multi - server environments, not having
a List operation causes considerable  client re processing and protocol
exchanges due to dealing with system referrals. This leads to extended
user/client response times. For those who have already implemented a
LDAP Search operation a Read and List should be of little consequence.


This document defines two additional operations for LDAP namely List
and Read that extend the LDAPv3 [LDAP] operations to provide a simple
navigation/browsing and information retrieval mechanism by which a
LDAP client can be more effective in dealing with a distributed
directory system.


In addition, the operations proposed provide major step in the
alignment of LDAP and DAP and their use of X.500. This will permit
functional consistency to be achieved in directory enabled applications
that use LDAP for access to X.500 systems.


In order to distinguish this functionality from LDAP V3 capable systems,
an upgrade to LDAP V4 is also proposed.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  and "MAY" in this document are
to be interpreted as described in RFC 2119 [KEYWORDS].



3.  General Approach

The approach taken to implement the features required is define the
List and Read as per X.511 (DAP).



4. Directory Read Operation
A read operation is used to extract information from an explicitly
identified entry. It may also be used to verify a distinguished name.



        ReadRequest ::= [APPLICATION 17] SEQUENCE {
                entry           LDAPDN,
                derefAliases    ENUMERATED {
                        neverDerefAliases       (0),--default
                        derefAlways             (3) },
                typesOnly       BOOLEAN,
                attributes      AttributeDescriptionList }

 The base level definitions of the Read Request and Result parameters
 are defined in [LDAP].



4.1 Read Result

   The results of the Read attempted by the server upon receipt of a
   Read Request are returned in Read Response, which is an LDAP
   message containing either Entry data or an Error.

        ReadResult ::= [APPLICATION 18] SEQUENCE {
                LDAPResult,
                attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        -- implementors should note that the PartialAttributeList may
        -- have zero elements (if none of the attributes of that entry
        -- were requested, or could be returned), and that the vals set
        -- may also have zero elements (if types only was requested, or
        -- all values were excluded from the result.)


   Upon receipt of a Read Request, a server will perform the necessary
   selection of the DN requested.





5. Directory List operation
A list operation is used to efficiently obtain a list of the relative
names of the immediate subordinates of an explicitly identified entry.
Under some circumstances,(such as size/time limitations) the list
returned may be incomplete.

5.1 List Request

   The List Request is defined as follows:

        ListRequest ::= [APPLICATION 19] SEQUENCE {
                baseObject      LDAPDN,
                derefAliases    ENUMERATED {
                        neverDerefAliases       (0),--default
                        derefAlways             (3) },
                sizeLimit       INTEGER (0 .. maxInt),
                timeLimit       INTEGER (0 .. maxInt)}


 The base level definitions of the List Request and Result parameters
 are defined in [LDAP].


5.1 List Result

   The results of the List attempted by the server upon receipt of a
   List Request are returned in List Response, which is an LDAP
   message containing either RelativeLDAPDN(s) or an Error.

         ListResult ::= [APPLICATION 20] SEQUENCE {
               LDAPResult,
                 result ::= CHOICE {
                  listInfo [1] SET OF SEQUENCE {
                           rdn        RelativeLDAPDN,
                     aliasEntry [0]BOOLEAN DEFAULT  FALSE,
                     fromEntry  [1]BOOLEAN DEFAULT  TRUE }
                  uncorrelatedListInfo[0]       SET OF ListResult },



        -- implementors should note that the RelativeLDAPDNList may
        -- have zero elements (if no subordinates exist). And that the
        -- the matchedDN / LDAPDN component of the LDAPresult is set
        -- to the baseObject.




The use of uncorrelatedListInfo permits the List response to deal with
responses that are received from distributed servers/DSAs that were
involved with the List operation. Generally this parameter is only used
where signed operations are performed between some servers involved with
the List operation.



6.  Compliance

Upon receiving either of these operations, a server that supports
them MUST process them as a standard LDAPv3 operation.

Compliance to the support of the above operations will be specified
in the respective Server or Client profiles or X.500/DAP/LDAP ISPs.




6.  Security Considerations

General security issues apply as per LDAP and X.500.



7.  Associated Proposals

This proposal accompanies a proposal to align the service control
aspects of LDAP V3 and X.511.
draft-lloyd-ldap-svcs-00.txt



8.  Acknowledgements

   This document is an update to RFC 2251, by Mark. Wahl, ,Tim
   Howes, and Steve Kille.  Design ideas included in this document are
   based on those provided in the X.500 ISO/ITU specifications. The
   contributions of individuals in these working groups is gratefully
   acknowledged.



9.  Copyright
TBS



10.  Bibliography

[KEYWORDS]  S. Bradner, "Key words for use in RFCs to Indicate Require-
            ment Levels", RFC 2119, March 1997.

[LDAP]      M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
            Protocol (v3)", RFC 2251, December 1997.

[X.208]     CCITT Recommendation X.208: Specification of Abstract
              Syntax Notation One (ASN.1), 1988.

[X.501]     ITU-T Recommendation X.501: Information
            Technology - Open Systems Interconnection - The
            Directory: Models, 1993.

[X.509]     ITU-T Recommendation X.509 (1997 E): Information
            Technology - Open Systems Interconnection - The
            Directory: Authentication Framework, June 1997.

[X.511]     ITU-T Recommendation X.511: Information
            Technology - Open Systems Interconnection - The
            Directory: Abstract Service Definition(DAP), 1993/7.

[X.518]     ITU-T Recommendation X.511: Information
            Technology - Open Systems Interconnection - The
            Directory: Procedures for Distributed Operations(DSP),1993


[X.520]     ITU-T Recommendation X.520: Information
            Technology - Open Systems Interconnection - The
            Directory: Selected Attribute Types, 1993.


[X.521]     ITU-T Recommendation X.520: Information
            Technology - Open Systems Interconnection - The
            Directory: Selected Object Classes, 1993.


[X.525]     ITU-T Recommendation X.511: Information
            Technology - Open Systems Interconnection - The
            Directory: Replication (DISP), 1993.






9.  Author's Addresses

   Alan Lloyd
   OpenDirectory Pty Ltd.
   266 Maroondah Highway
   Mooroolbark
   Melbourne Vic 3138
   Australia
   +61 3 9727 8900
   mobile + 61 416 536 749
   alan.lloyd@opendirectory.com.au