source: vendor/current/source4/ldap_server/devdocs/rfc4529.txt@ 414

Last change on this file since 414 was 414, checked in by Herwig Bauernfeind, 15 years ago

Samba 3.5.0: Initial import
File size: 11.5 KB
Line 
1
2
3
4
5
6
7Network Working Group K. Zeilenga
8Request for Comments: 4529 OpenLDAP Foundation
9Category: Informational June 2006
10
11
12 Requesting Attributes by Object Class in the
13 Lightweight Directory Access Protocol (LDAP)
14
15Status of This Memo
16
17 This memo provides information for the Internet community. It does
18 not specify an Internet standard of any kind. Distribution of this
19 memo is unlimited.
20
21Copyright Notice
22
23 Copyright (C) The Internet Society (2006).
24
25Abstract
26
27 The Lightweight Directory Access Protocol (LDAP) search operation
28 provides mechanisms for clients to request all user application
29 attributes, all operational attributes, and/or attributes selected by
30 their description. This document extends LDAP to support a mechanism
31 that LDAP clients may use to request the return of all attributes of
32 an object class.
33
34Table of Contents
35
36 1. Background and Intended Use .....................................1
37 2. Terminology .....................................................2
38 3. Return of all Attributes of an Object Class .....................2
39 4. Security Considerations .........................................3
40 5. IANA Considerations .............................................3
41 6. References ......................................................4
42 6.1. Normative References .......................................4
43 6.2. Informative References .....................................4
44
451. Background and Intended Use
46
47 In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the
48 search operation [RFC4511] supports requesting the return of a set of
49 attributes. This set is determined by a list of attribute
50 descriptions. Two special descriptors are defined to request all
51 user attributes ("*") [RFC4511] and all operational attributes ("+")
52 [RFC3673]. However, there is no convenient mechanism for requesting
53 pre-defined sets of attributes such as the set of attributes used to
54 represent a particular class of object.
55
56
57
58Zeilenga Informational [Page 1]
59
60
61RFC 4529 Requesting Attributes by Object Class June 2006
62
63
64 This document extends LDAP to allow an object class identifier to be
65 specified in attributes lists, such as in Search requests, to request
66 the return of all attributes belonging to an object class. The
67 COMMERCIAL AT ("@", U+0040) character is used to distinguish an
68 object class identifier from an attribute descriptions.
69
70 For example, the attribute list of "@country" is equivalent to the
71 attribute list of 'c', 'searchGuide', 'description', and
72 'objectClass'. This object class is described in [RFC4519].
73
74 This extension is intended primarily to be used where the user is in
75 direct control of the parameters of the LDAP search operation, for
76 instance when entering an LDAP URL [RFC4516] into a web browser, such
77 as <ldap:///dc=example,dc=com?@organization?base>.
78
792. Terminology
80
81 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
82 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
83 and "OPTIONAL" are to be interpreted as described in BCP 14
84 [RFC2119].
85
86 DSA stands for Directory System Agent (or server).
87 DSE stands for DSA-specific Entry.
88
893. Return of All Attributes of an Object Class
90
91 This extension allows object class identifiers to be provided in the
92 attributes field of the LDAP SearchRequest [RFC4511] or other request
93 values of the AttributeSelection data type (e.g., attributes field in
94 pre/post read controls [ReadEntry]) and/or <attributeSelector>
95 production (e.g., attributes of an LDAP URL [RFC4516]). For each
96 object class identified in the attributes field, the request is to be
97 treated as if each attribute allowed by that class (by "MUST" or
98 "MAY", directly or by "SUP"erior) [RFC4512] were itself listed.
99
100 This extension extends the <attributeSelector> [RFC4511] production
101 as indicated by the following ABNF [RFC4234]:
102
103 attributeSelector =/ objectclassdescription
104 objectclassdescription = ATSIGN oid options
105 ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
106
107 where <oid> and <options> productions are as defined in [RFC4512].
108
109
110
111
112
113
114
115Zeilenga Informational [Page 2]
116
117
118RFC 4529 Requesting Attributes by Object Class June 2006
119
120
121 The <oid> component of an <objectclassdescription> production
122 identifies the object class by short name (descr) or object
123 identifier (numericoid). If the value of the <oid> component is
124 unrecognized or does not refer to an object class, the object class
125 description is to be treated as an unrecognized attribute
126 description.
127
128 The <options> production is included in the grammar for extensibility
129 purposes. An object class description with an unrecognized or
130 inappropriate option is to be treated as unrecognized.
131
132 Although object class description options and attribute description
133 options share the same syntax, they are not semantically related.
134 This document does not define any object description option.
135
136 Servers supporting this feature SHOULD publish the object identifier
137 (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
138 [RFC4512] attribute in the root DSE. Clients supporting this feature
139 SHOULD NOT use the feature unless they know that the server supports
140 it.
141
1424. Security Considerations
143
144 This extension provides a shorthand for requesting all attributes of
145 an object class. Because these attributes could have been listed
146 individually, introduction of this shorthand is not believed to raise
147 additional security considerations.
148
149 Implementors of this LDAP extension should be familiar with security
150 considerations applicable to the LDAP search operation [RFC4511], as
151 well as with general LDAP security considerations [RFC4510].
152
1535. IANA Considerations
154
155 Registration of the LDAP Protocol Mechanism [RFC4520] defined in this
156 document has been completed.
157
158 Subject: Request for LDAP Protocol Mechanism Registration
159 Object Identifier: 1.3.6.1.4.1.4203.1.5.2
160 Description: OC AD Lists
161 Person & email address to contact for further information:
162 Kurt Zeilenga <kurt@openldap.org>
163 Usage: Feature
164 Specification: RFC 4529
165 Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
166 Comments: none
167
168
169
170
171
172Zeilenga Informational [Page 3]
173
174
175RFC 4529 Requesting Attributes by Object Class June 2006
176
177
178 This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
179 IANA-assigned private enterprise allocation [PRIVATE], for use in
180 this specification.
181
1826. References
183
1846.1. Normative References
185
186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
187 Requirement Levels", BCP 14, RFC 2119, March 1997.
188
189 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
190 Syntax Specifications: ABNF", RFC 4234, October 2005.
191
192 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
193 Protocol (LDAP): Technical Specification Road Map", RFC
194 4510, June 2006.
195
196 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
197 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
198
199 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
200 (LDAP): Directory Information Models", RFC 4512, June
201 2006.
202
203 [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
204 Access Protocol (LDAP): Uniform Resource Locator", RFC
205 4516, June 2006.
206
207 [X.680] International Telecommunication Union -
208 Telecommunication Standardization Sector, "Abstract
209 Syntax Notation One (ASN.1) - Specification of Basic
210 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
211
2126.2. Informative References
213
214 [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
215 version 3 (LDAPv3): All Operational Attributes", RFC
216 3673, December 2003.
217
218 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
219 Protocol (LDAP): Schema for User Applications", RFC
220 4519, June 2006.
221
222 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
223 (IANA) Considerations for the Lightweight Directory
224 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
225
226
227
228
229Zeilenga Informational [Page 4]
230
231
232RFC 4529 Requesting Attributes by Object Class June 2006
233
234
235 [ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol
236 (LDAP) Read Entry Controls", RFC 4527, June 2006.
237
238 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
239 http://www.openldap.org/foundation/oid-delegate.txt.
240
241 [PRIVATE] IANA, "Private Enterprise Numbers",
242 http://www.iana.org/assignments/enterprise-numbers.
243
244Author's Address
245
246 Kurt D. Zeilenga
247 OpenLDAP Foundation
248
249 EMail: Kurt@OpenLDAP.org
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286Zeilenga Informational [Page 5]
287
288
289RFC 4529 Requesting Attributes by Object Class June 2006
290
291
292Full Copyright Statement
293
294 Copyright (C) The Internet Society (2006).
295
296 This document is subject to the rights, licenses and restrictions
297 contained in BCP 78, and except as set forth therein, the authors
298 retain all their rights.
299
300 This document and the information contained herein are provided on an
301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
303 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
304 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
305 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
307
308Intellectual Property
309
310 The IETF takes no position regarding the validity or scope of any
311 Intellectual Property Rights or other rights that might be claimed to
312 pertain to the implementation or use of the technology described in
313 this document or the extent to which any license under such rights
314 might or might not be available; nor does it represent that it has
315 made any independent effort to identify any such rights. Information
316 on the procedures with respect to rights in RFC documents can be
317 found in BCP 78 and BCP 79.
318
319 Copies of IPR disclosures made to the IETF Secretariat and any
320 assurances of licenses to be made available, or the result of an
321 attempt made to obtain a general license or permission for the use of
322 such proprietary rights by implementers or users of this
323 specification can be obtained from the IETF on-line IPR repository at
324 http://www.ietf.org/ipr.
325
326 The IETF invites any interested party to bring to its attention any
327 copyrights, patents or patent applications, or other proprietary
328 rights that may cover technology that may be required to implement
329 this standard. Please address the information to the IETF at
330 ietf-ipr@ietf.org.
331
332Acknowledgement
333
334 Funding for the RFC Editor function is provided by the IETF
335 Administrative Support Activity (IASA).
336
337
338
339
340
341
342
343Zeilenga Informational [Page 6]
344
345
Note: See TracBrowser for help on using the repository browser.