Collective Attributes in the Lightweight Directory Access Protocol (LDAP)
Extracted elements (21)
Collective attributes are visible but not updateable by clients accessing entries within the collection; they must be modified via the associated collective attributes subentry. This separation enforces administrative control over shared values.
OIDs used in this document were assigned by ISO/IEC JTC1-SC6 for X.500 schema elements; this document makes no new OID assignments and only provides LDAP schema descriptions mapping to existing X.500 schema.
When an entry belongs to multiple entry collections, values of each collective attribute are combined such that independent sources are not manifested to clients — the entry presents a unified view of all applicable collective values.
Collective attributes are derived from X.520 definitions, with superior attribute types described in RFC 2256 for use with LDAP. Implementations must align with X.500 Directory Models (X.501) for interoperability.
A collective attribute subentry SHOULD contain at least one collective attribute. The collective attributes are available for finding, searching, and comparison at every entry within scope, but administered via the subentry.
Collective attributes SHALL NOT be SINGLE-VALUED, and collective attribute types SHALL NOT appear in the attribute types of an object class definition.
Implementations SHOULD support collective attribute subentries in both collectiveAttributeSpecificArea (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative areas.
Implementations SHOULD support the collective attributes defined in section 3 (c-l, c-st, c-street, c-o, c-ou, c-PostalAddress, c-PostalCode, c-PostOfficeBox, c-PhysicalDeliveryOfficeName, c-TelephoneNumber, c-TelexNumber, c-FacsimileTelephoneNumber, c-InternationalISDNNumber) and MAY support additional collective attributes.
LDAP servers MUST act in accordance with the X.500 Directory Models (X.501) when providing the collective attributes service.
Non-collective attribute types SHALL NOT subtype collective attributes.
Operational attributes SHALL NOT be defined to be collective.
The collectiveExclusions operational attribute MAY appear in any entry and MAY have multiple values, allowing particular collective attributes to be excluded from an entry.
c-l (OID 2.5.4.7.1) is the collective locality name attribute, defined as SUP l COLLECTIVE, specifying a shared locality name for a collection of entries.
c-o (OID 2.5.4.10.1) is the collective organization name attribute, defined as SUP o COLLECTIVE, and c-ou (OID 2.5.4.11.1) is the collective organizational unit name, defined as SUP ou COLLECTIVE.
c-TelephoneNumber (OID 2.5.4.20.1) specifies a collective telephone number (SUP telephoneNumber COLLECTIVE); c-FacsimileTelephoneNumber (OID 2.5.4.23.1) specifies a collective facsimile number (SUP facsimileTelephoneNumber COLLECTIVE).
Collective attribute types are defined as userApplications attributes with the COLLECTIVE flag. By convention, they are named by prefixing the non-collective supertype name with 'c-' (e.g., c-TelephoneNumber subtypes telephoneNumber).
The collectiveAttributeSubentries operational attribute (OID 2.5.18.12) identifies all collective attribute subentries that affect a given entry. It uses distinguishedNameMatch equality and DN syntax, is directoryOperation usage, and is NO-USER-MODIFICATION.
The collectiveAttributeSubentry auxiliary object class (OID 2.5.17.2) is used to administer collective attributes. Subentries of this class are collective attribute subentries whose contained attributes apply to all entries within the subentry's scope.
The collectiveExclusions operational attribute (OID 2.5.18.7) uses objectIdentifierMatch equality and OID syntax. When the OID 2.5.18.0 (excludeAllCollectiveAttributes) is present as a value, all collective attributes are excluded from the entry.
IANA registered 13 collective attribute type descriptors (c-l, c-st, c-street, c-o, c-ou, c-PostalAddress, c-PostalCode, c-PostOfficeBox, c-PhysicalDeliveryOfficeName, c-TelephoneNumber, c-TelexNumber, c-FacsimileTelephoneNumber, c-InternationalISDNNumber) plus collectiveAttributeSubentries and collectiveExclusions as attributes, and collectiveAttributeSubentry as an object class, in the LDAP Descriptor registry.
Collective attributes are subject to access control restrictions and other administrative policy. Access via an entry in a collection is governed by rules for that entry's attributes; access via a subentry is governed by rules for that subentry's attributes. Because LDAP lacks a standard access model, server implementations may differ in specifics.