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