6 INTERNET-DRAFT Kurt D. Zeilenga
7 Intended Category: Informational OpenLDAP Foundation
8 Expires in six months 18 July 2004
11 Requesting Attributes by Object Class in the
12 Lightweight Directory Access Protocol
13 <draft-zeilenga-ldap-adlist-08.txt>
18 This document is intended to be, after appropriate review and
19 revision, submitted to the RFC Editor as an Informational document.
20 Distribution of this memo is unlimited. Technical discussion of this
21 document will take place on the IETF LDAP Extensions mailing list
22 <ldapext@ietf.org>. Please send editorial comments directly to the
23 author <Kurt@OpenLDAP.org>.
25 By submitting this Internet-Draft, I accept the provisions of Section
26 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
27 applicable patent or other IPR claims of which I am aware have been
28 disclosed, or will be disclosed, and any of which I become aware will
29 be disclosed, in accordance with RFC 3668.
31 Internet-Drafts are working documents of the Internet Engineering Task
32 Force (IETF), its areas, and its working groups. Note that other
33 groups may also distribute working documents as Internet-Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference material
38 or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
42 Internet-Draft Shadow Directories can be accessed at
43 <http://www.ietf.org/shadow.html>.
45 Copyright (C) The Internet Society (2004). All Rights Reserved.
47 Please see the Full Copyright section near the end of this document
53 The Lightweight Directory Access Protocol (LDAP) search operation
57 Zeilenga Requesting Attributes by Object Class [Page 1]
59 INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
62 provides mechanisms for clients to request all user application
63 attributes, all operational attributes, and/or attributes selected by
64 their description. This document extends LDAP to support a mechanism
65 that LDAP clients may use to request the return of all attributes
66 belonging to an object class.
71 In the Lightweight Directory Access Protocol (LDAP) [RFC3377], the
72 search operation [RFC2251] support requesting a sets of attributes.
73 This set is determined by a list of attribute descriptions. Two
74 special descriptors are defined to request all user attributes ("*")
75 [RFC2251] and all operational attributes ("+") [RFC3673]. However,
76 there is no convenient mechanism for requesting pre-defined sets of
79 This document extends LDAP to allow an object class identifier to be
80 specified in attributes lists, such as in Search requests, to request
81 the return all attributes belonging to an object class. The
82 COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
83 class identifier from an attribute descriptions.
85 For example, the attribute list of "@country" is equivalent to the
86 attribute list of 'c', 'searchGuide', 'description', and
87 'objectClass'. This object class and its attributes are described in
90 This extension is intended to be used where the user is in direct
91 control of the parameters of the LDAP search operation, such as when
92 entering a LDAP URL [RFC2255] into a web browser.
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in BCP 14 [RFC2119].
101 DSA stands for Directory System Agent (or server).
102 DSE stands for DSA-specific Entry.
105 3. Return of all Attributes of an Object Class
107 This extension allows object class identifiers is to be provided in
108 the attributes field of the LDAP SearchRequest [RFC2251] or other
109 request structures who borrow the attributes field and its semantics
113 Zeilenga Requesting Attributes by Object Class [Page 2]
115 INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
118 (e.g., attributes field in pre/post read controls [READENTRY]). For
119 each object class identified in the attributes field, the request is
120 to be treated as if each attribute allowed by that class (by "MUST" or
121 "MAY", directly or by "SUP"erior) was itself listed.
123 If the object class identifier is unrecognized, it is be treated an an
124 unrecognized attribute description.
126 This extension redefines the attributes field of the SearchRequest to
127 be a DescriptionList described by the following ASN.1 [X.680] data
130 DescriptionList ::= SEQUENCE OF Description
131 Description ::= LDAPString
133 The Description is string conforming to the ABNF [RFC2234]:
135 Description = AttributeDescription | ObjectClassDescription.
136 ObjectClassDescription = AtSign ObjectClass *( ";" options )
137 AtSign = "@" ; U+0040
139 where <AttributeDescription> and <options> productions are as defined
140 in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
141 identifier, in either <numericoid> or <descr> form [RFC2252], of an
144 <ObjectClassDescription> <options> are provided for extensibility.
145 This document only defines semantics of <ObjectClassDescription>s with
146 zero options in the attributes field of a SearchRequest. Other uses
147 may be defined in future specifications.
149 Servers supporting this feature SHOULD publish the object identifier
150 (OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
151 [RFC3674] attribute in the root DSE. Clients supporting this feature
152 SHOULD NOT use the feature unless they have knowledge the server
156 3. Security Considerations
158 This extension provides a shorthand for requesting all attributes of
159 an object class. As these attributes which could have been listed
160 individually, this shorthand is not believed to raise additional
161 security considerations.
163 Implementors of this (or any) LDAP extension should be familiar with
164 general LDAP security considerations [RFC3377].
169 Zeilenga Requesting Attributes by Object Class [Page 3]
171 INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
174 4. IANA Considerations
176 Registration of the LDAP Protocol Mechanism [RFC3383] defined in
177 document is requested.
179 Subject: Request for LDAP Protocol Mechanism Registration
180 Object Identifier: 1.3.6.1.4.1.4203.1.5.2
181 Description: OC AD Lists
182 Person & email address to contact for further information:
183 Kurt Zeilenga <kurt@openldap.org>
185 Specification: RFC XXXX
186 Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
189 This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
190 IANA-assigned private enterprise allocation [PRIVATE], for use in this
199 Email: Kurt@OpenLDAP.org
202 6. Normative References
204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
205 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
207 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
208 Specifications: ABNF", RFC 2234, November 1997.
210 [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
211 Access Protocol (v3)", RFC 2251, December 1997.
213 [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
214 "Lightweight Directory Access Protocol (v3): Attribute
215 Syntax Definitions", RFC 2252, December 1997.
217 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
218 Protocol (v3): Technical Specification", RFC 3377,
221 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
225 Zeilenga Requesting Attributes by Object Class [Page 4]
227 INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
232 [X.680] International Telecommunication Union -
233 Telecommunication Standardization Sector, "Abstract
234 Syntax Notation One (ASN.1) - Specification of Basic
235 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
238 7. Informative References
240 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
243 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
244 use with LDAPv3", RFC 2256, December 1997.
246 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
247 (also RFC 3383), September 2002.
249 [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
252 [READENTRY] Zeilenga, K., "LDAP Read Entry Controls",
253 draft-zeilenga-ldap-readentry-xx.txt, a work in
256 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
257 http://www.openldap.org/foundation/oid-delegate.txt.
259 [PRIVATE] IANA, "Private Enterprise Numbers",
260 http://www.iana.org/assignments/enterprise-numbers.
266 Copyright (C) The Internet Society (2004). This document is subject
267 to the rights, licenses and restrictions contained in BCP 78, and
268 except as set forth therein, the authors retain all their rights.
270 This document and the information contained herein are provided on an
271 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
272 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
273 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
274 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
275 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
276 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
281 Zeilenga Requesting Attributes by Object Class [Page 5]
283 INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
286 Intellectual Property Rights
288 The IETF takes no position regarding the validity or scope of any
289 Intellectual Property Rights or other rights that might be claimed to
290 pertain to the implementation or use of the technology described in
291 this document or the extent to which any license under such rights
292 might or might not be available; nor does it represent that it has
293 made any independent effort to identify any such rights. Information
294 on the procedures with respect to rights in RFC documents can be found
295 in BCP 78 and BCP 79.
297 Copies of IPR disclosures made to the IETF Secretariat and any
298 assurances of licenses to be made available, or the result of an
299 attempt made to obtain a general license or permission for the use of
300 such proprietary rights by implementers or users of this specification
301 can be obtained from the IETF on-line IPR repository at
302 http://www.ietf.org/ipr.
304 The IETF invites any interested party to bring to its attention any
305 copyrights, patents or patent applications, or other proprietary
306 rights that may cover technology that may be required to implement
307 this standard. Please address the information to the IETF at
337 Zeilenga Requesting Attributes by Object Class [Page 6]