Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4512


Lightweight Directory Access Protocol (LDAP): Directory Information Models

Part 3 of 3, p. 40 to 52
Prev RFC Part


prevText      Top      Up      ToC       Page 40 
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.

Top      Up      ToC       Page 41 
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.

Top      Up      ToC       Page 42 
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.

Top      Up      ToC       Page 43 
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 <>
      Usage: see comment
      Specification: RFC 4512
      Author/Change Controller: IESG

      The following descriptors (short names) has been added to
      the registry.

        NAME                         Type OID
        ------------------------     ---- -----------------
        governingStructureRule          A
        structuralObjectClass           A

      The following descriptors (short names) have been updated to
      refer to this RFC.

        NAME                         Type OID
        ------------------------     ---- -----------------
        alias                           O
        aliasedObjectName               A
        altServer                       A
        attributeTypes                  A
        createTimestamp                 A
        creatorsName                    A
        dITContentRules                 A
        dITStructureRules               A
        extensibleObject                O
        ldapSyntaxes                    A

Top      Up      ToC       Page 44 
        matchingRuleUse                 A
        matchingRules                   A
        modifiersName                   A
        modifyTimestamp                 A
        nameForms                       A
        namingContexts                  A
        objectClass                     A
        objectClasses                   A
        subschema                       O
        subschemaSubentry               A
        supportedControl                A
        supportedExtension              A
        supportedFeatures               A
        supportedLDAPVersion            A
        supportedSASLMechanisms         A
        top                             O

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.

Top      Up      ToC       Page 45 
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,
                 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

Top      Up      ToC       Page 46 
   [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"
                 ( 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).

Top      Up      ToC       Page 47 
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'

Top      Up      ToC       Page 48 
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
     enumerated 'supportedExtension'.

   - 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
     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,

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

Top      Up      ToC       Page 49 
   - 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

Top      Up      ToC       Page 50 
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
   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

   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'.

Top      Up      ToC       Page 51 
   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


Top      Up      ToC       Page 52 
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

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

   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).