5 INTERNET-DRAFT Editor: Kurt D. Zeilenga
6 Intended Category: Standard Track OpenLDAP Foundation
7 Expires in six months 21 February 2005
8 Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
12 LDAP: Directory Information Models
13 <draft-ietf-ldapbis-models-14.txt>
19 This document is intended to be published as a Standard Track RFC.
20 Distribution of this memo is unlimited. Technical discussion of this
21 document will take place on the IETF LDAP Revision Working Group
22 mailing list <ietf-ldapbis@openldap.org>. Please send editorial
23 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.
31 Internet-Drafts are working documents of the Internet Engineering Task
32 Force (IETF), its areas, and its working groups. Note that other
33 groups may also distribute working documents as Internet-Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference material
38 or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/1id-abstracts.html
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html
47 Copyright (C) The Internet Society (2005). All Rights Reserved.
49 Please see the Full Copyright section near the end of this document
56 Zeilenga LDAP Models [Page 1]
58 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
63 The Lightweight Directory Access Protocol (LDAP) is an Internet
64 protocol for accessing distributed directory services which act in
65 accordance with X.500 data and service models. This document
66 describes the X.500 Directory Information Models, as used in LDAP.
74 1.1. Relationship to Other LDAP Specifications
75 1.2. Relationship to X.501 4
77 1.4. Common ABNF Productions
78 2. Model of Directory User Information 6
79 2.1. The Directory Information Tree 7
80 2.2. Structure of an Entry
81 2.3. Naming of Entries 8
83 2.5. Attribute Descriptions 12
85 3. Directory Administrative and Operational Information 17
88 3.3. The 'objectClass' attribute
89 3.4. Operational attributes 19
90 4. Directory Schema 22
91 4.1. Schema Definitions 23
92 4.2. Subschema Subentries 32
93 4.3. 'extensibleObject' 35
94 4.4. Subschema Discovery 36
95 5. DSA (Server) Informational Model
96 5.1. Server-specific Data Requirements 37
97 6. Other Considerations 40
98 6.1. Preservation of User Information 41
100 6.3. Cache and Shadowing
101 7. Implementation Guidelines 42
102 7.1. Server Guidelines
103 7.2. Client Guidelines
104 8. Security Considerations 43
105 9. IANA Considerations
106 10. Acknowledgments 44
112 Zeilenga LDAP Models [Page 2]
114 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
117 12.1. Normative References 45
118 12.2. Informative References
120 Intellectual Property Rights 51
126 This document discusses the X.500 Directory Information Models
127 [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
130 The Directory is "a collection of open systems cooperating to provide
131 directory services" [X.500]. The information held in the Directory is
132 collectively known as the Directory Information Base (DIB). A
133 Directory user, which may be a human or other entity, accesses the
134 Directory through a client (or Directory User Agent (DUA)). The
135 client, on behalf of the directory user, interacts with one or more
136 servers (or Directory System Agents (DSA)). A server holds a fragment
139 The DIB contains two classes of information:
141 1) user information (e.g., information provided and administrated
142 by users). Section 2 describes the Model of User Information.
144 2) administrative and operational information (e.g., information
145 used to administer and/or operate the directory). Section 3
146 describes the model of Directory Administrative and Operational
149 These two models, referred to as the generic Directory Information
150 Models, describe how information is represented in the Directory.
151 These generic models provide a framework for other information models.
152 Section 4 discusses the subschema information model and subschema
153 discovery. Section 5 discusses the DSA (Server) Informational Model.
155 Other X.500 information models, such as access control distribution
156 knowledge, and replication knowledge information models, may be
157 adapted for use in LDAP. Specification of how these models apply to
158 LDAP is left to future documents.
161 1.1. Relationship to Other LDAP Specifications
163 This document is a integral part of the LDAP technical specification
164 [Roadmap] which obsoletes the previously defined LDAP technical
168 Zeilenga LDAP Models [Page 3]
170 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
173 specification, RFC 3377, in its entirety.
175 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
176 portions of sections 4 and 6. Appendix A.1 summarizes changes to
177 these sections. The remainder of RFC 2251 is obsoleted by the
178 [Protocol], [AuthMeth], and [Roadmap] documents.
180 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
181 summarizes changes to these sections. The remainder of RFC 2252 is
182 obsoleted by [Syntaxes].
184 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
185 Appendix A.3 summarizes changes to these sections. The remainder of
186 RFC 2256 is obsoleted by [Schema] and [Syntaxes].
188 This document obsoletes RFC 3674 in its entirety. Appendix A.4
189 summarizes changes since RFC 3674.
192 1.2. Relationship to X.501
194 This document includes material, with and without adaptation, from
195 [X.501] as necessary to describe this protocol. These adaptations
196 (and any other differences herein) apply to this protocol, and only
202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
204 document are to be interpreted as described in BCP 14 [RFC2119].
206 Schema definitions are provided using LDAP description formats (as
207 defined in Section 4.1). Definitions provided here are formatted
208 (line wrapped) for readability. Matching rules and LDAP syntaxes
209 referenced in these definitions are specified in [Syntaxes].
212 1.4. Common ABNF Productions
214 A number of syntaxes in this document are described using Augmented
215 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
216 number of syntaxes defined in other documents) rely on the following
219 keystring = leadkeychar *keychar
224 Zeilenga LDAP Models [Page 4]
226 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
229 keychar = ALPHA / DIGIT / HYPHEN
230 number = DIGIT / ( LDIGIT 1*DIGIT )
232 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
233 DIGIT = %x30 / LDIGIT ; "0"-"9"
234 LDIGIT = %x31-39 ; "1"-"9"
235 HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
237 SP = 1*SPACE ; one or more " "
238 WSP = 0*SPACE ; zero or more " "
240 NULL = %x00 ; null (0)
241 SPACE = %x20 ; space (" ")
242 DQUOTE = %x22 ; quote (""")
243 SHARP = %x23 ; octothorpe (or sharp sign) ("#")
244 DOLLAR = %x24 ; dollar sign ("$")
245 SQUOTE = %x27 ; single quote ("'")
246 LPAREN = %x28 ; left paren ("(")
247 RPAREN = %x29 ; right paren (")")
248 PLUS = %x2B ; plus sign ("+")
249 COMMA = %x2C ; comma (",")
250 HYPHEN = %x2D ; hyphen ("-")
251 DOT = %x2E ; period (".")
252 SEMI = %x3B ; semicolon (";")
253 LANGLE = %x3C ; left angle bracket ("<")
254 EQUALS = %x3D ; equals sign ("=")
255 RANGLE = %x3E ; right angle bracket (">")
256 ESC = %x5C ; backslash ("\")
257 USCORE = %x5F ; underscore ("_")
258 LCURLY = %x7B ; left curly brace "{"
259 RCURLY = %x7D ; right curly brace "}"
261 ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
263 UTFMB = UTF2 / UTF3 / UTF4
267 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
268 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
269 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
272 OCTET = %x00-FF ; Any octet (8-bit data unit)
274 Object identifiers (OIDs) [X.680] are represented in LDAP using a
275 dot-decimal format conforming to the ABNF:
280 Zeilenga LDAP Models [Page 5]
282 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
285 numericoid = number 1*( DOT number )
287 Short names, also known as descriptors, are used as more readable
288 aliases for object identifiers. Short names are case insensitive and
293 Where either an object identifier or a short name may be specified,
294 the following production is used:
296 oid = descr / numericoid
298 While the <descr> form is generally preferred when the usage is
299 restricted to short names referring to object identifiers which
300 identify like kinds of objects (e.g., attribute type descriptions,
301 matching rule descriptions, object class descriptions), the
302 <numericoid> form should be used when the object identifiers may
303 identify multiple kinds of objects or when an unambiguous short name
304 (descriptor) is not available.
306 Implementations SHOULD treat short names (descriptors) used in an
307 ambiguous manner (as discussed above) as unrecognized.
309 Short Names (descriptors) are discussed further in Section 6.2.
312 2. Model of Directory User Information
316 The purpose of the Directory is to hold, and provide access to,
317 information about objects of interest (objects) in some 'world'.
318 An object can be anything which is identifiable (can be named).
320 An object class is an identified family of objects, or conceivable
321 objects, which share certain characteristics. Every object belongs
322 to at least one class. An object class may be a subclass of other
323 object classes, in which case the members of the former class, the
324 subclass, are also considered to be members of the latter classes,
325 the superclasses. There may be subclasses of subclasses, etc., to
328 A directory entry, a named collection of information, is the basic
329 unit of information held in the Directory. There are multiple kinds
330 of directory entries.
332 An object entry represents a particular object. An alias entry
336 Zeilenga LDAP Models [Page 6]
338 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
341 provides alternative naming. A subentry holds administrative and/or
342 operational information.
344 The set of entries representing the DIB are organized hierarchically
345 in a tree structure known as the Directory Information Tree (DIT).
347 Section 2.1 describes the Directory Information Tree
348 Section 2.2 discusses the structure of entries.
349 Section 2.3 discusses naming of entries.
350 Section 2.4 discusses object classes.
351 Section 2.5 discusses attribute descriptions.
352 Section 2.6 discusses alias entries.
355 2.1. The Directory Information Tree
357 As noted above, the DIB is composed of a set of entries organized
358 hierarchically in a tree structure known as the Directory Information
359 Tree (DIT). Specifically, a tree where vertices are the entries.
361 The arcs between vertices define relations between entries. If an arc
362 exists from X to Y, then the entry at X is the immediate superior of Y
363 and Y is the immediate subordinate of X. An entry's superiors are the
364 entry's immediate superior and its superiors. An entry's subordinates
365 are all of its immediate subordinates and their subordinates.
367 Similarly, the superior/subordinate relationship between object
368 entries can be used to derive a relation between the objects they
369 represent. DIT structure rules can be used to govern relationships
372 Note: An entry's immediate superior is also known as the entry's
373 parent and an entry's immediate subordinate is also known as the
374 entry's child. Entries which have the same parent are known as
378 2.2. Structure of an Entry
380 An entry consists of a set of attributes which hold information about
381 the object which the entry represents. Some attributes represent user
382 information and are called user attributes. Other attributes
383 represent operational and/or administrative information and are called
384 operational attributes.
386 An attribute is an attribute description (a type and zero or more
387 options) with one or more associated values. An attribute is often
388 referred to by its attribute description. For example, the
392 Zeilenga LDAP Models [Page 7]
394 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
397 'givenName' attribute is the attribute which consists of the attribute
398 description 'givenName' (the 'givenName' attribute type [Schema] and
399 zero options) and one or more associated values.
401 The attribute type governs whether the attribute can have multiple
402 values, the syntax and matching rules used to construct and compare
403 values of that attribute, and other functions. Options indicate
404 subtypes and other functions.
406 Attribute values conform to the defined syntax of the attribute type.
408 No two values of an attribute may be equivalent. Two values are
409 considered equivalent if and only if they would match according to the
410 equality matching rule of the attribute type or, if the attribute type
411 is defined with no equality matching rule, two values are equivalent
412 if and only if they are identical. (See 2.5.1 for other
415 For example, a 'givenName' attribute can have more than one value,
416 they must be Directory Strings, and they are case insensitive. A
417 'givenName' attribute cannot hold both "John" and "JOHN" as these are
418 equivalent values per the equality matching rule of the attribute
421 Additionally, no attribute is to have a value which is not equivalent
422 to itself. For example, the 'givenName' attribute cannot have as a
423 value a directory string which includes the REPLACEMENT CHARACTER
424 (U+FFFD) code point as matching involving that directory string is
425 Undefined per this attribute's equality matching rule.
427 When an attribute is used for naming of the entry, one and only one
428 value of the attribute is used in forming the Relative Distinguished
429 Name. This value is known as a distinguished value.
432 2.3. Naming of Entries
434 2.3.1. Relative Distinguished Names
436 Each entry is named relative to its immediate superior. This relative
437 name, known as its Relative Distinguished Name (RDN) [X.501], is
438 composed of an unordered set of one or more attribute value assertions
439 (AVA) consisting of an attribute description with zero options and an
440 attribute value. These AVAs are chosen to match attribute values
441 (each a distinguished value) of the entry.
443 An entry's relative distinguished name must be unique among all
444 immediate subordinates of the entry's immediate superior (i.e., all
448 Zeilenga LDAP Models [Page 8]
450 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
455 The following are examples of string representations of RDNs [LDAPDN]:
459 CN=Kurt Zeilenga+L=Redwood Shores
461 The last is an example of a multi-valued RDN. That is, an RDN
462 composed of multiple AVAs.
465 2.3.2. Distinguished Names
467 An entry's fully qualified name, known as its Distinguished Name (DN)
468 [X.501], is the concatenation of its RDN and its immediate superior's
469 DN. A Distinguished Name unambiguously refers to an entry in the
470 tree. The following are examples of string representations of DNs
473 UID=nobody@example.com,DC=example,DC=com
474 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
479 An alias, or alias name, is "an name for an object, provided by the
480 use of alias entries" [X.501]. Alias entries are described in Section
486 An object class is "an identified family of objects (or conceivable
487 objects) which share certain characteristics" [X.501].
489 As defined in [X.501]:
491 Object classes are used in the Directory for a number of purposes:
493 - describing and categorising objects and the entries that
494 correspond to these objects;
496 - where appropriate, controlling the operation of the Directory;
498 - regulating, in conjunction with DIT structure rule
499 specifications, the position of entries in the DIT;
504 Zeilenga LDAP Models [Page 9]
506 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
509 - regulating, in conjunction with DIT content rule
510 specifications, the attributes that are contained in entries;
512 - identifying classes of entry that are to be associated with a
513 particular policy by the appropriate administrative authority.
515 An object class (a subclass) may be derived from an object class
516 (its direct superclass) which is itself derived from an even more
517 generic object class. For structural object classes, this process
518 stops at the most generic object class, 'top' (defined in Section
519 2.4.1). An ordered set of superclasses up to the most superior
520 object class of an object class is its superclass chain.
522 An object class may be derived from two or more direct
523 superclasses (superclasses not part of the same superclass chain).
524 This feature of subclassing is termed multiple inheritance.
526 Each object class identifies the set of attributes required to be
527 present in entries belonging to the class and the set of attributes
528 allowed to be present in entries belonging to the class. As an entry
529 of a class must meet the requirements of each class it belongs to, it
530 can be said that an object class inherits the sets of allowed and
531 required attributes from its superclasses. A subclass can identify an
532 attribute allowed by its superclass as being required. If an
533 attribute is a member of both sets, it is required to be present.
535 Each object class is defined to be one of three kinds of object
536 classes: Abstract, Structural, or Auxiliary.
538 Each object class is identified by an object identifier (OID) and,
539 optionally, one or more short names (descriptors).
542 2.4.1. Abstract Object Classes
544 An abstract object class, as the name implies, provides a base of
545 characteristics from which other object classes can be defined to
546 inherit from. An entry cannot belong to an abstract object class
547 unless it belongs to a structural or auxiliary class which inherits
548 from that abstract class.
550 Abstract object classes can not derive from structural nor auxiliary
553 All structural object classes derive (directly or indirectly) from the
554 'top' abstract object class. Auxiliary object classes do not
555 necessarily derive from 'top'.
560 Zeilenga LDAP Models [Page 10]
562 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
565 The following is the object class definition (see Section 4.1.1) for
566 the 'top' object class:
568 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
570 All entries belong to the 'top' abstract object class.
573 2.4.2. Structural Object Classes
575 As stated in [X.501]:
577 An object class defined for use in the structural specification of
578 the DIT is termed a structural object class. Structural object
579 classes are used in the definition of the structure of the names
580 of the objects for compliant entries.
582 An object or alias entry is characterised by precisely one
583 structural object class superclass chain which has a single
584 structural object class as the most subordinate object class.
585 This structural object class is referred to as the structural
586 object class of the entry.
588 Structural object classes are related to associated entries:
590 - an entry conforming to a structural object class shall
591 represent the real-world object constrained by the object
594 - DIT structure rules only refer to structural object classes;
595 the structural object class of an entry is used to specify the
596 position of the entry in the DIT;
598 - the structural object class of an entry is used, along with an
599 associated DIT content rule, to control the content of an
602 The structural object class of an entry shall not be changed.
604 Each structural object class is a (direct or indirect) subclass of the
605 'top' abstract object class.
607 Structural object classes cannot subclass auxiliary object classes.
609 Each entry is said to belong to its structural object class as well as
610 all classes in its structural object class's superclass chain.
616 Zeilenga LDAP Models [Page 11]
618 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
621 2.4.3. Auxiliary Object Classes
623 Auxiliary object classes are used to augment the characteristics of
624 entries. They are commonly used to augment the sets of attributes
625 required and allowed to be present in an entry. They can be used to
626 describe entries or classes of entries.
628 Auxiliary object classes cannot subclass structural object classes.
630 An entry can belong to any subset of the set of auxiliary object
631 classes allowed by the DIT content rule associated with the structural
632 object class of the entry. If no DIT content rule is associated with
633 the structural object class of the entry, the entry cannot belong to
634 any auxiliary object class.
636 The set of auxiliary object classes which an entry belongs to can
640 2.5. Attribute Descriptions
642 An attribute description is composed of an attribute type (see Section
643 2.5.1) and a set of zero or more attribute options (see Section
646 An attribute description is represented by the ABNF:
648 attributedescription = attributetype options
650 options = *( SEMI option )
653 where <attributetype> identifies the attribute type and each <option>
654 identifies an attribute option. Both <attributetype> and <option>
655 productions are case insensitive. The order in which <option>s appear
656 is irrelevant. That is, any two <attributedescription>s which consist
657 of the same <attributetype> and same set of <option>s are equivalent.
659 Examples of valid attribute descriptions:
665 An attribute description with an unrecognized attribute type is to be
666 treated as unrecognized. Servers SHALL treat an attribute description
667 with an unrecognized attribute option as unrecognized. Clients MAY
668 treat an unrecognized attribute option as a tagging option (see
672 Zeilenga LDAP Models [Page 12]
674 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
679 All attributes of an entry must have distinct attribute descriptions.
682 2.5.1. Attribute Types
684 An attribute type governs whether the attribute can have multiple
685 values, the syntax and matching rules used to construct and compare
686 values of that attribute, and other functions.
688 If no equality matching is specified for the attribute type:
689 - the attribute (of the type) cannot be used for naming;
690 - when adding the attribute (or replacing all values), no two values
691 may be equivalent (see 2.2);
692 - individual values of a multi-valued attribute are not to be
693 independently added or deleted;
694 - attribute value assertions (such as matching in search filters and
695 comparisons) using values of such a type cannot be performed.
697 Otherwise, the specified equality matching rule is to be used for the
698 purposes of evaluating attribute value assertions concerning the
699 attribute type. The specified equality rule is to be transitive and
702 The attribute type indicates whether the attribute is a user attribute
703 or an operational attribute. If operational, the attribute type
704 indicates the operational usage and whether the attribute is
705 modifiable by users or not. Operational attributes are discussed in
708 An attribute type (a subtype) may derive from a more generic attribute
709 type (a direct supertype). The following restrictions apply to
711 - a subtype must have the same usage as its direct supertype,
712 - a subtype's syntax must be the same, or a refinement of, its
713 supertype's syntax, and
714 - a subtype must be collective [RFC3671] if its supertype is
717 An attribute description consisting of a subtype and no options is
718 said to be the direct description subtype of the attribute description
719 consisting of the subtype's direct supertype and no options.
721 Each attribute type is identified by an object identifier (OID) and,
722 optionally, one or more short names (descriptors).
728 Zeilenga LDAP Models [Page 13]
730 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
733 2.5.2. Attribute Options
735 There are multiple kinds of attribute description options. The LDAP
736 technical specification details one kind: tagging options.
738 Not all options can be associated with attributes held in the
739 directory. Tagging options can be.
741 Not all options can be used in conjunction with all attribute types.
742 In such cases, the attribute description is to be treated as
745 An attribute description that contains mutually exclusive options
746 shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
747 "x-foo" and "x-bar" are mutually exclusive, is to be treated as
750 Other kinds of options may be specified in future documents. These
751 documents must detail how new kinds of options they define relate to
752 tagging options. In particular, these documents must detail whether
753 or not new kinds of options can be associated with attributes held in
754 the directory, how new kinds of options affect transfer of attribute
755 values, and how new kinds of options are treated in attribute
756 description hierarchies.
758 Options are represented as short case insensitive textual strings
759 conforming to the <option> production defined in Section 2.5 of this
762 Procedures for registering options are detailed in BCP 64 [BCP64bis].
765 2.5.2.1. Tagging Options
767 Attributes held in the directory can have attribute descriptions with
768 any number of tagging options. Tagging options are never mutually
771 An attribute description with N tagging options is a direct
772 (description) subtype of all attribute descriptions of the same
773 attribute type and all but one of the N options. If the attribute
774 type has a supertype, then the attribute description is also a direct
775 (description) subtype of the attribute description of the supertype
776 and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
777 (description) subtype of 'cn;lang-de', 'cn;lang-en', and
778 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
784 Zeilenga LDAP Models [Page 14]
786 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
789 2.5.3. Attribute Description Hierarchies
791 An attribute description can be the direct subtype of zero or more
792 other attribute descriptions as indicated by attribute type subtyping
793 (as described in Section 2.5.1) or attribute tagging option subtyping
794 (as described in Section 2.5.2.1). These subtyping relationships are
795 used to form hierarchies of attribute descriptions and attributes.
797 As adapted from [X.501]:
799 Attribute hierarchies allow access to the DIB with varying degrees
800 of granularity. This is achieved by allowing the value components
801 of attributes to be accessed by using either their specific
802 attribute description (a direct reference to the attribute) or by
803 a more generic attribute description (an indirect reference).
805 Semantically related attributes may be placed in a hierarchical
806 relationship, the more specialized being placed subordinate to the
807 more generalized. Searching for, or retrieving attributes and
808 their values is made easier by quoting the more generalized
809 attribute description; a filter item so specified is evaluated for
810 the more specialized descriptions as well as for the quoted
813 Where subordinate specialized descriptions are selected to be
814 returned as part of a search result these descriptions shall be
815 returned if available. Where the more general descriptions are
816 selected to be returned as part of a search result both the
817 general and the specialized descriptions shall be returned, if
818 available. An attribute value shall always be returned as a value
819 of its own attribute description.
821 All of the attribute descriptions in an attribute hierarchy are
822 treated as distinct and unrelated descriptions for user
823 modification of entry content.
825 An attribute value stored in an object or alias entry is of
826 precisely one attribute description. The description is indicated
827 when the value is originally added to the entry.
829 For the purpose of subschema administration of the entry, a
830 specification that an attribute is required is fulfilled if the entry
831 contains a value of an attribute description belonging to an attribute
832 hierarchy where the attribute type of that description is the same as
833 the required attribute's type. That is, a "MUST name" specification
834 is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
835 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
836 'name'). Likewise, an entry may contain a value of an attribute
840 Zeilenga LDAP Models [Page 15]
842 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
845 description belonging to an attribute hierarchy where the attribute
846 type of that description is either explicitly included in the
847 definition of an object class to which the entry belongs or allowed by
848 the DIT content rule applicable to that entry. That is, 'name' and
849 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
850 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
853 For the purposes of other policy administration, unless stated
854 otherwise in the specification of the particular administrative model,
855 all of the attribute descriptions in an attribute hierarchy are
856 treated as distinct and unrelated descriptions.
861 As adapted from [X.501]:
863 An alias, or an alias name, for an object is an alternative name
864 for an object or object entry which is provided by the use of
867 Each alias entry contains, within the 'aliasedObjectName'
868 attribute (known as the 'aliasedEntryName' attribute in X.500]), a
869 name of some object. The distinguished name of the alias entry is
870 thus also a name for this object.
872 NOTE - The name within the 'aliasedObjectName' is said to be
873 pointed to by the alias. It does not have to be the
874 distinguished name of any entry.
876 The conversion of an alias name to an object name is termed
877 (alias) dereferencing and comprises the systematic replacement of
878 alias names, where found within a purported name, by the value of
879 the corresponding 'aliasedObjectName' attribute. The process may
880 require the examination of more than one alias entry.
882 Any particular entry in the DIT may have zero or more alias names.
883 It therefore follows that several alias entries may point to the
884 same entry. An alias entry may point to an entry that is not a
885 leaf entry and may point to another alias entry.
887 An alias entry shall have no subordinates, so that an alias entry
888 is always a leaf entry.
890 Every alias entry shall belong to the 'alias' object class.
892 An entry with the 'alias' object class must also belong to an object
896 Zeilenga LDAP Models [Page 16]
898 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
901 class (or classes), or be governed by a DIT content rule, which allows
902 suitable naming attributes to be present.
905 dn: cn=bar,dc=example,dc=com
908 objectClass: extensibleObject
910 aliasedObjectName: cn=foo,dc=example,dc=com
913 2.6.1. 'alias' object class
915 Alias entries belong to the 'alias' object class.
917 ( 2.5.6.1 NAME 'alias'
919 MUST aliasedObjectName )
922 2.6.2. 'aliasedObjectName' attribute type
924 The 'aliasedObjectName' attribute holds the name of the entry an alias
925 points to. The 'aliasedObjectName' attribute is known as the
926 'aliasedEntryName' attribute in X.500.
928 ( 2.5.4.1 NAME 'aliasedObjectName'
929 EQUALITY distinguishedNameMatch
930 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
933 The 'distinguishedNameMatch' matching rule and the DistinguishedName
934 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
937 3. Directory Administrative and Operational Information
939 This section discusses select aspects of the X.500 Directory
940 Administrative and Operational Information model [X.501]. LDAP
941 implementations MAY support other aspects of this model.
946 As defined in [X.501]:
948 A subtree is a collection of object and alias entries situated at
952 Zeilenga LDAP Models [Page 17]
954 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
957 the vertices of a tree. Subtrees do not contain subentries. The
958 prefix sub, in subtree, emphasizes that the base (or root) vertex
959 of this tree is usually subordinate to the root of the DIT.
961 A subtree begins at some vertex and extends to some identifiable
962 lower boundary, possibly extending to leaves. A subtree is always
963 defined within a context which implicitly bounds the subtree. For
964 example, the vertex and lower boundaries of a subtree defining a
965 replicated area are bounded by a naming context.
970 A subentry is a "special sort of entry, known by the Directory, used
971 to hold information associated with a subtree or subtree refinement"
972 [X.501]. Subentries are used in Directory to hold for administrative
973 and operational purposes as defined in [X.501]. Their use in LDAP is
974 detailed in [RFC3672].
976 The term "(sub)entry" in this specification indicates that servers
977 implementing X.500(93) models are, in accordance with X.500(93) as
978 described in [RFC3672], to use a subentry and that other servers are
979 to use an object entry belonging to the appropriate auxiliary class
980 normally used with the subentry (e.g., 'subschema' for subschema
981 subentries) to mimic the subentry. This object entry's RDN SHALL be
982 formed from a value of the 'cn' (commonName) attribute [Schema] (as
983 all subentries are named with 'cn').
986 3.3. The 'objectClass' attribute
988 Each entry in the DIT has an 'objectClass' attribute.
990 ( 2.5.4.0 NAME 'objectClass'
991 EQUALITY objectIdentifierMatch
992 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
994 The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
995 (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
997 The 'objectClass' attribute specifies the object classes of an entry,
998 which (among other things) is used in conjunction with the controlling
999 schema to determine the permitted attributes of an entry. Values of
1000 this attribute can be modified by clients, but the 'objectClass'
1001 attribute cannot be removed.
1003 Servers which follow X.500(93) models SHALL restrict modifications of
1004 this attribute to prevent the basic structural class of the entry from
1008 Zeilenga LDAP Models [Page 18]
1010 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1013 being changed. That is, one cannot change a 'person' into a
1016 When creating an entry or adding an 'objectClass' value to an entry,
1017 all superclasses of the named classes SHALL be implicitly added as
1018 well if not already present. That is, if the auxiliary class 'x-a' is
1019 a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
1020 'x-b' to be implicitly added (if is not already present).
1022 Servers SHALL restrict modifications of this attribute to prevent
1023 superclasses of remaining 'objectClass' values from being deleted.
1024 That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
1025 class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
1026 an attempt to delete only 'x-b' from the 'objectClass' attribute is an
1030 3.4. Operational attributes
1032 Some attributes, termed operational attributes, are used or maintained
1033 by servers for administrative and operational purposes. As stated in
1034 [X.501]: "There are three varieties of operational attributes:
1035 Directory operational attributes, DSA-shared operational attributes,
1036 and DSA-specific operational attributes."
1038 A directory operational attribute is used to represent operational
1039 and/or administrative information in the Directory Information Model.
1040 This includes operational attributes maintained by the server (e.g.
1041 'createTimestamp') as well as operational attributes which hold values
1042 administrated by the user (e.g. 'ditContentRules').
1044 A DSA-shared operational attribute is used to represent information of
1045 the DSA Information Model which is shared between DSAs.
1047 A DSA-specific operational attribute is used to represent information
1048 of the DSA Information Model which is specific to the DSA (though, in
1049 some cases, may be derived from information shared between DSAs)
1050 (e.g., 'namingContexts').
1052 The DSA Information Model operational attributes are detailed in
1055 Operational attributes are not normally visible. They are not
1056 returned in search results unless explicitly requested by name.
1058 Not all operational attributes are user modifiable.
1060 Entries may contain, among others, the following operational
1064 Zeilenga LDAP Models [Page 19]
1066 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1071 - creatorsName: the Distinguished Name of the user who added this
1072 entry to the directory,
1074 - createTimestamp: the time this entry was added to the directory,
1076 - modifiersName: the Distinguished Name of the user who last
1077 modified this entry, and
1079 - modifyTimestamp: the time this entry was last modified.
1081 Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
1082 'modifiersName', and 'modifyTimestamp' attributes for all entries of
1086 3.4.1. 'creatorsName'
1088 This attribute appears in entries which were added using the protocol
1089 (e.g., using the Add operation). The value is the distinguished name
1092 ( 2.5.18.3 NAME 'creatorsName'
1093 EQUALITY distinguishedNameMatch
1094 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1095 SINGLE-VALUE NO-USER-MODIFICATION
1096 USAGE directoryOperation )
1098 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1099 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1102 3.4.2. 'createTimestamp'
1104 This attribute appears in entries which were added using the protocol
1105 (e.g., using the Add operation). The value is the time the entry was
1108 ( 2.5.18.1 NAME 'createTimestamp'
1109 EQUALITY generalizedTimeMatch
1110 ORDERING generalizedTimeOrderingMatch
1111 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1112 SINGLE-VALUE NO-USER-MODIFICATION
1113 USAGE directoryOperation )
1115 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1116 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1120 Zeilenga LDAP Models [Page 20]
1122 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1125 are defined in [Syntaxes].
1128 3.4.3. 'modifiersName'
1130 This attribute appears in entries which have been modified using the
1131 protocol (e.g., using Modify operation). The value is the
1132 distinguished name of the last modifier.
1134 ( 2.5.18.4 NAME 'modifiersName'
1135 EQUALITY distinguishedNameMatch
1136 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1137 SINGLE-VALUE NO-USER-MODIFICATION
1138 USAGE directoryOperation )
1140 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1141 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1144 3.4.4. 'modifyTimestamp'
1146 This attribute appears in entries which have been modified using the
1147 protocol (e.g., using the Modify operation). The value is the time
1148 the entry was last modified.
1150 ( 2.5.18.2 NAME 'modifyTimestamp'
1151 EQUALITY generalizedTimeMatch
1152 ORDERING generalizedTimeOrderingMatch
1153 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1154 SINGLE-VALUE NO-USER-MODIFICATION
1155 USAGE directoryOperation )
1157 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1158 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1159 are defined in [Syntaxes].
1162 3.4.5. 'structuralObjectClass'
1164 This attribute indicates the structural object class of the entry.
1166 ( 2.5.21.9 NAME 'structuralObjectClass'
1167 EQUALITY objectIdentifierMatch
1168 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
1169 SINGLE-VALUE NO-USER-MODIFICATION
1170 USAGE directoryOperation )
1172 The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
1176 Zeilenga LDAP Models [Page 21]
1178 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1181 (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
1184 3.4.6. 'governingStructureRule'
1186 This attribute indicates the structure rule governing the entry.
1188 ( 2.5.21.10 NAME 'governingStructureRule'
1189 EQUALITY integerMatch
1190 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1191 SINGLE-VALUE NO-USER-MODIFICATION
1192 USAGE directoryOperation )
1194 The 'integerMatch' matching rule and INTEGER
1195 (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
1200 As defined in [X.501]:
1202 The Directory Schema is a set of definitions and constraints
1203 concerning the structure of the DIT, the possible ways entries are
1204 named, the information that can be held in an entry, the
1205 attributes used to represent that information and their
1206 organization into hierarchies to facilitate search and retrieval
1207 of the information and the ways in which values of attributes may
1208 be matched in attribute value and matching rule assertions.
1210 NOTE 1 - The schema enables the Directory system to, for example:
1212 - prevent the creation of subordinate entries of the wrong
1213 object-class (e.g. a country as a subordinate of a person);
1215 - prevent the addition of attribute-types to an entry
1216 inappropriate to the object-class (e.g. a serial number to a
1219 - prevent the addition of an attribute value of a syntax not
1220 matching that defined for the attribute-type (e.g. a printable
1221 string to a bit string).
1223 Formally, the Directory Schema comprises a set of:
1225 a) Name Form definitions that define primitive naming relations
1226 for structural object classes;
1228 b) DIT Structure Rule definitions that define the names that
1232 Zeilenga LDAP Models [Page 22]
1234 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1237 entries may have and the ways in which the entries may be
1238 related to one another in the DIT;
1240 c) DIT Content Rule definitions that extend the specification of
1241 allowable attributes for entries beyond those indicated by the
1242 structural object classes of the entries;
1244 d) Object Class definitions that define the basic set of mandatory
1245 and optional attributes that shall be present, and may be
1246 present, respectively, in an entry of a given class, and which
1247 indicate the kind of object class that is being defined;
1249 e) Attribute Type definitions that identify the object identifier
1250 by which an attribute is known, its syntax, associated matching
1251 rules, whether it is an operational attribute and if so its
1252 type, whether it is a collective attribute, whether it is
1253 permitted to have multiple values and whether or not it is
1254 derived from another attribute type;
1256 f) Matching Rule definitions that define matching rules.
1260 g) LDAP Syntax definitions that define encodings used in LDAP.
1263 4.1. Schema Definitions
1265 Schema definitions in this section are described using ABNF and rely
1266 on the common productions specified in Section 1.2 as well as these:
1268 noidlen = numericoid [ LCURLY len RCURLY ]
1271 oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
1272 oidlist = oid *( WSP DOLLAR WSP oid )
1274 extensions = *( SP xstring SP qdstrings )
1275 xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
1277 qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
1278 qdescrlist = [ qdescr *( SP qdescr ) ]
1279 qdescr = SQUOTE descr SQUOTE
1281 qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
1282 qdstringlist = [ qdstring *( SP qdstring ) ]
1283 qdstring = SQUOTE dstring SQUOTE
1284 dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
1288 Zeilenga LDAP Models [Page 23]
1290 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1293 QQ = ESC %x32 %x37 ; "\27"
1294 QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
1296 ; Any UTF-8 encoded Unicode character
1297 ; except %x27 ("'") and %x5C ("\")
1298 QUTF8 = QUTF1 / UTFMB
1300 ; Any ASCII character except %x27 ("'") and %x5C ("\")
1301 QUTF1 = %x00-26 / %x28-5B / %x5D-7F
1303 Schema definitions in this section also share a number of common
1306 The NAME field provides a set of short names (descriptors) which are
1307 to be used as aliases for the OID.
1309 The DESC field optionally allows a descriptive string to be provided
1310 by the directory administrator and/or implementor. While
1311 specifications may suggest a descriptive string, there is no
1312 requirement that the suggested (or any) descriptive string be used.
1314 The OBSOLETE field, if present, indicates the element is not active.
1316 Implementors should note that future versions of this document may
1317 expand these definitions to include additional terms. Terms whose
1318 identifier begins with "X-" are reserved for private experiments, and
1319 are followed by <SP> and <qdstrings> tokens.
1322 4.1.1. Object Class Definitions
1324 Object Class definitions are written according to the ABNF:
1326 ObjectClassDescription = LPAREN WSP
1327 numericoid ; object identifier
1328 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1329 [ SP "DESC" SP qdstring ] ; description
1330 [ SP "OBSOLETE" ] ; not active
1331 [ SP "SUP" SP oids ] ; superior object classes
1332 [ SP kind ] ; kind of class
1333 [ SP "MUST" SP oids ] ; attribute types
1334 [ SP "MAY" SP oids ] ; attribute types
1335 extensions WSP RPAREN
1337 kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
1340 <numericoid> is object identifier assigned to this object class;
1344 Zeilenga LDAP Models [Page 24]
1346 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1349 NAME <qdescrs> are short names (descriptors) identifying this object
1351 DESC <qdstring> is a short descriptive string;
1352 OBSOLETE indicates this object class is not active;
1353 SUP <oids> specifies the direct superclasses of this object class;
1354 the kind of object class is indicated by one of ABSTRACT,
1355 STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
1356 MUST and MAY specify the sets of required and allowed attribute
1357 types, respectively; and
1358 <extensions> describe extensions.
1361 4.1.2. Attribute Types
1363 Attribute Type definitions are written according to the ABNF:
1365 AttributeTypeDescription = LPAREN WSP
1366 numericoid ; object identifier
1367 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1368 [ SP "DESC" SP qdstring ] ; description
1369 [ SP "OBSOLETE" ] ; not active
1370 [ SP "SUP" SP oid ] ; supertype
1371 [ SP "EQUALITY" SP oid ] ; equality matching rule
1372 [ SP "ORDERING" SP oid ] ; ordering matching rule
1373 [ SP "SUBSTR" SP oid ] ; substrings matching rule
1374 [ SP "SYNTAX" SP noidlen ] ; value syntax
1375 [ SP "SINGLE-VALUE" ] ; single-value
1376 [ SP "COLLECTIVE" ] ; collective
1377 [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
1378 [ SP "USAGE" SP usage ] ; usage
1379 extensions WSP RPAREN ; extensions
1381 usage = "userApplications" / ; user
1382 "directoryOperation" / ; directory operational
1383 "distributedOperation" / ; DSA-shared operational
1384 "dSAOperation" ; DSA-specific operational
1387 <numericoid> is object identifier assigned to this attribute type;
1388 NAME <qdescrs> are short names (descriptors) identifying this
1390 DESC <qdstring> is a short descriptive string;
1391 OBSOLETE indicates this attribute type is not active;
1392 SUP oid specifies the direct supertype of this type;
1393 EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
1394 ordering, and substrings matching rules, respectively;
1395 SYNTAX identifies value syntax by object identifier and may suggest
1396 a minimum upper bound;
1400 Zeilenga LDAP Models [Page 25]
1402 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1405 SINGLE-VALUE indicates attributes of this type are restricted to a
1407 COLLECTIVE indicates this attribute type is collective
1409 NO-USER-MODIFICATION indicates this attribute type is not user
1411 USAGE indicates the application of this attribute type; and
1412 <extensions> describe extensions.
1414 Each attribute type description must contain at least one of the SUP
1415 or SYNTAX fields. If no SYNTAX field is provided, the attribute type
1416 description takes its value from the supertype.
1418 If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
1419 fields, if not specified, take their value from the supertype.
1421 Usage of userApplications, the default, indicates that attributes of
1422 this type represent user information. That is, they are user
1425 A usage of directoryOperation, distributedOperation, or dSAOperation
1426 indicates that attributes of this type represent operational and/or
1427 administrative information. That is, they are operational attributes.
1429 directoryOperation usage indicates that the attribute of this type is
1430 a directory operational attribute. distributedOperation usage
1431 indicates that the attribute of this DSA-shared usage operational
1432 attribute. dSAOperation usage indicates that the attribute of this
1433 type is a DSA-specific operational attribute.
1435 COLLECTIVE requires usage userApplications. Use of collective
1436 attribute types in LDAP is discussed in [RFC3671].
1438 NO-USER-MODIFICATION requires an operational usage.
1440 Note that the <AttributeTypeDescription> does not list the matching
1441 rules which can be used with that attribute type in an extensibleMatch
1442 search filter [Protocol]. This is done using the 'matchingRuleUse'
1443 attribute described in Section 4.1.4.
1445 This document refines the schema description of X.501 by requiring
1446 that the SYNTAX field in an <AttributeTypeDescription> be a string
1447 representation of an object identifier for the LDAP string syntax
1448 definition with an optional indication of the suggested minimum bound
1449 of a value of this attribute.
1451 A suggested minimum upper bound on the number of characters in a value
1452 with a string-based syntax, or the number of bytes in a value for all
1456 Zeilenga LDAP Models [Page 26]
1458 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1461 other syntaxes, may be indicated by appending this bound count inside
1462 of curly braces following the syntax's OBJECT IDENTIFIER in an
1463 Attribute Type Description. This bound is not part of the syntax name
1464 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
1465 implementations should allow a string to be 64 characters long,
1466 although they may allow longer strings. Note that a single character
1467 of the Directory String syntax may be encoded in more than one octet
1468 since UTF-8 [RFC3629] is a variable-length encoding.
1471 4.1.3. Matching Rules
1473 Matching rules are used in performance of attribute value assertions,
1474 such as in performance of a Compare operation. They are also used in
1475 evaluation of a Search filters, in determining which individual values
1476 are be added or deleted during performance of a Modify operation, and
1477 used in comparison of distinguished names.
1479 Each matching rule is identified by an object identifier (OID) and,
1480 optionally, one or more short names (descriptors).
1482 Matching rule definitions are written according to the ABNF:
1484 MatchingRuleDescription = LPAREN WSP
1485 numericoid ; object identifier
1486 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1487 [ SP "DESC" SP qdstring ] ; description
1488 [ SP "OBSOLETE" ] ; not active
1489 SP "SYNTAX" SP numericoid ; assertion syntax
1490 extensions WSP RPAREN ; extensions
1493 <numericoid> is object identifier assigned to this matching rule;
1494 NAME <qdescrs> are short names (descriptors) identifying this
1496 DESC <qdstring> is a short descriptive string;
1497 OBSOLETE indicates this matching rule is not active;
1498 SYNTAX identifies the assertion syntax (the syntax of the assertion
1499 value) by object identifier; and
1500 <extensions> describe extensions.
1503 4.1.4. Matching Rule Uses
1505 A matching rule use lists the attribute types which are suitable for
1506 use with an extensibleMatch search filter.
1508 Matching rule use descriptions are written according to the following
1512 Zeilenga LDAP Models [Page 27]
1514 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1519 MatchingRuleUseDescription = LPAREN WSP
1520 numericoid ; object identifier
1521 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1522 [ SP "DESC" SP qdstring ] ; description
1523 [ SP "OBSOLETE" ] ; not active
1524 SP "APPLIES" SP oids ; attribute types
1525 extensions WSP RPAREN ; extensions
1528 <numericoid> is the object identifier of the matching rule
1529 associated with this matching rule use description;
1530 NAME <qdescrs> are short names (descriptors) identifying this
1532 DESC <qdstring> is a short descriptive string;
1533 OBSOLETE indicates this matching rule use is not active;
1534 APPLIES provides a list of attribute types the matching rule applies
1536 <extensions> describe extensions.
1539 4.1.5. LDAP Syntaxes
1541 LDAP Syntaxes of (attribute and assertion) values are described in
1542 terms of ASN.1 [X.680] and, optionally, have an octet string encoding
1543 known as the LDAP-specific encoding. Commonly, the LDAP-specific
1544 encoding is constrained to a string of Unicode [Unicode] characters in
1545 UTF-8 [RFC3629] form.
1547 Each LDAP syntax is identified by an object identifier (OID).
1549 LDAP syntax definitions are written according to the ABNF:
1551 SyntaxDescription = LPAREN WSP
1552 numericoid ; object identifier
1553 [ SP "DESC" SP qdstring ] ; description
1554 extensions WSP RPAREN ; extensions
1557 <numericoid> is the object identifier assigned to this LDAP syntax;
1558 DESC <qdstring> is a short descriptive string; and
1559 <extensions> describe extensions.
1562 4.1.6. DIT Content Rules
1564 A DIT content rule is a "rule governing the content of entries of a
1568 Zeilenga LDAP Models [Page 28]
1570 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1573 particular structural object class" [X.501].
1575 For DIT entries of a particular structural object class, a DIT content
1576 rule specifies which auxiliary object classes the entries are allowed
1577 to belong to and which additional attributes (by type) are required,
1578 allowed or not allowed to appear in the entries.
1580 The list of precluded attributes cannot include any attribute listed
1581 as mandatory in the rule, the structural object class, or any of the
1582 allowed auxiliary object classes.
1584 Each content rule is identified by the object identifier, as well as
1585 any short names (descriptors), of the structural object class it
1588 An entry may only belong to auxiliary object classes listed in the
1589 governing content rule.
1591 An entry must contain all attributes required by the object classes
1592 the entry belongs to as well as all attributes required by the
1593 governing content rule.
1595 An entry may contain any non-precluded attributes allowed by the
1596 object classes the entry belongs to as well as all attributes allowed
1597 by the governing content rule.
1599 An entry cannot include any attribute precluded by the governing
1602 An entry is governed by (if present and active in the subschema) the
1603 DIT content rule which applies to the structural object class of the
1604 entry (see Section 2.4.2). If no active rule is present for the
1605 entry's structural object class, the entry's content is governed by
1606 the structural object class (and possibly other aspects of user and
1607 system schema). DIT content rules for superclasses of the structural
1608 object class of an entry are not applicable to that entry.
1610 DIT content rule descriptions are written according to the ABNF:
1612 DITContentRuleDescription = LPAREN WSP
1613 numericoid ; object identifier
1614 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1615 [ SP "DESC" SP qdstring ] ; description
1616 [ SP "OBSOLETE" ] ; not active
1617 [ SP "AUX" SP oids ] ; auxiliary object classes
1618 [ SP "MUST" SP oids ] ; attribute types
1619 [ SP "MAY" SP oids ] ; attribute types
1620 [ SP "NOT" SP oids ] ; attribute types
1624 Zeilenga LDAP Models [Page 29]
1626 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1629 extensions WSP RPAREN ; extensions
1632 <numericoid> is the object identifier of the structural object class
1633 associated with this DIT content rule;
1634 NAME <qdescrs> are short names (descriptors) identifying this DIT
1636 DESC <qdstring> is a short descriptive string;
1637 OBSOLETE indicates this DIT content rule use is not active;
1638 AUX specifies a list of auxiliary object classes which entries
1639 subject to this DIT content rule may belong to;
1640 MUST, MAY, and NOT specify lists of attribute types which are
1641 required, allowed, or precluded, respectively, from appearing in
1642 entries subject to this DIT content rule; and
1643 <extensions> describe extensions.
1646 4.1.7. DIT Structure Rules and Name Forms
1648 It is sometimes desirable to regulate where object and alias entries
1649 can be placed in the DIT and how they can be named based upon their
1650 structural object class.
1653 4.1.7.1. DIT Structure Rules
1655 A DIT structure rule is a "rule governing the structure of the DIT by
1656 specifying a permitted superior to subordinate entry relationship. A
1657 structure rule relates a name form, and therefore a structural object
1658 class, to superior structure rules. This permits entries of the
1659 structural object class identified by the name form to exist in the
1660 DIT as subordinates to entries governed by the indicated superior
1661 structure rules" [X.501].
1663 DIT structure rule descriptions are written according to the ABNF:
1665 DITStructureRuleDescription = LPAREN WSP
1666 ruleid ; rule identifier
1667 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1668 [ SP "DESC" SP qdstring ] ; description
1669 [ SP "OBSOLETE" ] ; not active
1670 SP "FORM" SP oid ; NameForm
1671 [ SP "SUP" ruleids ] ; superior rules
1672 extensions WSP RPAREN ; extensions
1674 ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
1675 ruleidlist = ruleid *( SP ruleid )
1680 Zeilenga LDAP Models [Page 30]
1682 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1686 <ruleid> is the rule identifier of this DIT structure rule;
1687 NAME <qdescrs> are short names (descriptors) identifying this DIT
1689 DESC <qdstring> is a short descriptive string;
1690 OBSOLETE indicates this DIT structure rule use is not active;
1691 FORM is specifies the name form associated with this DIT structure
1693 SUP identifies superior rules (by rule id); and
1694 <extensions> describe extensions.
1696 If no superior rules are identified, the DIT structure rule applies
1697 to an autonomous administrative point (e.g. the root vertex of the
1698 subtree controlled by the subschema) [X.501].
1703 A name form "specifies a permissible RDN for entries of a particular
1704 structural object class. A name form identifies a named object
1705 class and one or more attribute types to be used for naming (i.e.
1706 for the RDN). Name forms are primitive pieces of specification
1707 used in the definition of DIT structure rules" [X.501].
1709 Each name form indicates the structural object class to be named,
1710 a set of required attribute types, and a set of allowed attribute
1711 types. A particular attribute type cannot be in both sets.
1713 Entries governed by the form must be named using a value from each
1714 required attribute type and zero or more values from the allowed
1717 Each name form is identified by an object identifier (OID) and,
1718 optionally, one or more short names (descriptors).
1720 Name form descriptions are written according to the ABNF:
1722 NameFormDescription = LPAREN WSP
1723 numericoid ; object identifier
1724 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1725 [ SP "DESC" SP qdstring ] ; description
1726 [ SP "OBSOLETE" ] ; not active
1727 SP "OC" SP oid ; structural object class
1728 SP "MUST" SP oids ; attribute types
1729 [ SP "MAY" SP oids ] ; attribute types
1730 extensions WSP RPAREN ; extensions
1736 Zeilenga LDAP Models [Page 31]
1738 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1741 <numericoid> is object identifier which identifies this name form;
1742 NAME <qdescrs> are short names (descriptors) identifying this name
1744 DESC <qdstring> is a short descriptive string;
1745 OBSOLETE indicates this name form is not active;
1746 OC identifies the structural object class this rule applies to,
1747 MUST and MAY specify the sets of required and allowed, respectively,
1748 naming attributes for this name form; and
1749 <extensions> describe extensions.
1751 All attribute types in the required ("MUST") and allowed ("MAY") lists
1755 4.2. Subschema Subentries
1757 Subschema (sub)entries are used for administering information about
1758 the directory schema. A single subschema (sub)entry contains all
1759 schema definitions (see Section 4.1) used by entries in a particular
1760 part of the directory tree.
1762 Servers which follow X.500(93) models SHOULD implement subschema using
1763 the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
1764 and so these are not ordinary object entries but subentries (see
1765 Section 3.2). LDAP clients SHOULD NOT assume that servers implement
1766 any of the other aspects of X.500 subschema.
1768 Servers MAY allow subschema modification. Procedures for subschema
1769 modification are discussed in Section 14.5 of [X.501].
1771 A server which masters entries and permits clients to modify these
1772 entries SHALL implement and provide access to these subschema
1773 (sub)entries including providing a 'subschemaSubentry' attribute in
1774 each modifiable entry. This is so clients may discover the attributes
1775 and object classes which are permitted to be present. It is strongly
1776 RECOMMENDED that all other servers implement this as well.
1778 The value of the 'subschemaSubentry' attribute is the name of the
1779 subschema (sub)entry holding the subschema controlling the entry.
1781 ( 2.5.18.10 NAME 'subschemaSubentry'
1782 EQUALITY distinguishedNameMatch
1783 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1784 NO-USER-MODIFICATION SINGLE-VALUE
1785 USAGE directoryOperation )
1787 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1788 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1792 Zeilenga LDAP Models [Page 32]
1794 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1797 Subschema is held in (sub)entries belonging to the subschema auxiliary
1800 ( 2.5.20.1 NAME 'subschema' AUXILIARY
1801 MAY ( dITStructureRules $ nameForms $ ditContentRules $
1802 objectClasses $ attributeTypes $ matchingRules $
1805 The 'ldapSyntaxes' operational attribute may also be present in
1808 Servers MAY provide additional attributes (described in other
1809 documents) in subschema (sub)entries.
1811 Servers SHOULD provide the attributes 'createTimestamp' and
1812 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
1813 to maintain their caches of schema information.
1815 The following subsections provide attribute type definitions for each
1816 of schema definition attribute types.
1819 4.2.1. 'objectClasses'
1821 This attribute holds definitions of object classes.
1823 ( 2.5.21.6 NAME 'objectClasses'
1824 EQUALITY objectIdentifierFirstComponentMatch
1825 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
1826 USAGE directoryOperation )
1828 The 'objectIdentifierFirstComponentMatch' matching rule and the
1829 ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
1830 defined in [Syntaxes].
1833 4.2.2. 'attributeTypes'
1835 This attribute holds definitions of attribute types.
1837 ( 2.5.21.5 NAME 'attributeTypes'
1838 EQUALITY objectIdentifierFirstComponentMatch
1839 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
1840 USAGE directoryOperation )
1842 The 'objectIdentifierFirstComponentMatch' matching rule and the
1843 AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
1844 defined in [Syntaxes].
1848 Zeilenga LDAP Models [Page 33]
1850 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1853 4.2.3. 'matchingRules'
1855 This attribute holds definitions of matching rules.
1857 ( 2.5.21.4 NAME 'matchingRules'
1858 EQUALITY objectIdentifierFirstComponentMatch
1859 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
1860 USAGE directoryOperation )
1862 The 'objectIdentifierFirstComponentMatch' matching rule and the
1863 MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
1864 defined in [Syntaxes].
1867 4.2.4 'matchingRuleUse'
1869 This attribute holds definitions of matching rule uses.
1871 ( 2.5.21.8 NAME 'matchingRuleUse'
1872 EQUALITY objectIdentifierFirstComponentMatch
1873 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
1874 USAGE directoryOperation )
1876 The 'objectIdentifierFirstComponentMatch' matching rule and the
1877 MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
1878 defined in [Syntaxes].
1881 4.2.5. 'ldapSyntaxes'
1883 This attribute holds definitions of LDAP syntaxes.
1885 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
1886 EQUALITY objectIdentifierFirstComponentMatch
1887 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
1888 USAGE directoryOperation )
1890 The 'objectIdentifierFirstComponentMatch' matching rule and the
1891 SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
1895 4.2.6. 'dITContentRules'
1897 This attribute lists DIT Content Rules which are present in the
1900 ( 2.5.21.2 NAME 'dITContentRules'
1904 Zeilenga LDAP Models [Page 34]
1906 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1909 EQUALITY objectIdentifierFirstComponentMatch
1910 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
1911 USAGE directoryOperation )
1913 The 'objectIdentifierFirstComponentMatch' matching rule and the
1914 DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
1915 defined in [Syntaxes].
1918 4.2.7. 'dITStructureRules'
1920 This attribute lists DIT Structure Rules which are present in the
1923 ( 2.5.21.1 NAME 'dITStructureRules'
1924 EQUALITY integerFirstComponentMatch
1925 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
1926 USAGE directoryOperation )
1928 The 'integerFirstComponentMatch' matching rule and the
1929 DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
1930 defined in [Syntaxes].
1935 This attribute lists Name Forms which are in force.
1937 ( 2.5.21.7 NAME 'nameForms'
1938 EQUALITY objectIdentifierFirstComponentMatch
1939 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
1940 USAGE directoryOperation )
1942 The 'objectIdentifierFirstComponentMatch' matching rule and the
1943 NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
1947 4.3. 'extensibleObject' object class
1949 The 'extensibleObject' auxiliary object class allows entries that
1950 belong to it to hold any user attribute. The set of allowed attribute
1951 types of this object class is implicitly the set of all attribute
1952 types of userApplications usage.
1954 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
1960 Zeilenga LDAP Models [Page 35]
1962 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
1965 The mandatory attributes of the other object classes of this entry are
1966 still required to be present and any precluded attributes are still
1967 not allowed to be present.
1971 4.4. Subschema Discovery
1973 To discover the DN of the subschema (sub)entry holding the subschema
1974 controlling a particular entry, a client reads that entry's
1975 'subschemaSubentry' operational attribute. To read schema attributes
1976 from the subschema (sub)entry, clients MUST issue a Search operation
1977 [Protocol] where baseObject is the DN of the subschema (sub)entry,
1978 scope is baseObject, filter is "(objectClass=subschema)" [Filters],
1979 and attributes field lists the names of the desired schema attributes
1980 (as they are operational). Note: the "(objectClass=subschema)" filter
1981 allows LDAP servers which gateway to X.500 to detect that subentry
1982 information is being requested.
1984 Clients SHOULD NOT assume a published subschema is complete nor assume
1985 the server supports all of the schema elements it publishes nor assume
1986 the server does not support an unpublished element.
1989 5. DSA (Server) Informational Model
1991 The LDAP protocol assumes there are one or more servers which jointly
1992 provide access to a Directory Information Tree (DIT). The server
1993 holding the original information is called the "master" (for that
1994 information). Servers which hold copies of the original information
1995 are referred to as "shadowing" or "caching" servers.
1997 As defined in [X.501]:
1999 context prefix: The sequence of RDNs leading from the Root of the
2000 DIT to the initial vertex of a naming context; corresponds to
2001 the distinguished name of that vertex.
2005 naming context: A subtree of entries held in a single master DSA.
2007 That is, a naming context is the largest collection of entries,
2008 starting at an entry that is mastered by a particular server, and
2009 including all its subordinates and their subordinates, down to the
2010 entries which are mastered by different servers. The context prefix
2011 is the name of the initial entry.
2016 Zeilenga LDAP Models [Page 36]
2018 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2021 The root of the DIT is a DSA-specific Entry (DSE) and not part of any
2022 naming context (or any subtree); each server has different attribute
2023 values in the root DSE.
2026 5.1. Server-specific Data Requirements
2028 An LDAP server SHALL provide information about itself and other
2029 information that is specific to each server. This is represented as a
2030 group of attributes located in the root DSE, which is named with the
2031 DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
2034 These attributes are retrievable, subject to access control and other
2035 restrictions, if a client performs a Search operation [Protocol] with
2036 an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
2037 [Filters], and with the attributes field listing the names of the
2038 desired attributes. It is noted that root DSE attributes are
2039 operational, and like other operational attributes, are not returned
2040 in search requests unless requested by name.
2042 The root DSE SHALL NOT be included if the client performs a subtree
2043 search starting from the root.
2045 Servers may allow clients to modify attributes of the root DSE where
2048 The following attributes of the root DSE are defined in [Syntaxes].
2049 Additional attributes may be defined in other documents.
2051 - altServer: alternative servers;
2053 - namingContexts: naming contexts;
2055 - supportedControl: recognized LDAP controls;
2057 - supportedExtension: recognized LDAP extended operations;
2059 - supportedFeatures: recognized LDAP features;
2061 - supportedLDAPVersion: LDAP versions supported; and
2063 - supportedSASLMechanisms: recognized Simple Authentication and
2064 Security Layers (SASL) [SASL] mechanisms.
2066 The values provided for these attributes may depend on
2067 session-specific and other factors. For example, a server supporting
2068 the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
2072 Zeilenga LDAP Models [Page 37]
2074 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2077 client's identity has been established by a lower level. See
2080 The root DSE may also include a 'subschemaSubentry' attribute. If so,
2081 it refers to the subschema (sub)entry holding the schema controlling
2082 the root DSE. Clients SHOULD NOT assume that this subschema
2083 (sub)entry controls other entries held by the server. General
2084 subschema discovery procedures are provided in Section 4.4.
2089 The 'altServer' attribute lists URIs referring to alternative servers
2090 which may be contacted when this server becomes unavailable. URIs for
2091 servers implementing the LDAP are written according to [LDAPURL].
2092 Other kinds of URIs may be provided. If the server does not know of
2093 any other servers which could be used this attribute will be absent.
2094 Clients may cache this information in case their preferred server
2095 later becomes unavailable.
2097 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
2098 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
2099 USAGE dSAOperation )
2101 The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
2105 5.1.2. 'namingContexts'
2107 The 'namingContexts' attribute lists the context prefixes of the
2108 naming contexts the server masters or shadows (in part or in whole).
2109 If the server is a first-level DSA [X.501], it should list (in
2110 addition) an empty string (indicating the root of the DIT). If the
2111 server does not master or shadow any information (e.g. it is an LDAP
2112 gateway to a public X.500 directory) this attribute will be absent.
2113 If the server believes it masters or shadows the entire directory, the
2114 attribute will have a single value, and that value will be the empty
2115 string (indicating the root of the DIT).
2117 This attribute may be used, for example, to select a suitable entry
2118 name for subsequent operations with this server.
2120 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
2121 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2122 USAGE dSAOperation )
2124 The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
2128 Zeilenga LDAP Models [Page 38]
2130 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2133 defined in [Syntaxes].
2136 5.1.3. 'supportedControl'
2138 The 'supportedControl' attribute lists object identifiers identifying
2139 the request controls [Protocol] the server supports. If the server
2140 does not support any request controls, this attribute will be absent.
2141 Object identifiers identifying response controls need not be listed.
2143 Procedures for registering object identifiers used to discovery of
2144 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2146 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
2147 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2148 USAGE dSAOperation )
2150 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2151 defined in [Syntaxes].
2154 5.1.4. 'supportedExtension'
2156 The 'supportedExtension' attribute lists object identifiers
2157 identifying the extended operations [Protocol] which the server
2158 supports. If the server does not support any extended operations,
2159 this attribute will be absent.
2161 An extended operation generally consists of an extended request and an
2162 extended response but may also include other protocol data units (such
2163 as intermediate responses). The object identifier assigned to the
2164 extended request is used to identify the extended operation. Other
2165 object identifiers used in the extended operation need not be listed
2166 as values of this attribute.
2168 Procedures for registering object identifiers used to discovery of
2169 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2171 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
2172 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2173 USAGE dSAOperation )
2175 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2176 defined in [Syntaxes].
2179 5.1.5. 'supportedFeatures'
2184 Zeilenga LDAP Models [Page 39]
2186 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2189 The 'supportedFeatures' attribute lists object identifiers identifying
2190 elective features which the server supports. If the server does not
2191 support any discoverable elective features, this attribute will be
2194 ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
2195 EQUALITY objectIdentifierMatch
2196 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2197 USAGE dSAOperation )
2199 Procedures for registering object identifiers used to discovery of
2200 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2202 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
2203 objectIdentifierMatch matching rule are defined in [Syntaxes].
2206 5.1.6. 'supportedLDAPVersion'
2208 The 'supportedLDAPVersion' attribute lists the versions of LDAP which
2209 the server supports.
2211 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
2212 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2213 USAGE dSAOperation )
2215 The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
2219 5.1.7. 'supportedSASLMechanisms'
2221 The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
2222 [SASL] which the server recognizes and/or supports [AuthMeth]. The
2223 contents of this attribute may depend on the current session state.
2224 If the server does not support any SASL mechanisms this attribute will
2227 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
2228 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2229 USAGE dSAOperation )
2231 The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
2235 6. Other Considerations
2240 Zeilenga LDAP Models [Page 40]
2242 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2245 6.1. Preservation of User Information
2247 Syntaxes may be defined which have specific value and/or value form
2248 (representation) preservation requirements. For example, a syntax
2249 containing digitally signed data can mandate the server preserve both
2250 the value and form of value presented to ensure signature is not
2253 Where such requirements have not been explicitly stated, servers
2254 SHOULD preserve the value of user information but MAY return the value
2255 in a different form. And where a server is unable (or unwilling) to
2256 preserve the value of user information, the server SHALL ensure that
2257 an equivalent value (per Section 2.3) is returned.
2262 Short names, also known as descriptors, are used as more readable
2263 aliases for object identifiers and are used to identify various schema
2264 elements. However, it is not expected that LDAP implementations with
2265 human user interface would display these short names (nor the object
2266 identifiers they refer to) to the user, but would most likely be
2267 performing translations (such as expressing the short name in one of
2268 the local national languages). For example, the short name "st"
2269 (stateOrProvinceName) might be displayed to a German-speaking user as
2272 The same short name might have different meaning in different
2273 subschemas and, within a particular subschema, the same short name
2274 might refer to different object identifiers each identifying a
2275 different kind of schema element.
2277 Implementations MUST be prepared that the same short name might be
2278 used in a subschema to refer to the different kinds of schema
2279 elements. That is, there might be an object class 'x-fubar' and an
2280 attribute type 'x-fubar' in a subschema.
2282 Implementations MUST be prepared that the same short name might be
2283 used in the different subschemas to refer to the different schema
2284 elements. That is, there might be two matching rules 'x-fubar', each
2285 in different subschemas.
2287 Procedures for registering short names (descriptors) are detailed in
2291 6.3. Cache and Shadowing
2296 Zeilenga LDAP Models [Page 41]
2298 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2301 Some servers may hold cache or shadow copies of entries, which can be
2302 used to answer search and comparison queries, but will return
2303 referrals or contact other servers if modification operations are
2304 requested. Servers that perform shadowing or caching MUST ensure that
2305 they do not violate any access control constraints placed on the data
2306 by the originating server.
2309 7. Implementation Guidelines
2311 7.1 Server Guidelines
2313 Servers MUST recognize all names of attribute types and object classes
2314 defined in this document but, unless stated otherwise, need not
2315 support the associated functionality. Servers SHOULD recognize all
2316 the names of attribute types and object classes defined in Section 3
2317 and 4, respectively, of [Schema].
2319 Servers MUST ensure that entries conform to user and system schema
2320 rules or other data model constraints.
2322 Servers MAY support DIT Content Rules. Servers MAY support DIT
2323 Structure Rules and Name Forms.
2325 Servers MAY support alias entries.
2327 Servers MAY support the 'extensibleObject' object class.
2329 Servers MAY support subentries. If so, they MUST do so in accordance
2330 with [RFC3672]. Servers which do not support subentries SHOULD use
2331 object entries to mimic subentries as detailed in Section 3.2.
2333 Servers MAY implement additional schema elements. Servers SHOULD
2334 provide definitions of all schema elements they support in subschema
2338 7.2 Client Guidelines
2340 In the absence of prior agreements with servers, clients SHOULD NOT
2341 assume that servers support any particular schema elements beyond
2342 those referenced in Section 7.1. The client can retrieve subschema
2343 information as described in Section 4.4.
2345 Clients MUST NOT display nor attempt to decode as ASN.1, a value if
2346 its syntax is not known. Clients MUST NOT assume the LDAP-specific
2347 string encoding is restricted to a UTF-8 encoded string of Unicode
2348 characters or any particular subset of Unicode (such as a printable
2352 Zeilenga LDAP Models [Page 42]
2354 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2357 subset) unless such restriction is explicitly stated. Clients SHOULD
2358 NOT send attribute values in a request that are not valid according to
2359 the syntax defined for the attributes.
2362 8. Security Considerations
2364 Attributes of directory entries are used to provide descriptive
2365 information about the real-world objects they represent, which can be
2366 people, organizations or devices. Most countries have privacy laws
2367 regarding the publication of information about people.
2369 General security considerations for accessing directory information
2370 with LDAP are discussed in [Protocol] and [AuthMeth].
2373 9. IANA Considerations
2375 It is requested that the Internet Assigned Numbers Authority (IANA)
2376 update the LDAP descriptors registry as indicated in the following
2379 Subject: Request for LDAP Descriptor Registration Update
2380 Descriptor (short name): see comment
2381 Object Identifier: see comment
2382 Person & email address to contact for further information:
2383 Kurt Zeilenga <kurt@OpenLDAP.org>
2385 Specification: RFC XXXX
2386 Author/Change Controller: IESG
2389 The following descriptors (short names) should be added to
2393 ------------------------ ---- -----------------
2394 governingStructureRule A 2.5.21.10
2395 structuralObjectClass A 2.5.21.9
2397 The following descriptors (short names) should be updated to
2401 ------------------------ ---- -----------------
2403 aliasedObjectName A 2.5.4.1
2404 altServer A 1.3.6.1.4.1.1466.101.120.6
2408 Zeilenga LDAP Models [Page 43]
2410 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2413 attributeTypes A 2.5.21.5
2414 createTimestamp A 2.5.18.1
2415 creatorsName A 2.5.18.3
2416 dITContentRules A 2.5.21.2
2417 dITStructureRules A 2.5.21.1
2418 extensibleObject O 1.3.6.1.4.1.1466.101.120.111
2419 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
2420 matchingRuleUse A 2.5.21.8
2421 matchingRules A 2.5.21.4
2422 modifiersName A 2.5.18.4
2423 modifyTimestamp A 2.5.18.2
2424 nameForms A 2.5.21.7
2425 namingContexts A 1.3.6.1.4.1.1466.101.120.5
2426 objectClass A 2.5.4.0
2427 objectClasses A 2.5.21.6
2428 subschema O 2.5.20.1
2429 subschemaSubentry A 2.5.18.10
2430 supportedControl A 1.3.6.1.4.1.1466.101.120.13
2431 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
2432 supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
2433 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
2434 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
2440 This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
2441 S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
2442 RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
2443 Indexing of Directories (ASID) Working Group. This document is also
2444 based in part on "The Directory: Models" [X.501], a product of the
2445 International Telephone Union (ITU). Additional text was borrowed
2446 from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
2448 This document is a product of the IETF LDAP Revision (LDAPBIS) Working
2452 11. Editor's Address
2457 Email: Kurt@OpenLDAP.org
2464 Zeilenga LDAP Models [Page 44]
2466 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2469 [[Note to the RFC Editor: please replace the citation tags used in
2470 referencing Internet-Drafts with tags of the form RFCnnnn where
2474 12.1. Normative References
2476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2477 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
2479 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2480 Specifications: ABNF", RFC 2234, November 1997.
2482 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
2483 10646", RFC 3629 (also STD 63), November 2003.
2485 [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
2488 [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
2489 3672, December 2003.
2491 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
2492 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
2494 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
2495 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
2498 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
2499 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
2501 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
2502 Connection Level Security Mechanisms",
2503 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
2505 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
2506 Representation of Search Filters",
2507 draft-ietf-ldapbis-filter-xx.txt, a work in progress.
2509 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
2510 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
2513 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
2514 draft-ietf-ldapbis-url-xx.txt, a work in progress.
2516 [SASL] Melnikov, A. (Editor), "Simple Authentication and
2520 Zeilenga LDAP Models [Page 45]
2522 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2525 Security Layer (SASL)",
2526 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
2528 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
2529 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
2531 [Schema] Dally, K. (editor), "LDAP: User Schema",
2532 draft-ietf-ldapbis-user-schema-xx.txt, a work in
2535 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
2536 3.2.0" is defined by "The Unicode Standard, Version 3.0"
2537 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
2538 as amended by the "Unicode Standard Annex #27: Unicode
2539 3.1" (http://www.unicode.org/reports/tr27/) and by the
2540 "Unicode Standard Annex #28: Unicode 3.2"
2541 (http://www.unicode.org/reports/tr28/).
2543 [X.500] International Telecommunication Union -
2544 Telecommunication Standardization Sector, "The Directory
2545 -- Overview of concepts, models and services,"
2546 X.500(1993) (also ISO/IEC 9594-1:1994).
2548 [X.501] International Telecommunication Union -
2549 Telecommunication Standardization Sector, "The Directory
2550 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
2552 [X.680] International Telecommunication Union -
2553 Telecommunication Standardization Sector, "Abstract
2554 Syntax Notation One (ASN.1) - Specification of Basic
2555 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
2558 12.2. Informative References
2565 This appendix is non-normative.
2567 This document amounts to nearly a complete rewrite of portions of RFC
2568 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
2569 overall clarity of technical specification. This appendix provides a
2570 summary of substantive changes made to the portions of these documents
2571 incorporated into this document. Readers should consult [Roadmap],
2572 [Protocol], [Syntaxes], and [Schema] for summaries of remaining
2576 Zeilenga LDAP Models [Page 46]
2578 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2581 portions of these documents.
2584 A.1 Changes to RFC 2251
2586 This document incorporates from RFC 2251 sections 3.2 and 3.4,
2587 portions of Section 4 and 6 as summarized below.
2590 A.1.1 Section 3.2 of RFC 2251
2592 Section 3.2 of RFC 2251 provided a brief introduction to the X.500
2593 data model, as used by LDAP. The previous specification relied on
2594 [X.501] but lacked clarity in how X.500 models are adapted for use by
2595 LDAP. This document describes the X.500 data models, as used by LDAP
2596 in greater detail, especially in areas where adaptation is needed.
2598 Section 3.2.1 of RFC 2251 described an attribute as "a type with one
2599 or more associated values." In LDAP, an attribute is better described
2600 as an attribute description, a type with zero or more options, and one
2601 or more associated values.
2603 Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
2604 objectClasses and attributeTypes attributes, yet X.500(93) treats
2605 these attributes as optional. While generally all implementations
2606 that support X.500(93) subschema mechanisms will provide both of these
2607 attributes, it is not absolutely required for interoperability that
2608 all servers do. The mandate was removed for consistency with
2609 X.500(93). The subschema discovery mechanism was also clarified to
2610 indicate that subschema controlling an entry is obtained by reading
2611 the (sub)entry referred to by that entry's 'subschemaSubentry'
2615 A.1.2 Section 3.4 of RFC 2251
2617 Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
2618 This material, with changes, was incorporated in Section 5.1 of this
2623 - Clarify that attributes of the root DSE are subject to "other
2624 restrictions" in addition to access controls.
2626 - Clarify that only recognized extended requests need to be enumerated
2627 'supportedExtension'.
2632 Zeilenga LDAP Models [Page 47]
2634 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2637 - Clarify that only recognized request controls need to be enumerated
2640 - Clarify that root DSE attributes are operational and, like other
2641 operational attributes, will not be returned in search requests
2642 unless requested by name.
2644 - Clarify that not all root DSE attributes are user modifiable.
2646 - Remove inconsistent text regarding handling of the
2647 'subschemaSubentry' attribute within the root DSE. The previous
2648 specification stated that the 'subschemaSubentry' attribute held in
2649 the root DSE referred to "subschema entries (or subentries) known by
2650 this server." This is inconsistent with the attribute intended use
2651 as well as its formal definition as a single valued attribute
2652 [X.501]. It is also noted that a simple (possibly incomplete) list
2653 of subschema (sub)entries is not terrible useful. This document (in
2654 section 5.1) specifies that the 'subschemaSubentry' attribute of the
2655 root DSE refers to the subschema controlling the root DSE. It is
2656 noted that the general subschema discovery mechanism remains
2657 available (see Section 4.4 of this document).
2660 A.1.2 Section 4 of RFC 2251
2662 Portions of Section 4 of RFC 2251 detailing aspects of the information
2663 model used by LDAP were incorporated in this document, including:
2665 - Restriction of distinguished values to attributes whose descriptions
2666 have no options (from Section 4.1.3);
2668 - Data model aspects of Attribute Types (from Section 4.1.4),
2669 Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
2670 Matching Rule Identifier (from 4.1.9); and
2672 - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
2675 Clarifications to these portions include:
2677 - Subtyping and AttributeDescriptions with options.
2683 A.1.3 Section 6 of RFC 2251
2688 Zeilenga LDAP Models [Page 48]
2690 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2693 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
2694 where incorporated into this document.
2697 A.2 Changes to RFC 2252
2699 This document incorporates Sections 4, 5 and 7 from RFC 2252.
2702 A.2.1 Section 4 of RFC 2252
2704 The specification was updated to use Augmented BNF [RFC2234]. The
2705 string representation of an OBJECT IDENTIFIER was tighten to
2706 disallow leading zeros as described in RFC 2252 text.
2708 The <descr> syntax was changed to disallow semicolon (U+003B)
2709 characters to appear to be consistent its natural language
2710 specification "descr is the syntactic representation of an object
2711 descriptor, which consists of letters and digits, starting with a
2712 letter." In a related change, the statement "an
2713 AttributeDescription can be used as the value in a NAME part of an
2714 AttributeTypeDescription" was deleted. RFC 2252 provided no
2715 specification of the semantics of attribute options appearing in
2718 RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
2719 over the <numericoid> form. However, <descr> form can be ambiguous.
2720 To address this issue, the imperative was replaced with a statement
2721 (in Section 1.4) that while the <descr> form is generally preferred,
2722 <numericoid> should be used where an unambiguous <descr> is not
2723 available. Additionally, an expanded discussion of descriptor
2724 issues is discussed in Section 6.2 (Short Names).
2726 The ABNF for a quoted string (qdstring) was updated to reflect
2727 support for the escaping mechanism described in 4.3 of RFC 2252.
2730 A.2.2 Section 5 of RFC 2252
2732 Definitions of operational attributes provided in Section 5 of RFC
2733 2252 where incorporated into this document.
2735 The 'namingContexts' description was clarified. A first-level DSA
2736 should publish, in addition to other values, "" indicating the root
2739 The 'altServer' description was clarified. It may hold any URI.
2744 Zeilenga LDAP Models [Page 49]
2746 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2749 The 'supportedExtension' description was clarified. A server need
2750 only list the OBJECT IDENTIFIERs associated with the extended
2751 requests of the extended operations it recognizes.
2753 The 'supportedControl' description was clarified. A server need
2754 only list the OBJECT IDENTIFIERs associated with the request
2755 controls it recognizes.
2757 Descriptions for the 'structuralObjectClass' and
2758 'governingStructureRule' operational attribute types were added.
2761 A.2.3 Section 7 of RFC 2252
2763 Section 7 of RFC 2252 provides definitions of the 'subschema' and
2764 'extensibleObject' object classes. These definitions where
2765 integrated into Section 4.2 and Section 4.3 of this document,
2766 respectively. Section 7 of RFC 2252 also contained the object class
2767 implementation requirement. This was incorporated into Section 7 of
2770 The specification of 'extensibleObject' was clarified of how it
2771 interacts with precluded attributes.
2774 A.3 Changes to RFC 2256
2776 This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2779 Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
2780 attribute type. This was integrated into Section 2.4.1 of this
2781 document. The statement "One of the values is either 'top' or
2782 'alias'" was replaced with statement that one of the values is 'top'
2783 as entries belonging to 'alias' also belong to 'top'.
2785 Section 5.2 of RFC 2256 provided the definition of the
2786 'aliasedObjectName' attribute type. This was integrated into
2787 Section 2.6.2 of this document.
2789 Section 7.1 of RFC 2256 provided the definition of the 'top' object
2790 class. This was integrated into Section 2.4.1 of this document.
2792 Section 7.2 of RFC 2256 provided the definition of the 'alias'
2793 object class. This was integrated into Section 2.6.1 of this
2800 Zeilenga LDAP Models [Page 50]
2802 INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
2805 A.4 Changes to RFC 3674
2807 This document made no substantive change to the 'supportedFeatures'
2808 technical specification provided in RFC 3674.
2812 Intellectual Property Rights
2814 The IETF takes no position regarding the validity or scope of any
2815 Intellectual Property Rights or other rights that might be claimed to
2816 pertain to the implementation or use of the technology described in
2817 this document or the extent to which any license under such rights
2818 might or might not be available; nor does it represent that it has
2819 made any independent effort to identify any such rights. Information
2820 on the procedures with respect to rights in RFC documents can be found
2821 in BCP 78 and BCP 79.
2823 Copies of IPR disclosures made to the IETF Secretariat and any
2824 assurances of licenses to be made available, or the result of an
2825 attempt made to obtain a general license or permission for the use of
2826 such proprietary rights by implementers or users of this specification
2827 can be obtained from the IETF on-line IPR repository at
2828 http://www.ietf.org/ipr.
2830 The IETF invites any interested party to bring to its attention any
2831 copyrights, patents or patent applications, or other proprietary
2832 rights that may cover technology that may be required to implement
2833 this standard. Please address the information to the IETF at
2840 Copyright (C) The Internet Society (2005). This document is subject
2841 to the rights, licenses and restrictions contained in BCP 78, and
2842 except as set forth therein, the authors retain all their rights.
2844 This document and the information contained herein are provided on an
2845 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2846 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2847 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2848 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2849 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2850 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2856 Zeilenga LDAP Models [Page 51]