Skip to main content

Appendix A. Changes

This appendix is non-normative.

This document amounts to nearly a complete rewrite of portions of RFC 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve overall clarity of technical specification. This appendix provides a summary of substantive changes made to the portions of these documents incorporated into this document. Readers should consult [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of remaining portions of these documents.

A.1. Changes to RFC 2251​

This document incorporates from RFC 2251, Sections 3.2 and 3.4, and portions of Sections 4 and 6 as summarized below.

A.1.1. Section 3.2 of RFC 2251​

Section 3.2 of RFC 2251 provided a brief introduction to the X.500 data model, as used by LDAP. The previous specification relied on [X.501] but lacked clarity in how X.500 models are adapted for use by LDAP. This document describes the X.500 data models, as used by LDAP, in greater detail, especially in areas where adaptation is needed.

Section 3.2.1 of RFC 2251 described an attribute as "a type with one or more associated values". In LDAP, an attribute is better described as an attribute description, a type with zero or more options, and one or more associated values.

Section 3.2.2 of RFC 2251 mandated that subschema subentries contain objectClasses and attributeTypes attributes, yet X.500(93) treats these attributes as optional. While generally all implementations that support X.500(93) subschema mechanisms will provide both of these attributes, it is not absolutely required for interoperability that all servers do. The mandate was removed for consistency with X.500(93). The subschema discovery mechanism was also clarified to indicate that subschema controlling an entry is obtained by reading the (sub)entry referred to by that entry's 'subschemaSubentry' attribute.

A.1.2. Section 3.4 of RFC 2251​

Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". This material, with changes, was incorporated in Section 5.1 of this document.

Changes:

  • Clarify that attributes of the root DSE are subject to "other restrictions" in addition to access controls.

  • Clarify that only recognized extended requests need to be enumerated 'supportedExtension'.

  • Clarify that only recognized request controls need to be enumerated 'supportedControl'.

  • Clarify that root DSE attributes are operational and, like other operational attributes, will not be returned in search requests unless requested by name.

  • Clarify that not all root DSE attributes are user modifiable.

  • Remove inconsistent text regarding handling of the 'subschemaSubentry' attribute within the root DSE. The previous specification stated that the 'subschemaSubentry' attribute held in the root DSE referred to "subschema entries (or subentries) known by this server". This is inconsistent with the attribute's intended use as well as its formal definition as a single valued attribute [X.501]. It is also noted that a simple (possibly incomplete) list of subschema (sub)entries is not terribly useful. This document (in Section 5.1) specifies that the 'subschemaSubentry' attribute of the root DSE refers to the subschema controlling the root DSE. It is noted that the general subschema discovery mechanism remains available (see Section 4.4 of this document).

A.1.3. Section 4 of RFC 2251​

Portions of Section 4 of RFC 2251 detailing aspects of the information model used by LDAP were incorporated in this document, including:

  • Restriction of distinguished values to attributes whose descriptions have no options (from Section 4.1.3);

  • Data model aspects of Attribute Types (from Section 4.1.4), Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), Matching Rule Identifier (from 4.1.9); and

  • User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).

Clarifications to these portions include:

  • Subtyping and AttributeDescriptions with options.

A.1.4. Section 6 of RFC 2251​

The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 where incorporated into this document.

A.2. Changes to RFC 2252​

This document incorporates Sections 4, 5, and 7 from RFC 2252.

A.2.1. Section 4 of RFC 2252​

The specification was updated to use Augmented BNF [RFC4234]. The string representation of an OBJECT IDENTIFIER was tightened to disallow leading zeros as described in RFC 2252.

The syntax was changed to disallow semicolon (U+003B) characters in order to appear to be consistent its natural language specification "descr is the syntactic representation of an object descriptor, which consists of letters and digits, starting with a letter". In a related change, the statement "an AttributeDescription can be used as the value in a NAME part of an AttributeTypeDescription" was deleted. RFC 2252 provided no specification of the semantics of attribute options appearing in NAME fields.

RFC 2252 stated that the form of SHOULD be preferred over the form. However, form can be ambiguous. To address this issue, the imperative was replaced with a statement (in Section 1.4) that while the form is generally preferred, should be used where an unambiguous is not available. Additionally, an expanded discussion of descriptor issues is in Section 6.2 ("Short Names").

The ABNF for a quoted string (qdstring) was updated to reflect support for the escaping mechanism described in Section 4.3 of RFC 2252.

A.2.2. Section 5 of RFC 2252​

Definitions of operational attributes provided in Section 5 of RFC 2252 where incorporated into this document.

The 'namingContexts' description was clarified. A first-level DSA should publish, in addition to other values, "" indicating the root of the DIT.

The 'altServer' description was clarified. It may hold any URI.

The 'supportedExtension' description was clarified. A server need only list the OBJECT IDENTIFIERs associated with the extended requests of the extended operations it recognizes.

The 'supportedControl' description was clarified. A server need only list the OBJECT IDENTIFIERs associated with the request controls it recognizes.

Descriptions for the 'structuralObjectClass' and 'governingStructureRule' operational attribute types were added.

The attribute definition of 'subschemaSubentry' was corrected to list the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.

A.2.3. Section 7 of RFC 2252​

Section 7 of RFC 2252 provides definitions of the 'subschema' and 'extensibleObject' object classes. These definitions where integrated into Section 4.2 and Section 4.3 of this document, respectively. Section 7 of RFC 2252 also contained the object class implementation requirement. This was incorporated into Section 7 of this document.

The specification of 'extensibleObject' was clarified regarding how it interacts with precluded attributes.

A.3. Changes to RFC 2256​

This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256.

Section 5.1 of RFC 2256 provided the definition of the 'objectClass' attribute type. This was integrated into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.

Section 5.2 of RFC 2256 provided the definition of the 'aliasedObjectName' attribute type. This was integrated into Section 2.6.2 of this document.

Section 7.1 of RFC 2256 provided the definition of the 'top' object class. This was integrated into Section 2.4.1 of this document.

Section 7.2 of RFC 2256 provided the definition of the 'alias' object class. This was integrated into Section 2.6.1 of this document.

A.4. Changes to RFC 3674​

This document made no substantive change to the 'supportedFeatures' technical specification provided in RFC 3674.