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
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
The following descriptors (short names) has been added to
NAME Type OID
------------------------ ---- -----------------
governingStructureRule A 126.96.36.199
structuralObjectClass A 188.8.131.52
The following descriptors (short names) have been updated to
refer to this RFC.
NAME Type OID
------------------------ ---- -----------------
alias O 184.108.40.206
aliasedObjectName A 220.127.116.11
altServer A 18.104.22.168.4.1.1422.214.171.124
attributeTypes A 126.96.36.199
createTimestamp A 188.8.131.52
creatorsName A 184.108.40.206
dITContentRules A 220.127.116.11
dITStructureRules A 18.104.22.168
extensibleObject O 22.214.171.124.4.1.14126.96.36.199
ldapSyntaxes A 188.8.131.52.4.1.14184.108.40.206
matchingRuleUse A 220.127.116.11
matchingRules A 18.104.22.168
modifiersName A 22.214.171.124
modifyTimestamp A 126.96.36.199
nameForms A 188.8.131.52
namingContexts A 184.108.40.206.4.1.14220.127.116.11
objectClass A 18.104.22.168
objectClasses A 22.214.171.124
subschema O 126.96.36.199
subschemaSubentry A 188.8.131.52
supportedControl A 184.108.40.206.4.1.14220.127.116.11
supportedExtension A 18.104.22.168.4.1.1422.214.171.124
supportedFeatures A 126.96.36.199.4.1.4188.8.131.52
supportedLDAPVersion A 184.108.40.206.4.1.14220.127.116.11
supportedSASLMechanisms A 18.104.22.168.4.1.1422.214.171.124
top O 126.96.36.199
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)
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
[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,
[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
[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"
[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-
[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
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'
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
- 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
- Clarify that only recognized request controls need to be enumerated
- 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
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,
- 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
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
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
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
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
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'.
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.
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
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
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).