RFC 4529

Requesting Attributes by Object Class in the Lightweight Directory Access Protocol

📅 published June 2006, from ietf

📜 RFC 4529: Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP) 🎀

okay bestie, the title block first 💅 It's from the Network Working Group, it's RFC 4529, and it's written by Kurt Zeilenga from the OpenLDAP Foundation. The category is Informational 🌸 and the date is June 2006 ✨. The header doesn't list anything it obsoletes or updates, so there's nothing to chase down there 🧚

Status of This Memo 🦋

This memo is just giving information for the Internet community 💜 It is NOT a specification for an Internet standard of any kind, and distribution is unlimited ✨

Copyright (C) The Internet Society (2006) 🌈

Abstract 💅

LDAP search lets clients ask for all user application attributes, all operational attributes, and/or attributes picked by their description 🔥 This doc extends LDAP so a client can ask for all the attributes of an object class in one go, which is iconic 👑

Table of Contents 🍓

1. Background and Intended Use .....................................1
2. Terminology .....................................................2
3. Return of all Attributes of an Object Class .....................2
4. Security Considerations .........................................3
5. IANA Considerations .............................................3
6. References ......................................................4
   6.1. Normative References .......................................4
   6.2. Informative References .....................................4

1. Background and Intended Use 🎀

okay so in LDAP [RFC4510], the search operation [RFC4511] lets you ask for a set of attributes, and that set is decided by a list of attribute descriptions 💅 There are two special descriptors already: "*" asks for all user attributes [RFC4511], and "+" asks for all operational attributes [RFC3673] 🫶 The catch is there's no nice way to grab a pre-made set of attributes, like the ones used to represent one kind of object 😭

So this doc lets you put an object class identifier in attribute lists, like in Search requests, to get back all the attributes that belong to that object class ✨ The COMMERCIAL AT character ("@", U+0040) is what tells the server "this is an object class, not an attribute" 🧚

For example, the attribute list "@country" is the same as the attribute list 'c', 'searchGuide', 'description', and 'objectClass' 🍓 That object class is described in [RFC4519] 💖

This extension is mostly meant for when the user is directly in charge of the LDAP search parameters, like typing an LDAP URL [RFC4516] into a web browser, for example <ldap:///dc=example,dc=com?@organization?base> 🌸

2. Terminology 💅

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] 📜

DSA stands for Directory System Agent (or server) 🖥️ DSE stands for DSA-specific Entry ✨

3. Return of All Attributes of an Object Class 🔥

This extension lets object class identifiers show up in the attributes field of the LDAP SearchRequest [RFC4511], or in other request values of the AttributeSelection data type (like the attributes field in pre/post read controls [ReadEntry]), and/or in the <attributeSelector> production (like attributes of an LDAP URL [RFC4516]) 💖 For each object class named in the attributes field, the request is treated as if every attribute that class allows (by "MUST" or "MAY", directly or by "SUP"erior) [RFC4512] had been listed itself 🧚

This extension extends the <attributeSelector> [RFC4511] production, as shown in this ABNF [RFC4234]:

     attributeSelector =/ objectclassdescription
     objectclassdescription = ATSIGN oid options
     ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)

The <oid> and <options> productions are defined in [RFC4512] 🌈

The <oid> part of an <objectclassdescription> identifies the object class by its short name (descr) or its object identifier (numericoid) 👑 If the <oid> value isn't recognized, or it doesn't point to an object class, then the object class description gets treated as an unrecognized attribute description 😭

The <options> production is in the grammar for extensibility 🍓 An object class description with an unrecognized or inappropriate option gets treated as unrecognized ✨

Object class description options and attribute description options have the same syntax, but they are not semantically related 🦋 This document doesn't define any object description options 🎀

Servers that support this feature SHOULD publish the object identifier (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures' [RFC4512] attribute in the root DSE 💜 Clients that support this feature SHOULD NOT use the feature unless they know the server supports it 💅

4. Security Considerations 🛡️

⚠️ This part is seriously important, bestie! Read it closely.

This extension is basically a shorthand for asking for all the attributes of an object class 💀 Since those attributes could have been listed one by one, adding this shorthand isn't believed to raise any additional security considerations 🙈

Implementors of this LDAP extension should be familiar with the security considerations for the LDAP search operation [RFC4511], as well as the general LDAP security considerations [RFC4510] 🫶

5. IANA Considerations 🌸

Registration of the LDAP Protocol Mechanism [RFC4520] defined in this document has been completed ✨ Here's the registration template, verbatim:

    Subject: Request for LDAP Protocol Mechanism Registration
    Object Identifier: 1.3.6.1.4.1.4203.1.5.2
    Description: OC AD Lists
    Person & email address to contact for further information:
         Kurt Zeilenga <kurt@openldap.org>
    Usage: Feature
    Specification: RFC 4529
    Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
    Comments: none

This OID was assigned [ASSIGN] by the OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification 🔥

6. References 📚

6.1. Normative References 💖

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
  • [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
  • [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
  • [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
  • [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).

6.2. Informative References 🧚

Author's Address 🎀

Kurt D. Zeilenga OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) ✨

📦 where this page comes from