RFC 4512
Lightweight Directory Access Protocol (LDAP): Directory Information Models
6. Other Considerations
6.1. Preservation of User Information
Syntaxes may be defined that have specific value and/or value form (representation) preservation requirements. For example, a syntax containing digitally signed data can mandate that the server preserve both the value and form of value presented to ensure that the signature is not invalidated. Where such requirements have not been explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned.
6.2. Short Names
Short names, also known as descriptors, are used as more readable aliases for object identifiers and are used to identify various schema elements. However, it is not expected that LDAP implementations with human user interface would display these short names (or the object identifiers they refer to) to the user. Instead, they would most likely be performing translations (such as expressing the short name in one of the local national languages). For example, the short name "st" (stateOrProvinceName) might be displayed to a German-speaking user as "Land". The same short name might have different meaning in different subschemas, and, within a particular subschema, the same short name might refer to different object identifiers each identifying a different kind of schema element. Implementations MUST be prepared that the same short name might be used in a subschema to refer to the different kinds of schema elements. That is, there might be an object class 'x-fubar' and an attribute type 'x-fubar' in a subschema. Implementations MUST be prepared that the same short name might be used in the different subschemas to refer to the different schema elements. That is, there might be two matching rules 'x-fubar', each in different subschemas. Procedures for registering short names (descriptors) are detailed in BCP 64, RFC 4520 [RFC4520].6.3. Cache and Shadowing
Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested. Servers that perform shadowing or caching MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
7. Implementation Guidelines
7.1. Server Guidelines
Servers MUST recognize all names of attribute types and object classes defined in this document but, unless stated otherwise, need not support the associated functionality. Servers SHOULD recognize all the names of attribute types and object classes defined in Section 3 and 4, respectively, of [RFC4519]. Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. Servers MAY support DIT Content Rules. Servers MAY support DIT Structure Rules and Name Forms. Servers MAY support alias entries. Servers MAY support the 'extensibleObject' object class. Servers MAY support subentries. If so, they MUST do so in accordance with [RFC3672]. Servers that do not support subentries SHOULD use object entries to mimic subentries as detailed in Section 3.2. Servers MAY implement additional schema elements. Servers SHOULD provide definitions of all schema elements they support in subschema (sub)entries.7.2. Client Guidelines
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schema elements beyond those referenced in Section 7.1. The client can retrieve subschema information as described in Section 4.4. Clients MUST NOT display or attempt to decode a value as ASN.1 if the value's syntax is not known. Clients MUST NOT assume the LDAP- specific string encoding is restricted to a UTF-8 encoded string of Unicode characters or any particular subset of Unicode (such as a printable subset) unless such restriction is explicitly stated. Clients SHOULD NOT send attribute values in a request that are not valid according to the syntax defined for the attributes.
8. Security Considerations
Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations, or devices. Most countries have privacy laws regarding the publication of information about people. General security considerations for accessing directory information with LDAP are discussed in [RFC4511] and [RFC4513].9. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry as indicated in the following template: Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comment Person & email address to contact for further information: Kurt Zeilenga <kurt@OpenLDAP.org> Usage: see comment Specification: RFC 4512 Author/Change Controller: IESG Comments: The following descriptors (short names) has been added to the registry. NAME Type OID ------------------------ ---- ----------------- governingStructureRule A 2.5.21.10 structuralObjectClass A 2.5.21.9 The following descriptors (short names) have been updated to refer to this RFC. NAME Type OID ------------------------ ---- ----------------- alias O 2.5.6.1 aliasedObjectName A 2.5.4.1 altServer A 1.3.6.1.4.1.1466.101.120.6 attributeTypes A 2.5.21.5 createTimestamp A 2.5.18.1 creatorsName A 2.5.18.3 dITContentRules A 2.5.21.2 dITStructureRules A 2.5.21.1 extensibleObject O 1.3.6.1.4.1.1466.101.120.111 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
10. Acknowledgements
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
Indexing of Directories (ASID) Working Group. This document is also
based in part on "The Directory: Models" [X.501], a product of the
International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
This document is a product of the IETF LDAP Revision (LDAPBIS)
Working Group.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003. [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [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. [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006. [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006. [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006. [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994). [X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2:1994). [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).
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 <descr> 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 <descr> form of <oid> SHOULD be preferred over the <numericoid> form. However, <descr> form can be ambiguous. To address this issue, the imperative was replaced with a statement (in Section 1.4) that while the <descr> form is generally preferred, <numericoid> should be used where an unambiguous <descr> 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.Editor's Address
Kurt D. Zeilenga OpenLDAP Foundation EMail: Kurt@OpenLDAP.org
Full Copyright Statement 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).