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