1 INTERNET-DRAFT Editor: Kurt D. Zeilenga
2 Intended Category: Standard Track OpenLDAP Foundation
3 Expires in six months 24 October 2004
4 Obsoletes: RFC 2251, RFC 2252, RFC 2256
9 LDAP: Directory Information Models
10 <draft-ietf-ldapbis-models-12.txt>
18 This document is intended to be published as a Standard Track RFC.
19 Distribution of this memo is unlimited. Technical discussion of this
20 document will take place on the IETF LDAP Revision Working Group
21 mailing list <ietf-ldapbis@openldap.org>. Please send editorial
22 comments directly to the editor <Kurt@OpenLDAP.org>.
25 By submitting this Internet-Draft, I accept the provisions of Section
26 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
27 applicable patent or other IPR claims of which I am aware have been
28 disclosed, or will be disclosed, and any of which I become aware will
29 be disclosed, in accordance with RFC 3668.
32 Internet-Drafts are working documents of the Internet Engineering Task
33 Force (IETF), its areas, and its working groups. Note that other
34 groups may also distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference material
40 or to cite them other than as "work in progress."
43 The list of current Internet-Drafts can be accessed at
44 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
45 Internet-Draft Shadow Directories can be accessed at
46 <http://www.ietf.org/shadow.html>.
49 Copyright (C) The Internet Society (2004). All Rights Reserved.
52 Please see the Full Copyright section near the end of this document
62 Zeilenga LDAP Models [Page 1]
63 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
70 The Lightweight Directory Access Protocol (LDAP) is an Internet
71 protocol for accessing distributed directory services which act in
72 accordance with X.500 data and service models. This document
73 describes the X.500 Directory Information Models, as used in LDAP.
83 1.1. Relationship to Other LDAP Specifications
84 1.2. Relationship to X.501 4
86 1.4. Common ABNF Productions
87 2. Model of Directory User Information 6
88 2.1. The Directory Information Tree 7
89 2.2. Structure of an Entry
90 2.3. Naming of Entries 8
92 2.5. Attribute Descriptions 12
94 3. Directory Administrative and Operational Information 17
97 3.3. The 'objectClass' attribute 18
98 3.4. Operational attributes 19
99 4. Directory Schema 20
100 4.1. Schema Definitions 23
101 4.2. Subschema Subentries 30
102 4.3. 'extensibleObject' 35
103 4.4. Subschema Discovery
104 5. DSA (Server) Informational Model 36
105 5.1. Server-specific Data Requirements
106 6. Other Considerations 39
107 6.1. Preservation of User Information 40
109 6.3. Cache and Shadowing 41
110 7. Implementation Guidelines
111 7.1. Server Guidelines
112 7.2. Client Guidelines
113 8. Security Considerations 42
114 9. IANA Considerations
115 10. Acknowledgments 43
122 Zeilenga LDAP Models [Page 2]
123 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
127 12.1. Normative References
128 12.2. Informative References 45
130 Intellectual Property Rights 50
138 This document discusses the X.500 Directory Information Models
139 [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
143 The Directory is "a collection of open systems cooperating to provide
144 directory services" [X.500]. The information held in the Directory is
145 collectively known as the Directory Information Base (DIB). A
146 Directory user, which may be a human or other entity, accesses the
147 Directory through a client (or Directory User Agent (DUA)). The
148 client, on behalf of the directory user, interacts with one or more
149 servers (or Directory System Agents (DSA)). A server holds a fragment
153 The DIB contains two classes of information:
156 1) user information (e.g., information provided and administrated
157 by users). Section 2 describes the Model of User Information.
160 2) administrative and operational information (e.g., information
161 used to administer and/or operate the directory). Section 3
162 describes the model of Directory Administrative and Operational
166 These two models, referred to as the generic Directory Information
167 Models, describe how information is represented in the Directory.
168 These generic models provide a framework for other information models.
169 Section 4 discusses the subschema information model and subschema
170 discovery. Section 5 discusses the DSA (Server) Informational Model.
173 Other X.500 information models, such as access control distribution
174 knowledge, and replication knowledge information models, may be
175 adapted for use in LDAP. Specification of how these models apply to
176 LDAP is left to future documents.
180 1.1. Relationship to Other LDAP Specifications
183 This document is a integral part of the LDAP technical specification
184 [Roadmap] which obsoletes the previously defined LDAP technical
189 Zeilenga LDAP Models [Page 3]
190 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
194 specification, RFC 3377, in its entirety.
197 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
198 portions of sections 4 and 6. Appendix A.1 summaries changes to these
199 sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
200 [AuthMeth], and [Roadmap] documents.
203 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
204 summaries changes to these sections. The remainder of RFC 2252 is
205 obsoleted by [Syntaxes].
208 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
209 Appendix A.3 summarizes changes to these sections. The remainder of
210 RFC 2256 is obsoleted by [Schema] and [Syntaxes].
214 1.2. Relationship to X.501
217 This document includes material, with and without adaptation, from
218 [X.501]. The material in this document takes precedence over that in
226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
228 document are to be interpreted as described in BCP 14 [RFC2119].
231 Schema definitions are provided using LDAP description formats (as
232 defined in Section 4.1). Definitions provided here are formatted
233 (line wrapped) for readability. Matching rules and LDAP syntaxes
234 referenced in these definitions are specified in [Syntaxes].
238 1.4. Common ABNF Productions
241 A number of syntaxes in this document are described using Augmented
242 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
243 number of syntaxes defined in other documents) rely on the following
247 keystring = leadkeychar *keychar
249 keychar = ALPHA / DIGIT / HYPHEN
250 number = DIGIT / ( LDIGIT 1*DIGIT )
253 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
258 Zeilenga LDAP Models [Page 4]
259 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
263 DIGIT = %x30 / LDIGIT ; "0"-"9"
264 LDIGIT = %x31-39 ; "1"-"9"
265 HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
268 SP = 1*SPACE ; one or more " "
269 WSP = 0*SPACE ; zero or more " "
272 NULL = %x00 ; null (0)
273 SPACE = %x20 ; space (" ")
274 DQUOTE = %x22 ; quote (""")
275 SHARP = %x23 ; octothorpe (or sharp sign) ("#")
276 DOLLAR = %x24 ; dollar sign ("$")
277 SQUOTE = %x27 ; single quote ("'")
278 LPAREN = %x28 ; left paren ("(")
279 RPAREN = %x29 ; right paren (")")
280 PLUS = %x2B ; plus sign ("+")
281 COMMA = %x2C ; comma (",")
282 HYPHEN = %x2D ; hyphen ("-")
283 DOT = %x2E ; period (".")
284 SEMI = %x3B ; semicolon (";")
285 LANGLE = %x3C ; left angle bracket ("<")
286 EQUALS = %x3D ; equals sign ("=")
287 RANGLE = %x3E ; right angle bracket (">")
288 ESC = %x5C ; backslash ("\")
289 USCORE = %x5F ; underscore ("_")
290 LCURLY = %x7B ; left curly brace "{"
291 RCURLY = %x7D ; right curly brace "}"
294 ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
296 UTFMB = UTF2 / UTF3 / UTF4
300 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
301 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
302 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
306 OCTET = %x00-FF ; Any octet (8-bit data unit)
309 Object identifiers (OIDs) [X.680] are represented in LDAP using a
310 dot-decimal format conforming to the ABNF:
313 numericoid = number 1*( DOT number )
316 Short names, also known as descriptors, are used as more readable
317 aliases for object identifiers. Short names are case insensitive and
322 Zeilenga LDAP Models [Page 5]
323 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
333 Where either an object identifier or a short name may be specified,
334 the following production is used:
337 oid = descr / numericoid
340 While the <descr> form is generally preferred when the usage is
341 restricted to short names referring to object identifiers which
342 identify like kinds of objects (e.g., attribute type descriptions,
343 matching rule descriptions, object class descriptions), the
344 <numericoid> form should be used when the object identifiers may
345 identify multiple kinds of objects or when an unambiguous short name
346 (descriptor) is not available.
349 Implementations SHOULD treat short names (descriptors) used in an
350 ambiguous manner (as discussed above) as unrecognized.
353 Short Names (descriptors) are discussed further in Section 6.2.
357 2. Model of Directory User Information
363 The purpose of the Directory is to hold, and provide access to,
364 information about objects of interest (objects) in some 'world'.
365 An object can be anything which is identifiable (can be named).
368 An object class is an identified family of objects, or conceivable
369 objects, which share certain characteristics. Every object belongs
370 to at least one class. An object class may be a subclass of other
371 object classes, in which case the members of the former class, the
372 subclass, are also considered to be members of the latter classes,
373 the superclasses. There may be subclasses of subclasses, etc., to
377 A directory entry, a named collection of information, is the basic
378 unit of information held in the Directory. There are multiple kinds
379 of directory entries.
382 An object entry represents a particular object. An alias entry
383 provides alternative naming. A subentry holds administrative and/or
384 operational information.
387 The set of entries representing the DIB are organized hierarchically
392 Zeilenga LDAP Models [Page 6]
393 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
397 in a tree structure known as the Directory Information Tree (DIT).
400 Section 2.1 describes the Directory Information Tree
401 Section 2.2 discusses the structure of entries.
402 Section 2.3 discusses naming of entries.
403 Section 2.4 discusses object classes.
404 Section 2.5 discusses attribute descriptions.
405 Section 2.6 discusses alias entries.
409 2.1. The Directory Information Tree
412 As noted above, the DIB is composed of a set of entries organized
413 hierarchically in a tree structure known as the Directory Information
414 Tree (DIT). Specifically, a tree where vertices are the entries.
417 The arcs between vertices define relations between entries. If an arc
418 exists from X to Y, then the entry at X is the immediate superior of Y
419 and Y is the immediate subordinate of X. An entry's superiors are the
420 entry's immediate superior and its superiors. An entry's subordinates
421 are all of its immediate subordinates and their subordinates.
424 Similarly, the superior/subordinate relationship between object
425 entries can be used to derive a relation between the objects they
426 represent. DIT structure rules can be used to govern relationships
430 Note: An entry's immediate superior is also known as the entry's
431 parent and an entry's immediate subordinate is also known as the
432 entry's child. Entries which have the same parent are known as
437 2.2. Structure of an Entry
440 An entry consists of a set of attributes which hold information about
441 the object which the entry represents. Some attributes represent user
442 information and are called user attributes. Other attributes
443 represent operational and/or administrative information and are called
444 operational attributes.
447 An attribute is an attribute description (a type and zero or more
448 options) with one or more associated values. An attribute is often
449 referred to by its attribute description. For example, the
450 'givenName' attribute is the attribute which consists of the attribute
451 description 'givenName' (the 'givenName' attribute type [Schema] and
452 zero options) and one or more associated values.
458 Zeilenga LDAP Models [Page 7]
459 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
463 The attribute type governs whether the attribute can have multiple
464 values, the syntax and matching rules used to construct and compare
465 values of that attribute, and other functions. Options indicate
466 subtypes and other functions.
469 Attribute values conform to the defined syntax of the attribute type.
472 No two values of an attribute may be equivalent. Two values are
473 considered equivalent only if they would match according to the
474 equality matching rule of the attribute type. If the attribute type
475 is defined with no equality matching rule, two values are equivalent
476 if and only if they are identical. (See 2.5.1 for other
480 For example, a 'givenName' attribute can have more than one value,
481 they must be Directory Strings, and they are case insensitive. A
482 'givenName' attribute cannot hold both "John" and "JOHN" as these are
483 equivalent values per the equality matching rule of the attribute
487 When an attribute is used for naming of the entry, one and only one
488 value of the attribute is used in forming the Relative Distinguished
489 Name. This value is known as a distinguished value.
493 2.3. Naming of Entries
496 2.3.1. Relative Distinguished Names
499 Each entry is named relative to its immediate superior. This relative
500 name, known as its Relative Distinguished Name (RDN) [X.501], is
501 composed of an unordered set of one or more attribute value assertions
502 (AVA) consisting of an attribute description with zero options and an
503 attribute value. These AVAs are chosen to match attribute values
504 (each a distinguished value) of the entry.
507 An entry's relative distinguished name must be unique among all
508 immediate subordinates of the entry's immediate superior (i.e., all
512 The following are examples of string representations of RDNs [LDAPDN]:
517 CN=Kurt Zeilenga+L=Redwood Shores
520 The last is an example of a multi-valued RDN. That is, an RDN
521 composed of multiple AVAs.
526 Zeilenga LDAP Models [Page 8]
527 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
531 2.3.2. Distinguished Names
534 An entry's fully qualified name, known as its Distinguished Name (DN)
535 [X.501], is the concatenation of its RDN and its immediate superior's
536 DN. A Distinguished Name unambiguously refers to an entry in the
537 tree. The following are examples of string representations of DNs
541 UID=nobody@example.com,DC=example,DC=com
542 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
549 An alias, or alias name, is "an name for an object, provided by the
550 use of alias entries" [X.501]. Alias entries are described in Section
558 An object class is "an identified family of objects (or conceivable
559 objects) which share certain characteristics" [X.501].
562 As defined in [X.501]:
565 Object classes are used in the Directory for a number of purposes:
568 - describing and categorising objects and the entries that
569 correspond to these objects;
572 - where appropriate, controlling the operation of the Directory;
575 - regulating, in conjunction with DIT structure rule
576 specifications, the position of entries in the DIT;
579 - regulating, in conjunction with DIT content rule
580 specifications, the attributes that are contained in entries;
583 - identifying classes of entry that are to be associated with a
584 particular policy by the appropriate administrative authority.
587 An object class (a subclass) may be derived from an object class
588 (its direct superclass) which is itself derived from an even more
589 generic object class. For structural object classes, this process
590 stops at the most generic object class, 'top' (defined in Section
591 2.4.1). An ordered set of superclasses up to the most superior
592 object class of an object class is its superclass chain.
597 Zeilenga LDAP Models [Page 9]
598 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
602 An object class may be derived from two or more direct
603 superclasses (superclasses not part of the same superclass chain).
604 This feature of subclassing is termed multiple inheritance.
607 Each object class identifies the set of attributes required to be
608 present in entries belonging to the class and the set of attributes
609 allowed to be present in entries belonging to the class. As an entry
610 of a class must meet the requirements of each class it belongs to, it
611 can be said that an object class inherits the sets of allowed and
612 required attributes from its superclasses. A subclass can identify an
613 attribute allowed by its superclass as being required. If an
614 attribute is a member of both sets, it is required to be present.
617 Each object class is defined to be one of three kinds of object
618 classes: Abstract, Structural, or Auxiliary.
621 Each object class is identified by an object identifier (OID) and,
622 optionally, one or more short names (descriptors).
626 2.4.1. Abstract Object Classes
629 An abstract object class, as the name implies, provides a base of
630 characteristics from which other object classes can be defined to
631 inherit from. An entry cannot belong to an abstract object class
632 unless it belongs to a structural or auxiliary class which inherits
633 from that abstract class.
636 Abstract object classes can not derive from structural nor auxiliary
640 All structural object classes derive (directly or indirectly) from the
641 'top' abstract object class. Auxiliary object classes do not
642 necessarily derive from 'top'.
645 The following is the object class definition (see Section 4.1.1) for
646 the 'top' object class:
649 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
652 All entries belong to the 'top' abstract object class.
656 2.4.2. Structural Object Classes
659 As stated in [X.501]:
662 An object class defined for use in the structural specification of
667 Zeilenga LDAP Models [Page 10]
668 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
672 the DIT is termed a structural object class. Structural object
673 classes are used in the definition of the structure of the names
674 of the objects for compliant entries.
677 An object or alias entry is characterised by precisely one
678 structural object class superclass chain which has a single
679 structural object class as the most subordinate object class.
680 This structural object class is referred to as the structural
681 object class of the entry.
684 Structural object classes are related to associated entries:
687 - an entry conforming to a structural object class shall
688 represent the real-world object constrained by the object
692 - DIT structure rules only refer to structural object classes;
693 the structural object class of an entry is used to specify the
694 position of the entry in the DIT;
697 - the structural object class of an entry is used, along with an
698 associated DIT content rule, to control the content of an
702 The structural object class of an entry shall not be changed.
705 Each structural object class is a (direct or indirect) subclass of the
706 'top' abstract object class.
709 Structural object classes cannot subclass auxiliary object classes.
712 Each entry is said to belong to its structural object class as well as
713 all classes in its structural object class's superclass chain.
717 2.4.3. Auxiliary Object Classes
720 Auxiliary object classes are used to augment the characteristics of
721 entries. They are commonly used to augment the sets of attributes
722 required and allowed to be present in an entry. They can be used to
723 describe entries or classes of entries.
726 Auxiliary object classes cannot subclass structural object classes.
729 An entry can belong to any subset of the set of auxiliary object
730 classes allowed by the DIT content rule associated with the structural
731 object class of the entry. If no DIT content rule is associated with
732 the structural object class of the entry, the entry cannot belong to
737 Zeilenga LDAP Models [Page 11]
738 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
742 any auxiliary object class.
745 The set of auxiliary object classes which an entry belongs to can
750 2.5. Attribute Descriptions
753 An attribute description is composed of an attribute type (see Section
754 2.5.1) and a set of zero or more attribute options (see Section
758 An attribute description is represented by the ABNF:
761 attributedescription = attributetype options
763 options = *( SEMI option )
767 where <attributetype> identifies the attribute type and each <option>
768 identifies an attribute option. Both <attributetype> and <option>
769 productions are case insensitive. The order in which <option>s appear
770 is irrelevant. That is, any two <attributedescription>s which consist
771 of the same <attributetype> and same set of <option>s are equivalent.
774 Examples of valid attribute descriptions:
782 An attribute description with an unrecognized attribute type is to be
783 treated as unrecognized. Servers SHALL treat an attribute description
784 with an unrecognized attribute option as unrecognized. Clients MAY
785 treat an unrecognized attribute option as a tagging option (see
789 All attributes of an entry must have distinct attribute descriptions.
793 2.5.1. Attribute Types
796 An attribute type governs whether the attribute can have multiple
797 values, the syntax and matching rules used to construct and compare
798 values of that attribute, and other functions.
801 If no equality matching is specified for the attribute type:
802 - the attribute (of the type) cannot be used for naming;
807 Zeilenga LDAP Models [Page 12]
808 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
812 - when adding the attribute (or replacing all values), no two values
813 may be equivalent (see 2.2);
814 - individual values of a multi-valued attribute are not to be
815 independently added or deleted;
816 - attribute value assertions (such as matching in search filters and
817 comparisons) using values of such a type cannot be performed.
820 Otherwise, the equality matching rule is to be used for the purposes
821 of evaluating attribute value assertions concerning the attribute
825 The attribute type indicates whether the attribute is a user attribute
826 or an operational attribute. If operational, the attribute type
827 indicates the operational usage and whether the attribute is
828 modifiable by users or not. Operational attributes are discussed in
832 An attribute type (a subtype) may derive from a more generic attribute
833 type (a direct supertype). The following restrictions apply to
835 - a subtype must have the same usage as its direct supertype,
836 - a subtype's syntax must be the same, or a refinement of, its
837 supertype's syntax, and
838 - a subtype must be collective [RFC3671] if its supertype is
842 An attribute description consisting of a subtype and no options is
843 said to be the direct description subtype of the attribute description
844 consisting of the subtype's direct supertype and no options.
847 Each attribute type is identified by an object identifier (OID) and,
848 optionally, one or more short names (descriptors).
852 2.5.2. Attribute Options
855 There are multiple kinds of attribute description options. The LDAP
856 technical specification details one kind: tagging options.
859 Not all options can be associated with attributes held in the
860 directory. Tagging options can be.
863 Not all options can be used in conjunction with all attribute types.
864 In such cases, the attribute description is to be treated as
868 An attribute description that contains mutually exclusive options
869 shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
874 Zeilenga LDAP Models [Page 13]
875 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
879 "x-foo" and "x-bar" are mutually exclusive, is to be treated as
883 Other kinds of options may be specified in future documents. These
884 documents must detail how new kinds of options they define relate to
885 tagging options. In particular, these documents must detail whether
886 or not new kinds of options can be associated with attributes held in
887 the directory, how new kinds of options affect transfer of attribute
888 values, and how new kinds of options are treated in attribute
889 description hierarchies.
892 Options are represented as short case insensitive textual strings
893 conforming to the <option> production defined in Section 2.5 of this
897 Procedures for registering options are detailed in BCP 64 [BCP64bis].
901 2.5.2.1. Tagging Options
904 Attributes held in the directory can have attribute descriptions with
905 any number of tagging options. Tagging options are never mutually
909 An attribute description with N tagging options is a direct
910 (description) subtype of all attribute descriptions of the same
911 attribute type and all but one of the N options. If the attribute
912 type has a supertype, then the attribute description is also a direct
913 (description) subtype of the attribute description of the supertype
914 and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
915 (description) subtype of 'cn;lang-de', 'cn;lang-en', and
916 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
921 2.5.3. Attribute Description Hierarchies
924 An attribute description can be the direct subtype of zero or more
925 other attribute descriptions as indicated by attribute type subtyping
926 (as described in Section 2.5.1) or attribute tagging option subtyping
927 (as described in Section 2.5.2.1). These subtyping relationships are
928 used to form hierarchies of attribute descriptions and attributes.
931 As adapted from [X.501]:
934 Attribute hierarchies allow access to the DIB with varying degrees
935 of granularity. This is achieved by allowing the value components
936 of attributes to be accessed by using either their specific
941 Zeilenga LDAP Models [Page 14]
942 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
946 attribute description (a direct reference to the attribute) or by
947 a more generic attribute description (an indirect reference).
950 Semantically related attributes may be placed in a hierarchical
951 relationship, the more specialized being placed subordinate to the
952 more generalized. Searching for, or retrieving attributes and
953 their values is made easier by quoting the more generalized
954 attribute description; a filter item so specified is evaluated for
955 the more specialized descriptions as well as for the quoted
959 Where subordinate specialized descriptions are selected to be
960 returned as part of a search result these descriptions shall be
961 returned if available. Where the more general descriptions are
962 selected to be returned as part of a search result both the
963 general and the specialized descriptions shall be returned, if
964 available. An attribute value shall always be returned as a value
965 of its own attribute description.
968 All of the attribute descriptions in an attribute hierarchy are
969 treated as distinct and unrelated descriptions for user
970 modification of entry content.
973 An attribute value stored in an object or alias entry is of
974 precisely one attribute description. The description is indicated
975 when the value is originally added to the entry.
978 For the purpose of subschema administration of the entry, a
979 specification that an attribute is required is fulfilled if the entry
980 contains a value of an attribute description belonging to an attribute
981 hierarchy where the attribute type of that description is the same as
982 the required attribute's type. That is, a "MUST name" specification
983 is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
984 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
985 'name'). Likewise, an entry may contain a value of an attribute
986 description belonging to an attribute hierarchy where the attribute
987 type of that description is either explicitly included in the
988 definition of an object class to which the entry belongs or allowed by
989 the DIT content rule applicable to that entry. That is, 'name' and
990 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
991 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
995 For the purposes of other policy administration, unless stated
996 otherwise in the specification of the particular administrative model,
997 all of the attribute descriptions in an attribute hierarchy are
998 treated as distinct and unrelated descriptions.
1004 Zeilenga LDAP Models [Page 15]
1005 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1012 As adapted from [X.501]:
1015 An alias, or an alias name, for an object is an alternative name
1016 for an object or object entry which is provided by the use of
1020 Each alias entry contains, within the 'aliasedObjectName'
1021 attribute (known as the 'aliasedEntryName' attribute in X.500]), a
1022 name of some object. The distinguished name of the alias entry is
1023 thus also a name for this object.
1026 NOTE - The name within the 'aliasedObjectName' is said to be
1027 pointed to by the alias. It does not have to be the
1028 distinguished name of any entry.
1031 The conversion of an alias name to an object name is termed
1032 (alias) dereferencing and comprises the systematic replacement of
1033 alias names, where found within a purported name, by the value of
1034 the corresponding 'aliasedObjectName' attribute. The process may
1035 require the examination of more than one alias entry.
1038 Any particular entry in the DIT may have zero or more alias names.
1039 It therefore follows that several alias entries may point to the
1040 same entry. An alias entry may point to an entry that is not a
1041 leaf entry and may point to another alias entry.
1044 An alias entry shall have no subordinates, so that an alias entry
1045 is always a leaf entry.
1048 Every alias entry shall belong to the 'alias' object class.
1051 An entry with the 'alias' object class must also belong to an object
1052 class (or classes), or be governed by a DIT content rule, which allows
1053 suitable naming attributes to be present.
1057 dn: cn=bar,dc=example,dc=com
1060 objectClass: extensibleObject
1062 aliasedObjectName: cn=foo,dc=example,dc=com
1066 2.6.1. 'alias' object class
1072 Zeilenga LDAP Models [Page 16]
1073 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1077 Alias entries belong to the 'alias' object class.
1080 ( 2.5.6.1 NAME 'alias'
1082 MUST aliasedObjectName )
1086 2.6.2. 'aliasedObjectName' attribute type
1089 The 'aliasedObjectName' attribute holds the name of the entry an alias
1090 points to. The 'aliasedObjectName' attribute is known as the
1091 'aliasedEntryName' attribute in X.500.
1094 ( 2.5.4.1 NAME 'aliasedObjectName'
1095 EQUALITY distinguishedNameMatch
1096 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1100 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1101 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1105 3. Directory Administrative and Operational Information
1108 This section discusses select aspects of the X.500 Directory
1109 Administrative and Operational Information model [X.501]. LDAP
1110 implementations MAY support other aspects of this model.
1117 As defined in [X.501]:
1120 A subtree is a collection of object and alias entries situated at
1121 the vertices of a tree. Subtrees do not contain subentries. The
1122 prefix sub, in subtree, emphasizes that the base (or root) vertex
1123 of this tree is usually subordinate to the root of the DIT.
1126 A subtree begins at some vertex and extends to some identifiable
1127 lower boundary, possibly extending to leaves. A subtree is always
1128 defined within a context which implicitly bounds the subtree. For
1129 example, the vertex and lower boundaries of a subtree defining a
1130 replicated area are bounded by a naming context.
1137 A subentry is a "special sort of entry, known by the Directory, used
1142 Zeilenga LDAP Models [Page 17]
1143 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1147 to hold information associated with a subtree or subtree refinement"
1148 [X.501]. Subentries are used in Directory to hold for administrative
1149 and operational purposes as defined in [X.501]. Their use in LDAP is
1150 detailed in [RFC3672].
1153 The term "(sub)entry" in this specification indicates that servers
1154 implementing X.500(93) models are, in accordance with X.500(93) as
1155 described in [RFC3672], to use a subentry and that other servers are
1156 to use an object entry belonging to the appropriate auxiliary class
1157 normally used with the subentry (e.g., 'subschema' for subschema
1158 subentries) to mimic the subentry. This object entry's RDN SHALL be
1159 formed from a value of the 'cn' (commonName) attribute [Schema] (as
1160 all subentries are named with 'cn').
1164 3.3. The 'objectClass' attribute
1167 Each entry in the DIT has an 'objectClass' attribute.
1170 ( 2.5.4.0 NAME 'objectClass'
1171 EQUALITY objectIdentifierMatch
1172 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
1175 The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
1176 (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
1179 The 'objectClass' attribute specifies the object classes of an entry,
1180 which (among other things) is used in conjunction with the controlling
1181 schema to determine the permitted attributes of an entry. Values of
1182 this attribute can be modified by clients, but the 'objectClass'
1183 attribute cannot be removed.
1186 Servers which follow X.500(93) models SHALL restrict modifications of
1187 this attribute to prevent the basic structural class of the entry from
1188 being changed. That is, one cannot change a 'person' into a
1192 When creating an entry or adding an 'objectClass' value to an entry,
1193 all superclasses of the named classes SHALL be implicitly added as
1194 well if not already present. That is, if the auxiliary class 'x-a' is
1195 a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
1196 'x-b' to be implicitly added (if is not already present).
1199 Servers SHALL restrict modifications of this attribute to prevent
1200 superclasses of remaining 'objectClass' values from being deleted.
1201 That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
1202 class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
1203 an attempt to delete only 'x-b' from the 'objectClass' attribute is an
1208 Zeilenga LDAP Models [Page 18]
1209 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1217 3.4. Operational attributes
1220 Some attributes, termed operational attributes, are used or maintained
1221 by servers for administrative and operational purposes. As stated in
1222 [X.501]: "There are three varieties of operational attributes:
1223 Directory operational attributes, DSA-shared operational attributes,
1224 and DSA-specific operational attributes."
1227 A directory operational attribute is used to represent operational
1228 and/or administrative information in the Directory Information Model.
1229 This includes operational attributes maintained by the server (e.g.
1230 'createTimestamp') as well as operational attributes which hold values
1231 administrated by the user (e.g. 'ditContentRules').
1234 A DSA-shared operational attribute is used to represent information of
1235 the DSA Information Model which is shared between DSAs.
1238 A DSA-specific operational attribute is used to represent information
1239 of the DSA Information Model which is specific to the DSA (though, in
1240 some cases, may be derived from information shared between DSAs)
1241 (e.g., 'namingContexts').
1244 The DSA Information Model operational attributes are detailed in
1248 Operational attributes are not normally visible. They are not
1249 returned in search results unless explicitly requested by name.
1252 Not all operational attributes are user modifiable.
1255 Entries may contain, among others, the following operational
1259 - creatorsName: the Distinguished Name of the user who added this
1260 entry to the directory,
1263 - createTimestamp: the time this entry was added to the directory,
1266 - modifiersName: the Distinguished Name of the user who last
1267 modified this entry, and
1270 - modifyTimestamp: the time this entry was last modified.
1273 Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
1274 'modifiersName', and 'modifyTimestamp' attributes for all entries of
1279 Zeilenga LDAP Models [Page 19]
1280 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1288 3.4.1. 'creatorsName'
1291 This attribute appears in entries which were added using the protocol
1292 (e.g., using the Add operation). The value is the distinguished name
1296 ( 2.5.18.3 NAME 'creatorsName'
1297 EQUALITY distinguishedNameMatch
1298 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1299 SINGLE-VALUE NO-USER-MODIFICATION
1300 USAGE directoryOperation )
1303 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1304 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1308 3.4.2. 'createTimestamp'
1311 This attribute appears in entries which were added using the protocol
1312 (e.g., using the Add operation). The value is the time the entry was
1316 ( 2.5.18.1 NAME 'createTimestamp'
1317 EQUALITY generalizedTimeMatch
1318 ORDERING generalizedTimeOrderingMatch
1319 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1320 SINGLE-VALUE NO-USER-MODIFICATION
1321 USAGE directoryOperation )
1324 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1325 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1326 are defined in [Syntaxes].
1330 3.4.3. 'modifiersName'
1333 This attribute appears in entries which have been modified using the
1334 protocol (e.g., using Modify operation). The value is the
1335 distinguished name of the last modifier.
1338 ( 2.5.18.4 NAME 'modifiersName'
1339 EQUALITY distinguishedNameMatch
1340 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1341 SINGLE-VALUE NO-USER-MODIFICATION
1342 USAGE directoryOperation )
1347 Zeilenga LDAP Models [Page 20]
1348 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1352 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1353 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1357 3.4.4. 'modifyTimestamp'
1360 This attribute appears in entries which have been modified using the
1361 protocol (e.g., using the Modify operation). The value is the time
1362 the entry was last modified.
1365 ( 2.5.18.2 NAME 'modifyTimestamp'
1366 EQUALITY generalizedTimeMatch
1367 ORDERING generalizedTimeOrderingMatch
1368 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1369 SINGLE-VALUE NO-USER-MODIFICATION
1370 USAGE directoryOperation )
1373 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1374 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1375 are defined in [Syntaxes].
1379 3.4.5. 'structuralObjectClass'
1382 This attribute indicates the structural object class of the entry.
1385 ( 2.5.21.9 NAME 'structuralObjectClass'
1386 EQUALITY objectIdentifierMatch
1387 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
1388 SINGLE-VALUE NO-USER-MODIFICATION
1389 USAGE directoryOperation )
1392 The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
1393 (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
1397 3.4.6. 'governingStructureRule'
1400 This attribute indicates the structure rule governing the entry.
1403 ( 2.5.21.10 NAME 'governingStructureRule'
1404 EQUALITY integerMatch
1405 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1406 SINGLE-VALUE NO-USER-MODIFICATION
1407 USAGE directoryOperation )
1410 The 'integerMatch' matching rule and INTEGER
1411 (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
1416 Zeilenga LDAP Models [Page 21]
1417 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1424 As defined in [X.501]:
1427 The Directory Schema is a set of definitions and constraints
1428 concerning the structure of the DIT, the possible ways entries are
1429 named, the information that can be held in an entry, the
1430 attributes used to represent that information and their
1431 organization into hierarchies to facilitate search and retrieval
1432 of the information and the ways in which values of attributes may
1433 be matched in attribute value and matching rule assertions.
1436 NOTE 1 - The schema enables the Directory system to, for example:
1439 - prevent the creation of subordinate entries of the wrong
1440 object-class (e.g. a country as a subordinate of a person);
1443 - prevent the addition of attribute-types to an entry
1444 inappropriate to the object-class (e.g. a serial number to a
1448 - prevent the addition of an attribute value of a syntax not
1449 matching that defined for the attribute-type (e.g. a printable
1450 string to a bit string).
1453 Formally, the Directory Schema comprises a set of:
1456 a) Name Form definitions that define primitive naming relations
1457 for structural object classes;
1460 b) DIT Structure Rule definitions that define the names that
1461 entries may have and the ways in which the entries may be
1462 related to one another in the DIT;
1465 c) DIT Content Rule definitions that extend the specification of
1466 allowable attributes for entries beyond those indicated by the
1467 structural object classes of the entries;
1470 d) Object Class definitions that define the basic set of mandatory
1471 and optional attributes that shall be present, and may be
1472 present, respectively, in an entry of a given class, and which
1473 indicate the kind of object class that is being defined;
1476 e) Attribute Type definitions that identify the object identifier
1477 by which an attribute is known, its syntax, associated matching
1478 rules, whether it is an operational attribute and if so its
1479 type, whether it is a collective attribute, whether it is
1480 permitted to have multiple values and whether or not it is
1485 Zeilenga LDAP Models [Page 22]
1486 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1490 derived from another attribute type;
1493 f) Matching Rule definitions that define matching rules.
1499 g) LDAP Syntax definitions that define encodings used in LDAP.
1503 4.1. Schema Definitions
1506 Schema definitions in this section are described using ABNF and rely
1507 on the common productions specified in Section 1.2 as well as these:
1510 noidlen = numericoid [ LCURLY len RCURLY ]
1514 oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
1515 oidlist = oid *( WSP DOLLAR WSP oid )
1518 extensions = *( SP xstring SP qdstrings )
1519 xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
1522 qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
1523 qdescrlist = [ qdescr *( SP qdescr ) ]
1524 qdescr = SQUOTE descr SQUOTE
1527 qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
1528 qdstringlist = [ qdstring *( SP qdstring ) ]
1529 qdstring = SQUOTE dstring SQUOTE
1530 dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
1533 QQ = ESC %x32 %x37 ; "\27"
1534 QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
1537 ; Any UTF-8 encoded Unicode character
1538 ; except %x27 ("'") and %x5C ("\")
1539 QUTF8 = QUTF1 / UTFMB
1542 ; Any ASCII character except %x27 ("'") and %x5C ("\")
1543 QUTF1 = %x00-26 / %x28-5B / %x5D-7F
1546 Schema definitions in this section also share a number of common
1550 The NAME field provides a set of short names (descriptors) which are
1551 to be used as aliases for the OID.
1557 Zeilenga LDAP Models [Page 23]
1558 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1562 The DESC field optionally allows a descriptive string to be provided
1563 by the directory administrator and/or implementor. While
1564 specifications may suggest a descriptive string, there is no
1565 requirement that the suggested (or any) descriptive string be used.
1568 The OBSOLETE field, if present, indicates the element is not active.
1571 Implementors should note that future versions of this document may
1572 expand these definitions to include additional terms. Terms whose
1573 identifier begins with "X-" are reserved for private experiments, and
1574 are followed by <SP> and <qdstrings> tokens.
1578 4.1.1. Object Class Definitions
1581 Object Class definitions are written according to the ABNF:
1584 ObjectClassDescription = LPAREN WSP
1585 numericoid ; object identifier
1586 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1587 [ SP "DESC" SP qdstring ] ; description
1588 [ SP "OBSOLETE" ] ; not active
1589 [ SP "SUP" SP oids ] ; superior object classes
1590 [ SP kind ] ; kind of class
1591 [ SP "MUST" SP oids ] ; attribute types
1592 [ SP "MAY" SP oids ] ; attribute types
1593 extensions WSP RPAREN
1596 kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
1600 <numericoid> is object identifier assigned to this object class;
1601 NAME <qdescrs> are short names (descriptors) identifying this object
1603 DESC <qdstring> is a short descriptive string;
1604 OBSOLETE indicates this object class is not active;
1605 SUP <oids> specifies the direct superclasses of this object class;
1606 the kind of object class is indicated by one of ABSTRACT,
1607 STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
1608 MUST and MAY specify the sets of required and allowed attribute
1609 types, respectively; and
1610 <extensions> describe extensions.
1614 4.1.2. Attribute Types
1617 Attribute Type definitions are written according to the ABNF:
1623 Zeilenga LDAP Models [Page 24]
1624 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1628 AttributeTypeDescription = LPAREN WSP
1629 numericoid ; object identifier
1630 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1631 [ SP "DESC" SP qdstring ] ; description
1632 [ SP "OBSOLETE" ] ; not active
1633 [ SP "SUP" SP oid ] ; supertype
1634 [ SP "EQUALITY" SP oid ] ; equality matching rule
1635 [ SP "ORDERING" SP oid ] ; ordering matching rule
1636 [ SP "SUBSTR" SP oid ] ; substrings matching rule
1637 [ SP "SYNTAX" SP noidlen ] ; value syntax
1638 [ SP "SINGLE-VALUE" ] ; single-value
1639 [ SP "COLLECTIVE" ] ; collective
1640 [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
1641 [ SP "USAGE" SP usage ] ; usage
1642 extensions WSP RPAREN ; extensions
1645 usage = "userApplications" / ; user
1646 "directoryOperation" / ; directory operational
1647 "distributedOperation" / ; DSA-shared operational
1648 "dSAOperation" ; DSA-specific operational
1652 <numericoid> is object identifier assigned to this attribute type;
1653 NAME <qdescrs> are short names (descriptors) identifying this
1655 DESC <qdstring> is a short descriptive string;
1656 OBSOLETE indicates this attribute type is not active;
1657 SUP oid specifies the direct supertype of this type;
1658 EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
1659 ordering, and substrings matching rules, respectively;
1660 SYNTAX identifies value syntax by object identifier and may suggest
1661 a minimum upper bound;
1662 SINGLE-VALUE indicates attributes of this type are restricted to a
1664 COLLECTIVE indicates this attribute type is collective
1666 NO-USER-MODIFICATION indicates this attribute type is not user
1668 USAGE indicates the application of this attribute type; and
1669 <extensions> describe extensions.
1672 Each attribute type description must contain at least one of the SUP
1673 or SYNTAX fields. If no SYNTAX field is provided, the attribute type
1674 description takes its value from the supertype.
1677 If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
1678 fields, if not specified, take their value from the supertype.
1684 Zeilenga LDAP Models [Page 25]
1685 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1689 Usage of userApplications, the default, indicates that attributes of
1690 this type represent user information. That is, they are user
1694 A usage of directoryOperation, distributedOperation, or dSAOperation
1695 indicates that attributes of this type represent operational and/or
1696 administrative information. That is, they are operational attributes.
1699 directoryOperation usage indicates that the attribute of this type is
1700 a directory operational attribute. distributedOperation usage
1701 indicates that the attribute of this DSA-shared usage operational
1702 attribute. dSAOperation usage indicates that the attribute of this
1703 type is a DSA-specific operational attribute.
1706 COLLECTIVE requires usage userApplications. Use of collective
1707 attribute types in LDAP is discussed in [RFC3671].
1710 NO-USER-MODIFICATION requires an operational usage.
1713 Note that the <AttributeTypeDescription> does not list the matching
1714 rules which can be used with that attribute type in an extensibleMatch
1715 search filter [Protocol]. This is done using the 'matchingRuleUse'
1716 attribute described in Section 4.1.4.
1719 This document refines the schema description of X.501 by requiring
1720 that the SYNTAX field in an <AttributeTypeDescription> be a string
1721 representation of an object identifier for the LDAP string syntax
1722 definition with an optional indication of the suggested minimum bound
1723 of a value of this attribute.
1726 A suggested minimum upper bound on the number of characters in a value
1727 with a string-based syntax, or the number of bytes in a value for all
1728 other syntaxes, may be indicated by appending this bound count inside
1729 of curly braces following the syntax's OBJECT IDENTIFIER in an
1730 Attribute Type Description. This bound is not part of the syntax name
1731 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
1732 implementations should allow a string to be 64 characters long,
1733 although they may allow longer strings. Note that a single character
1734 of the Directory String syntax may be encoded in more than one octet
1735 since UTF-8 [RFC3629] is a variable-length encoding.
1739 4.1.3. Matching Rules
1742 Matching rules are used in performance of attribute value assertions,
1743 such as in performance of a Compare operation. They are also used in
1744 evaluation of a Search filters, in determining which individual values
1745 are be added or deleted during performance of a Modify operation, and
1750 Zeilenga LDAP Models [Page 26]
1751 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1755 used in comparison of distinguished names.
1758 Each matching rule is identified by an object identifier (OID) and,
1759 optionally, one or more short names (descriptors).
1762 Matching rule definitions are written according to the ABNF:
1765 MatchingRuleDescription = LPAREN WSP
1766 numericoid ; object identifier
1767 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1768 [ SP "DESC" SP qdstring ] ; description
1769 [ SP "OBSOLETE" ] ; not active
1770 SP "SYNTAX" SP numericoid ; assertion syntax
1771 extensions WSP RPAREN ; extensions
1775 <numericoid> is object identifier assigned to this matching rule;
1776 NAME <qdescrs> are short names (descriptors) identifying this
1778 DESC <qdstring> is a short descriptive string;
1779 OBSOLETE indicates this matching rule is not active;
1780 SYNTAX identifies the assertion syntax (the syntax of the assertion
1781 value) by object identifier; and
1782 <extensions> describe extensions.
1786 4.1.4. Matching Rule Uses
1789 A matching rule use lists the attributes which are suitable for use
1790 with an extensibleMatch search filter.
1793 Matching rule use descriptions are written according to the following
1797 MatchingRuleUseDescription = LPAREN WSP
1798 numericoid ; object identifier
1799 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1800 [ SP "DESC" SP qdstring ] ; description
1801 [ SP "OBSOLETE" ] ; not active
1802 SP "APPLIES" SP oids ; attribute types
1803 extensions WSP RPAREN ; extensions
1807 <numericoid> is the object identifier of the matching rule
1808 associated with this matching rule use description;
1809 NAME <qdescrs> are short names (descriptors) identifying this
1811 DESC <qdstring> is a short descriptive string;
1816 Zeilenga LDAP Models [Page 27]
1817 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1821 OBSOLETE indicates this matching rule use is not active;
1822 APPLIES provides a list of attribute types the matching rule applies
1824 <extensions> describe extensions.
1828 4.1.5. LDAP Syntaxes
1831 LDAP Syntaxes of (attribute and assertion) values are described in
1832 terms of ASN.1 [X.680] and, optionally, have an octet string encoding
1833 known as the LDAP-specific encoding. Commonly, the LDAP-specific
1834 encoding is constrained to a string of Unicode [Unicode] characters in
1835 UTF-8 [RFC3629] form.
1838 Each LDAP syntax is identified by an object identifier (OID).
1841 LDAP syntax definitions are written according to the ABNF:
1844 SyntaxDescription = LPAREN WSP
1845 numericoid ; object identifier
1846 [ SP "DESC" SP qdstring ] ; description
1847 extensions WSP RPAREN ; extensions
1851 <numericoid> is the object identifier assigned to this LDAP syntax;
1852 DESC <qdstring> is a short descriptive string; and
1853 <extensions> describe extensions.
1857 4.1.6. DIT Content Rules
1860 A DIT content rule is a "rule governing the content of entries of a
1861 particular structural object class" [X.501].
1864 For DIT entries of a particular structural object class, a DIT content
1865 rule specifies which auxiliary object classes the entries are allowed
1866 to belong to and which additional attributes (by type) are required,
1867 allowed or not allowed to appear in the entries.
1870 The list of precluded attributes cannot include any attribute listed
1871 as mandatory in the rule, the structural object class, or any of the
1872 allowed auxiliary object classes.
1875 Each content rule is identified by the object identifier, as well as
1876 any short names (descriptors), of the structural object class it
1880 An entry may only belong to auxiliary object classes listed in the
1885 Zeilenga LDAP Models [Page 28]
1886 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1890 governing content rule.
1893 An entry must contain all attributes required by the object classes
1894 the entry belongs to as well as all attributes required by the
1895 governing content rule.
1898 An entry may contain any non-precluded attributes allowed by the
1899 object classes the entry belongs to as well as all attributes allowed
1900 by the governing content rule.
1903 An entry cannot include any attribute precluded by the governing
1907 An entry is governed by (if present and active in the subschema) the
1908 DIT content rule which applies to the structural object class of the
1909 entry (see Section 2.4.2). If no active rule is present for the
1910 entry's structural object class, the entry's content is governed by
1911 the structural object class (and possibly other aspects of user and
1912 system schema). DIT content rules for superclasses of the structural
1913 object class of an entry are not applicable to that entry.
1916 DIT content rule descriptions are written according to the ABNF:
1919 DITContentRuleDescription = LPAREN WSP
1920 numericoid ; object identifier
1921 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1922 [ SP "DESC" SP qdstring ] ; description
1923 [ SP "OBSOLETE" ] ; not active
1924 [ SP "AUX" SP oids ] ; auxiliary object classes
1925 [ SP "MUST" SP oids ] ; attribute types
1926 [ SP "MAY" SP oids ] ; attribute types
1927 [ SP "NOT" SP oids ] ; attribute types
1928 extensions WSP RPAREN ; extensions
1932 <numericoid> is the object identifier of the structural object class
1933 associated with this DIT content rule;
1934 NAME <qdescrs> are short names (descriptors) identifying this DIT
1936 DESC <qdstring> is a short descriptive string;
1937 OBSOLETE indicates this DIT content rule use is not active;
1938 AUX specifies a list of auxiliary object classes which entries
1939 subject to this DIT content rule may belong to;
1940 MUST, MAY, and NOT specify lists of attribute types which are
1941 required, allowed, or precluded, respectively, from appearing in
1942 entries subject to this DIT content rule; and
1943 <extensions> describe extensions.
1949 Zeilenga LDAP Models [Page 29]
1950 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
1954 4.1.7. DIT Structure Rules and Name Forms
1957 It is sometimes desirable to regulate where object and alias entries
1958 can be placed in the DIT and how they can be named based upon their
1959 structural object class.
1963 4.1.7.1. DIT Structure Rules
1966 A DIT structure rule is a "rule governing the structure of the DIT by
1967 specifying a permitted superior to subordinate entry relationship. A
1968 structure rule relates a name form, and therefore a structural object
1969 class, to superior structure rules. This permits entries of the
1970 structural object class identified by the name form to exist in the
1971 DIT as subordinates to entries governed by the indicated superior
1972 structure rules" [X.501].
1975 DIT structure rule descriptions are written according to the ABNF:
1978 DITStructureRuleDescription = LPAREN WSP
1979 ruleid ; rule identifier
1980 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1981 [ SP "DESC" SP qdstring ] ; description
1982 [ SP "OBSOLETE" ] ; not active
1983 SP "FORM" SP oid ; NameForm
1984 [ SP "SUP" ruleids ] ; superior rules
1985 extensions WSP RPAREN ; extensions
1988 ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
1989 ruleidlist = ruleid *( SP ruleid )
1994 <ruleid> is the rule identifier of this DIT structure rule;
1995 NAME <qdescrs> are short names (descriptors) identifying this DIT
1997 DESC <qdstring> is a short descriptive string;
1998 OBSOLETE indicates this DIT structure rule use is not active;
1999 FORM is specifies the name form associated with this DIT structure
2001 SUP identifies superior rules (by rule id); and
2002 <extensions> describe extensions.
2005 If no superior rules are identified, the DIT structure rule applies
2006 to an autonomous administrative point (e.g. the root vertex of the
2007 subtree controlled by the subschema) [X.501].
2014 Zeilenga LDAP Models [Page 30]
2015 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2022 A name form "specifies a permissible RDN for entries of a particular
2023 structural object class. A name form identifies a named object
2024 class and one or more attribute types to be used for naming (i.e.
2025 for the RDN). Name forms are primitive pieces of specification
2026 used in the definition of DIT structure rules" [X.501].
2029 Each name form indicates the structural object class to be named,
2030 a set of required attribute types, and a set of allowed attribute
2031 types. A particular attribute type cannot be in both sets.
2034 Entries governed by the form must be named using a value from each
2035 required attribute type and zero or more values from the allowed
2039 Each name form is identified by an object identifier (OID) and,
2040 optionally, one or more short names (descriptors).
2043 Name form descriptions are written according to the ABNF:
2046 NameFormDescription = LPAREN WSP
2047 numericoid ; object identifier
2048 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
2049 [ SP "DESC" SP qdstring ] ; description
2050 [ SP "OBSOLETE" ] ; not active
2051 SP "OC" SP oid ; structural object class
2052 SP "MUST" SP oids ; attribute types
2053 [ SP "MAY" SP oids ] ; attribute types
2054 extensions WSP RPAREN ; extensions
2058 <numericoid> is object identifier which identifies this name form;
2059 NAME <qdescrs> are short names (descriptors) identifying this name
2061 DESC <qdstring> is a short descriptive string;
2062 OBSOLETE indicates this name form is not active;
2063 OC identifies the structural object class this rule applies to,
2064 MUST and MAY specify the sets of required and allowed, respectively,
2065 naming attributes for this name form; and
2066 <extensions> describe extensions.
2069 All attribute types in the required ("MUST") and allowed ("MAY") lists
2074 4.2. Subschema Subentries
2080 Zeilenga LDAP Models [Page 31]
2081 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2085 Subschema (sub)entries are used for administering information about
2086 the directory schema. A single subschema (sub)entry contains all
2087 schema definitions (see Section 4.1) used by entries in a particular
2088 part of the directory tree.
2091 Servers which follow X.500(93) models SHOULD implement subschema using
2092 the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
2093 and so these are not ordinary object entries but subentries (see
2094 Section 3.2). LDAP clients SHOULD NOT assume that servers implement
2095 any of the other aspects of X.500 subschema.
2098 Servers MAY allow subschema modification. Procedures for subschema
2099 modification are discussed in Section 14.5 of [X.501].
2102 A server which masters entries and permits clients to modify these
2103 entries SHALL implement and provide access to these subschema
2104 (sub)entries including providing a 'subschemaSubentry' attribute in
2105 each modifiable entry. This is so clients may discover the attributes
2106 and object classes which are permitted to be present. It is strongly
2107 RECOMMENDED that all other servers implement this as well.
2110 The value of the 'subschemaSubentry' attribute is the name of the
2111 subschema (sub)entry holding the subschema controlling the entry.
2114 ( 2.5.18.10 NAME 'subschemaSubentry'
2115 EQUALITY distinguishedNameMatch
2116 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2117 NO-USER-MODIFICATION SINGLE-VALUE
2118 USAGE directoryOperation )
2121 The 'distinguishedNameMatch' matching rule and the DistinguishedName
2122 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
2125 Subschema is held in (sub)entries belonging to the subschema auxiliary
2129 ( 2.5.20.1 NAME 'subschema' AUXILIARY
2130 MAY ( dITStructureRules $ nameForms $ ditContentRules $
2131 objectClasses $ attributeTypes $ matchingRules $
2135 The 'ldapSyntaxes' operational attribute may also be present in
2139 Servers MAY provide additional attributes (described in other
2140 documents) in subschema (sub)entries.
2143 Servers SHOULD provide the attributes 'createTimestamp' and
2148 Zeilenga LDAP Models [Page 32]
2149 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2153 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
2154 to maintain their caches of schema information.
2157 The following subsections provide attribute type definitions for each
2158 of schema definition attribute types.
2162 4.2.1. 'objectClasses'
2165 This attribute holds definitions of object classes.
2168 ( 2.5.21.6 NAME 'objectClasses'
2169 EQUALITY objectIdentifierFirstComponentMatch
2170 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
2171 USAGE directoryOperation )
2174 The 'objectIdentifierFirstComponentMatch' matching rule and the
2175 ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
2176 defined in [Syntaxes].
2180 4.2.2. 'attributeTypes'
2183 This attribute holds definitions of attribute types.
2186 ( 2.5.21.5 NAME 'attributeTypes'
2187 EQUALITY objectIdentifierFirstComponentMatch
2188 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
2189 USAGE directoryOperation )
2192 The 'objectIdentifierFirstComponentMatch' matching rule and the
2193 AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
2194 defined in [Syntaxes].
2198 4.2.3. 'matchingRules'
2201 This attribute holds definitions of matching rules.
2204 ( 2.5.21.4 NAME 'matchingRules'
2205 EQUALITY objectIdentifierFirstComponentMatch
2206 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
2207 USAGE directoryOperation )
2210 The 'objectIdentifierFirstComponentMatch' matching rule and the
2211 MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
2212 defined in [Syntaxes].
2218 Zeilenga LDAP Models [Page 33]
2219 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2223 4.2.4 'matchingRuleUse'
2226 This attribute holds definitions of matching rule uses.
2229 ( 2.5.21.8 NAME 'matchingRuleUse'
2230 EQUALITY objectIdentifierFirstComponentMatch
2231 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
2232 USAGE directoryOperation )
2235 The 'objectIdentifierFirstComponentMatch' matching rule and the
2236 MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
2237 defined in [Syntaxes].
2241 4.2.5. 'ldapSyntaxes'
2244 This attribute holds definitions of LDAP syntaxes.
2247 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
2248 EQUALITY objectIdentifierFirstComponentMatch
2249 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
2250 USAGE directoryOperation )
2253 The 'objectIdentifierFirstComponentMatch' matching rule and the
2254 SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
2259 4.2.6. 'dITContentRules'
2262 This attribute lists DIT Content Rules which are present in the
2266 ( 2.5.21.2 NAME 'dITContentRules'
2267 EQUALITY objectIdentifierFirstComponentMatch
2268 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
2269 USAGE directoryOperation )
2272 The 'objectIdentifierFirstComponentMatch' matching rule and the
2273 DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
2274 defined in [Syntaxes].
2278 4.2.7. 'dITStructureRules'
2281 This attribute lists DIT Structure Rules which are present in the
2288 Zeilenga LDAP Models [Page 34]
2289 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2293 ( 2.5.21.1 NAME 'dITStructureRules'
2294 EQUALITY integerFirstComponentMatch
2295 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
2296 USAGE directoryOperation )
2299 The 'integerFirstComponentMatch' matching rule and the
2300 DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
2301 defined in [Syntaxes].
2308 This attribute lists Name Forms which are in force.
2311 ( 2.5.21.7 NAME 'nameForms'
2312 EQUALITY objectIdentifierFirstComponentMatch
2313 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
2314 USAGE directoryOperation )
2317 The 'objectIdentifierFirstComponentMatch' matching rule and the
2318 NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
2323 4.3. 'extensibleObject' object class
2326 The 'extensibleObject' auxiliary object class allows entries that
2327 belong to it to hold any user attribute. The set of allowed attribute
2328 types of this object class is implicitly the set of all attribute
2329 types of userApplications usage.
2332 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
2336 The mandatory attributes of the other object classes of this entry are
2337 still required to be present and any precluded attributes are still
2338 not allowed to be present.
2343 4.4. Subschema Discovery
2346 To discover the DN of the subschema (sub)entry holding the subschema
2347 controlling a particular entry, a client reads that entry's
2348 'subschemaSubentry' operational attribute. To read schema attributes
2349 from the subschema (sub)entry, clients MUST issue a Search operation
2350 [Protocol] where baseObject is the DN of the subschema (sub)entry,
2351 scope is baseObject, filter is "(objectClass=subschema)" [Filters],
2356 Zeilenga LDAP Models [Page 35]
2357 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2361 and attributes field lists the names of the desired schema attributes
2362 (as they are operational). Note: the "(objectClass=subschema)" filter
2363 allows LDAP servers which gateway to X.500 to detect that subentry
2364 information is being requested.
2367 Clients SHOULD NOT assume a published subschema is complete nor assume
2368 the server supports all of the schema elements it publishes nor assume
2369 the server does not support an unpublished element.
2373 5. DSA (Server) Informational Model
2376 The LDAP protocol assumes there are one or more servers which jointly
2377 provide access to a Directory Information Tree (DIT). The server
2378 holding the original information is called the "master" (for that
2379 information). Servers which hold copies of the original information
2380 are referred to as "shadowing" or "caching" servers.
2383 As defined in [X.501]:
2386 context prefix: The sequence of RDNs leading from the Root of the
2387 DIT to the initial vertex of a naming context; corresponds to
2388 the distinguished name of that vertex.
2394 naming context: A subtree of entries held in a single master DSA.
2397 That is, a naming context is the largest collection of entries,
2398 starting at an entry that is mastered by a particular server, and
2399 including all its subordinates and their subordinates, down to the
2400 entries which are mastered by different servers. The context prefix
2401 is the name of the initial entry.
2404 The root of the DIT is a DSA-specific Entry (DSE) and not part of any
2405 naming context (or any subtree); each server has different attribute
2406 values in the root DSE.
2410 5.1. Server-specific Data Requirements
2413 An LDAP server SHALL provide information about itself and other
2414 information that is specific to each server. This is represented as a
2415 group of attributes located in the root DSE, which is named with the
2416 DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
2420 These attributes are retrievable, subject to access control and other
2425 Zeilenga LDAP Models [Page 36]
2426 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2430 restrictions, if a client performs a Search operation [Protocol] with
2431 an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
2432 [Filters], and with the attributes field listing the names of the
2433 desired attributes. It is noted that root DSE attributes are
2434 operational, and like other operational attributes, are not returned
2435 in search requests unless requested by name.
2438 The root DSE SHALL NOT be included if the client performs a subtree
2439 search starting from the root.
2442 Servers may allow clients to modify attributes of the root DSE where
2446 The following attributes of the root DSE are defined in [Syntaxes].
2447 Additional attributes may be defined in other documents.
2450 - altServer: alternative servers;
2453 - namingContexts: naming contexts;
2456 - supportedControl: recognized LDAP controls;
2459 - supportedExtension: recognized LDAP extended operations;
2462 - supportedLDAPVersion: LDAP versions supported; and
2465 - supportedSASLMechanisms: recognized Simple Authentication and
2466 Security Layers (SASL) [SASL] mechanisms.
2469 The values provided for these attributes may depend on
2470 session-specific and other factors. For example, a server supporting
2471 the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
2472 client's identity has been established by a lower level. See
2476 The root DSE may also include a 'subschemaSubentry' attribute. If so,
2477 it refers to the subschema (sub)entry holding the schema controlling
2478 the root DSE. Clients SHOULD NOT assume that this subschema
2479 (sub)entry controls other entries held by the server. General
2480 subschema discovery procedures are provided in Section 4.4.
2487 The 'altServer' attribute lists URIs referring to alternative servers
2488 which may be contacted when this server becomes unavailable. URIs for
2489 servers implementing the LDAP are written according to [LDAPURL].
2490 Other kinds of URIs may be provided. If the server does not know of
2495 Zeilenga LDAP Models [Page 37]
2496 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2500 any other servers which could be used this attribute will be absent.
2501 Clients may cache this information in case their preferred server
2502 later becomes unavailable.
2505 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
2506 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
2507 USAGE dSAOperation )
2510 The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
2515 5.1.2. 'namingContexts'
2518 The 'namingContexts' attribute lists the context prefixes of the
2519 naming contexts the server masters or shadows (in part or in whole).
2520 If the server is a first-level DSA [X.501], it should list (in
2521 addition) an empty string (indicating the root of the DIT). If the
2522 server does not master or shadow any information (e.g. it is an LDAP
2523 gateway to a public X.500 directory) this attribute will be absent.
2524 If the server believes it masters or shadows the entire directory, the
2525 attribute will have a single value, and that value will be the empty
2526 string (indicating the root of the DIT).
2529 This attribute may be used, for example, to select a suitable entry
2530 name for subsequent operations with this server.
2533 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
2534 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2535 USAGE dSAOperation )
2538 The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
2539 defined in [Syntaxes].
2543 5.1.3. 'supportedControl'
2546 The 'supportedControl' attribute lists object identifiers identifying
2547 the request controls [Protocol] the server supports. If the server
2548 does not support any request controls, this attribute will be absent.
2549 Object identifiers identifying response controls need not be listed.
2552 Procedures for registering object identifiers used to discovery of
2553 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2556 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
2557 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2558 USAGE dSAOperation )
2563 Zeilenga LDAP Models [Page 38]
2564 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2568 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2569 defined in [Syntaxes].
2573 5.1.4. 'supportedExtension'
2576 The 'supportedExtension' attribute lists object identifiers
2577 identifying the extended operations [Protocol] which the server
2578 supports. If the server does not support any extended operations,
2579 this attribute will be absent.
2582 An extended operation generally consists of an extended request and an
2583 extended response but may also include other protocol data units (such
2584 as intermediate responses). The object identifier assigned to the
2585 extended request is used to identify the extended operation. Other
2586 object identifiers used in the extended operation need not be listed
2587 as values of this attribute.
2590 Procedures for registering object identifiers used to discovery of
2591 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2594 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
2595 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2596 USAGE dSAOperation )
2599 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2600 defined in [Syntaxes].
2604 5.1.5. 'supportedLDAPVersion'
2607 The 'supportedLDAPVersion' attribute lists the versions of LDAP which
2608 the server supports.
2611 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
2612 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2613 USAGE dSAOperation )
2616 The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
2621 5.1.6. 'supportedSASLMechanisms'
2624 The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
2625 [SASL] which the server recognizes and/or supports [AuthMeth]. The
2626 contents of this attribute may depend on the current session state.
2627 If the server does not support any SASL mechanisms this attribute will
2632 Zeilenga LDAP Models [Page 39]
2633 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2640 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
2641 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2642 USAGE dSAOperation )
2645 The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
2650 6. Other Considerations
2653 6.1. Preservation of User Information
2656 Syntaxes may be defined which have specific value and/or value form
2657 (representation) preservation requirements. For example, a syntax
2658 containing digitally signed data can mandate the server preserve both
2659 the value and form of value presented to ensure signature is not
2663 Where such requirements have not been explicitly stated, servers
2664 SHOULD preserve the value of user information but MAY return the value
2665 in a different form. And where a server is unable (or unwilling) to
2666 preserve the value of user information, the server SHALL ensure that
2667 an equivalent value (per Section 2.3) is returned.
2674 Short names, also known as descriptors, are used as more readable
2675 aliases for object identifiers and are used to identify various schema
2676 elements. However, it is not expected that LDAP implementations with
2677 human user interface would display these short names (nor the object
2678 identifiers they refer to) to the user, but would most likely be
2679 performing translations (such as expressing the short name in one of
2680 the local national languages). For example, the short name "st"
2681 (stateOrProvinceName) might be displayed to a German-speaking user as
2685 The same short name might have different meaning in different
2686 subschemas and, within a particular subschema, the same short name
2687 might refer to different object identifiers each identifying a
2688 different kind of schema element.
2691 Implementations MUST be prepared that the same short name might be
2692 used in a subschema to refer to the different kinds of schema
2693 elements. That is, there might be an object class 'x-fubar' and an
2694 attribute type 'x-fubar' in a subschema.
2699 Zeilenga LDAP Models [Page 40]
2700 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2704 Implementations MUST be prepared that the same short name might be
2705 used in the different subschemas to refer to the different schema
2706 elements. That is, there might be two matching rules 'x-fubar', each
2707 in different subschemas.
2710 Procedures for registering short names (descriptors) are detailed in
2715 6.3. Cache and Shadowing
2718 Some servers may hold cache or shadow copies of entries, which can be
2719 used to answer search and comparison queries, but will return
2720 referrals or contact other servers if modification operations are
2721 requested. Servers that perform shadowing or caching MUST ensure that
2722 they do not violate any access control constraints placed on the data
2723 by the originating server.
2727 7. Implementation Guidelines
2730 7.1 Server Guidelines
2733 Servers MUST recognize all names of attribute types and object classes
2734 defined in this document but, unless stated otherwise, need not
2735 support the associated functionality. Servers SHOULD recognize all
2736 the names of attribute types and object classes defined in Section 3
2737 and 4, respectively, of [Schema].
2740 Servers MUST ensure that entries conform to user and system schema
2741 rules or other data model constraints.
2744 Servers MAY support DIT Content Rules. Servers MAY support DIT
2745 Structure Rules and Name Forms.
2748 Servers MAY support alias entries.
2751 Servers MAY support the 'extensibleObject' object class.
2754 Servers MAY support subentries. If so, they MUST do so in accordance
2755 with [RFC3672]. Servers which do not support subentries SHOULD use
2756 object entries to mimic subentries as detailed in Section 3.2.
2759 Servers MAY implement additional schema elements. Servers SHOULD
2760 provide definitions of all schema elements they support in subschema
2768 Zeilenga LDAP Models [Page 41]
2769 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2773 7.2 Client Guidelines
2776 In the absence of prior agreements with servers, clients SHOULD NOT
2777 assume that servers support any particular schema elements beyond
2778 those referenced in Section 7.1. The client can retrieve subschema
2779 information as described in Section 4.4.
2782 Clients MUST NOT display nor attempt to decode as ASN.1, a value if
2783 its syntax is not known. Clients MUST NOT assume the LDAP-specific
2784 string encoding is restricted to a UTF-8 encoded string of Unicode
2785 characters or any particular subset of Unicode (such as a printable
2786 subset) unless such restriction is explicitly stated. Clients SHOULD
2787 NOT send attribute values in a request that are not valid according to
2788 the syntax defined for the attributes.
2792 8. Security Considerations
2795 Attributes of directory entries are used to provide descriptive
2796 information about the real-world objects they represent, which can be
2797 people, organizations or devices. Most countries have privacy laws
2798 regarding the publication of information about people.
2801 General security considerations for accessing directory information
2802 with LDAP are discussed in [Protocol] and [AuthMeth].
2806 9. IANA Considerations
2809 It is requested that the Internet Assigned Numbers Authority (IANA)
2810 update the LDAP descriptors registry as indicated in the following
2814 Subject: Request for LDAP Descriptor Registration Update
2815 Descriptor (short name): see comment
2816 Object Identifier: see comment
2817 Person & email address to contact for further information:
2818 Kurt Zeilenga <kurt@OpenLDAP.org>
2820 Specification: RFC XXXX
2821 Author/Change Controller: IESG
2825 The following descriptors (short names) should be added to
2830 ------------------------ ---- -----------------
2835 Zeilenga LDAP Models [Page 42]
2836 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2840 governingStructureRule A 2.5.21.10
2841 structuralObjectClass A 2.5.21.9
2844 The following descriptors (short names) should be updated to
2849 ------------------------ ---- -----------------
2851 aliasedObjectName A 2.5.4.1
2852 altServer A 1.3.6.1.4.1.1466.101.120.6
2853 attributeTypes A 2.5.21.5
2854 createTimestamp A 2.5.18.1
2855 creatorsName A 2.5.18.3
2856 dITContentRules A 2.5.21.2
2857 dITStructureRules A 2.5.21.1
2858 extensibleObject O 1.3.6.1.4.1.1466.101.120.111
2859 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
2860 matchingRuleUse A 2.5.21.8
2861 matchingRules A 2.5.21.4
2862 modifiersName A 2.5.18.4
2863 modifyTimestamp A 2.5.18.2
2864 nameForms A 2.5.21.7
2865 namingContexts A 1.3.6.1.4.1.1466.101.120.5
2866 objectClass A 2.5.4.0
2867 objectClasses A 2.5.21.6
2868 subschema O 2.5.20.1
2869 subschemaSubentry A 2.5.18.10
2870 supportedControl A 1.3.6.1.4.1.1466.101.120.13
2871 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
2872 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
2873 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
2881 This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
2882 S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
2883 RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
2884 Indexing of Directories (ASID) Working Group. This document is also
2885 based in part on "The Directory: Models" [X.501], a product of the
2886 International Telephone Union (ITU). Additional text was borrowed
2887 from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
2890 This document is a product of the IETF LDAP Revision (LDAPBIS) Working
2897 Zeilenga LDAP Models [Page 43]
2898 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2902 11. Editor's Address
2906 E-mail: <kurt@openldap.org>
2913 [[Note to the RFC Editor: please replace the citation tags used in
2914 referencing Internet-Drafts with tags of the form RFCnnnn.]]
2918 12.1. Normative References
2921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2922 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
2925 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2926 Specifications: ABNF", RFC 2234, November 1997.
2929 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
2930 10646", RFC 3629 (also STD 63), November 2003.
2933 [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
2937 [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
2938 3672, December 2003.
2941 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
2942 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
2945 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
2946 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
2950 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
2951 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
2954 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
2955 Connection Level Security Mechanisms",
2956 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
2959 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
2960 Representation of Search Filters",
2961 draft-ietf-ldapbis-filter-xx.txt, a work in progress.
2964 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
2969 Zeilenga LDAP Models [Page 44]
2970 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
2974 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
2978 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
2979 draft-ietf-ldapbis-url-xx.txt, a work in progress.
2982 [SASL] Melnikov, A. (Editor), "Simple Authentication and
2983 Security Layer (SASL)",
2984 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
2987 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
2988 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
2991 [Schema] Dally, K. (editor), "LDAP: User Schema",
2992 draft-ietf-ldapbis-user-schema-xx.txt, a work in
2996 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
2997 3.2.0" is defined by "The Unicode Standard, Version 3.0"
2998 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
2999 as amended by the "Unicode Standard Annex #27: Unicode
3000 3.1" (http://www.unicode.org/reports/tr27/) and by the
3001 "Unicode Standard Annex #28: Unicode 3.2"
3002 (http://www.unicode.org/reports/tr28/).
3005 [X.500] International Telecommunication Union -
3006 Telecommunication Standardization Sector, "The Directory
3007 -- Overview of concepts, models and services,"
3008 X.500(1993) (also ISO/IEC 9594-1:1994).
3011 [X.501] International Telecommunication Union -
3012 Telecommunication Standardization Sector, "The Directory
3013 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
3016 [X.680] International Telecommunication Union -
3017 Telecommunication Standardization Sector, "Abstract
3018 Syntax Notation One (ASN.1) - Specification of Basic
3019 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
3023 12.2. Informative References
3033 This appendix is non-normative.
3038 Zeilenga LDAP Models [Page 45]
3039 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
3043 This document amounts to nearly a complete rewrite of portions of RFC
3044 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
3045 overall clarity of technical specification. This appendix provides a
3046 summary of substantive changes made to the portions of these documents
3047 incorporated into this document. Readers should consult [Roadmap],
3048 [Protocol], [Syntaxes], and [Schema] for summaries of remaining
3049 portions of these documents.
3053 A.1 Changes to RFC 2251
3056 This document incorporates from RFC 2251 sections 3.2 and 3.4,
3057 portions of Section 4 and 6 as summarized below.
3061 A.1.1 Section 3.2 of RFC 2251
3064 Section 3.2 of RFC 2251 provided a brief introduction to the X.500
3065 data model, as used by LDAP. The previous specification relied on
3066 [X.501] but lacked clarity in how X.500 models are adapted for use by
3067 LDAP. This document describes the X.500 data models, as used by LDAP
3068 in greater detail, especially in areas where adaptation is needed.
3071 Section 3.2.1 of RFC 2251 described an attribute as "a type with one
3072 or more associated values." In LDAP, an attribute is better described
3073 as an attribute description, a type with zero or more options, and one
3074 or more associated values.
3077 Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
3078 objectClasses and attributeTypes attributes, yet X.500(93) treats
3079 these attributes as optional. While generally all implementations
3080 that support X.500(93) subschema mechanisms will provide both of these
3081 attributes, it is not absolutely required for interoperability that
3082 all servers do. The mandate was removed for consistency with
3083 X.500(93). The subschema discovery mechanism was also clarified to
3084 indicate that subschema controlling an entry is obtained by reading
3085 the (sub)entry referred to by that entry's 'subschemaSubentry'
3090 A.1.2 Section 3.4 of RFC 2251
3093 Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
3094 This material, with changes, was incorporated in Section 5.1 of this
3104 Zeilenga LDAP Models [Page 46]
3105 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
3109 - Clarify that attributes of the root DSE are subject to "other
3110 restrictions" in addition to access controls.
3113 - Clarify that only recognized extended requests need to be enumerated
3114 'supportedExtension'.
3117 - Clarify that only recognized request controls need to be enumerated
3121 - Clarify that root DSE attributes are operational and, like other
3122 operational attributes, will not be returned in search requests
3123 unless requested by name.
3126 - Clarify that not all root DSE attributes are user modifiable.
3129 - Remove inconsistent text regarding handling of the
3130 'subschemaSubentry' attribute within the root DSE. The previous
3131 specification stated that the 'subschemaSubentry' attribute held in
3132 the root DSE referred to "subschema entries (or subentries) known by
3133 this server." This is inconsistent with the attribute intended use
3134 as well as its formal definition as a single valued attribute
3135 [X.501]. It is also noted that a simple (possibly incomplete) list
3136 of subschema (sub)entries is not terrible useful. This document (in
3137 section 5.1) specifies that the 'subschemaSubentry' attribute of the
3138 root DSE refers to the subschema controlling the root DSE. It is
3139 noted that the general subschema discovery mechanism remains
3140 available (see Section 4.4 of this document).
3144 A.1.2 Section 4 of RFC 2251
3147 Portions of Section 4 of RFC 2251 detailing aspects of the information
3148 model used by LDAP were incorporated in this document, including:
3151 - Restriction of distinguished values to attributes whose descriptions
3152 have no options (from Section 4.1.3);
3155 - Data model aspects of Attribute Types (from Section 4.1.4),
3156 Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
3157 Matching Rule Identifier (from 4.1.9); and
3160 - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
3164 Clarifications to these portions include:
3167 - Subtyping and AttributeDescriptions with options.
3173 Zeilenga LDAP Models [Page 47]
3174 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
3178 A.1.3 Section 6 of RFC 2251
3181 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
3182 where incorporated into this document.
3186 A.2 Changes to RFC 2252
3189 This document incorporates Sections 4, 5 and 7 from RFC 2252.
3193 A.2.1 Section 4 of RFC 2252
3196 The specification was updated to use Augmented BNF [RFC2234]. The
3197 string representation of an OBJECT IDENTIFIER was tighten to
3198 disallow leading zeros as described in RFC 2252 text.
3201 The <descr> syntax was changed to disallow semicolon (U+003B)
3202 characters to appear to be consistent its natural language
3203 specification "descr is the syntactic representation of an object
3204 descriptor, which consists of letters and digits, starting with a
3205 letter." In a related change, the statement "an
3206 AttributeDescription can be used as the value in a NAME part of an
3207 AttributeTypeDescription" was deleted. RFC 2252 provided no
3208 specification of the semantics of attribute options appearing in
3212 RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
3213 over the <numericoid> form. However, <descr> form can be ambiguous.
3214 To address this issue, the imperative was replaced with a statement
3215 (in Section 1.4) that while the <descr> form is generally preferred,
3216 <numericoid> should be used where an unambiguous <descr> is not
3217 available. Additionally, an expanded discussion of descriptor
3218 issues is discussed in Section 6.2 (Short Names).
3221 The ABNF for a quoted string (qdstring) was updated to reflect
3222 support for the escaping mechanism described in 4.3 of RFC 2252.
3226 A.2.2 Section 5 of RFC 2252
3229 Definitions of operational attributes provided in Section 5 of RFC
3230 2252 where incorporated into this document.
3233 The 'namingContexts' description was clarified. A first-level DSA
3234 should publish, in addition to other values, "" indicating the root
3241 Zeilenga LDAP Models [Page 48]
3242 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
3246 The 'altServer' description was clarified. It may hold any URI.
3249 The 'supportedExtension' description was clarified. A server need
3250 only list the OBJECT IDENTIFIERs associated with the extended
3251 requests of the extended operations it recognizes.
3254 The 'supportedControl' description was clarified. A server need
3255 only list the OBJECT IDENTIFIERs associated with the request
3256 controls it recognizes.
3259 Descriptions for the 'structuralObjectClass' and
3260 'governingStructureRule' operational attribute types were added.
3264 A.2.3 Section 7 of RFC 2252
3267 Section 7 of RFC 2252 provides definitions of the 'subschema' and
3268 'extensibleObject' object classes. These definitions where
3269 integrated into Section 4.2 and Section 4.3 of this document,
3270 respectively. Section 7 of RFC 2252 also contained the object class
3271 implementation requirement. This was incorporated into Section 7 of
3275 The specification of 'extensibleObject' was clarified of how it
3276 interacts with precluded attributes.
3280 A.3 Changes to RFC 2256
3283 This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
3287 Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
3288 attribute type. This was integrated into Section 2.4.1 of this
3289 document. The statement "One of the values is either 'top' or
3290 'alias'" was replaced with statement that one of the values is 'top'
3291 as entries belonging to 'alias' also belong to 'top'.
3294 Section 5.2 of RFC 2256 provided the definition of the
3295 'aliasedObjectName' attribute type. This was integrated into
3296 Section 2.6.2 of this document.
3299 Section 7.1 of RFC 2256 provided the definition of the 'top' object
3300 class. This was integrated into Section 2.4.1 of this document.
3303 Section 7.2 of RFC 2256 provided the definition of the 'alias'
3304 object class. This was integrated into Section 2.6.1 of this
3310 Zeilenga LDAP Models [Page 49]
3311 INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
3315 Intellectual Property Rights
3318 The IETF takes no position regarding the validity or scope of any
3319 Intellectual Property Rights or other rights that might be claimed to
3320 pertain to the implementation or use of the technology described in
3321 this document or the extent to which any license under such rights
3322 might or might not be available; nor does it represent that it has
3323 made any independent effort to identify any such rights. Information
3324 on the procedures with respect to rights in RFC documents can be found
3325 in BCP 78 and BCP 79.
3328 Copies of IPR disclosures made to the IETF Secretariat and any
3329 assurances of licenses to be made available, or the result of an
3330 attempt made to obtain a general license or permission for the use of
3331 such proprietary rights by implementers or users of this specification
3332 can be obtained from the IETF on-line IPR repository at
3333 http://www.ietf.org/ipr.
3336 The IETF invites any interested party to bring to its attention any
3337 copyrights, patents or patent applications, or other proprietary
3338 rights that may cover technology that may be required to implement
3339 this standard. Please address the information to the IETF at
3348 Copyright (C) The Internet Society (2004). This document is subject
3349 to the rights, licenses and restrictions contained in BCP 78, and
3350 except as set forth therein, the authors retain all their rights.
3353 This document and the information contained herein are provided on an
3354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
3356 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
3357 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
3358 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3372 Zeilenga LDAP Models [Page 50]
projects / openldap / blob