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