7 INTERNET-DRAFT Editor: Kurt D. Zeilenga
8 Intended Category: Standard Track OpenLDAP Foundation
9 Expires in six months 27 October 2003
10 Obsoletes: RFC 2251, RFC 2252, RFC 2256
14 LDAP: Directory Information Models
15 <draft-ietf-ldapbis-models-09.txt>
21 This document is an Internet-Draft and is in full conformance with all
22 provisions of Section 10 of RFC2026.
24 This document is intended to be published as a Standard Track RFC.
25 Distribution of this memo is unlimited. Technical discussion of this
26 document will take place on the IETF LDAP Revision Working Group
27 mailing list <ietf-ldapbis@openldap.org>. Please send editorial
28 comments directly to the author <Kurt@OpenLDAP.org>.
30 Internet-Drafts are working documents of the Internet Engineering Task
31 Force (IETF), its areas, and its working groups. Note that other
32 groups may also distribute working documents as Internet-Drafts.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as ``work in progress.''
38 The list of current Internet-Drafts can be accessed at
39 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
40 Internet-Draft Shadow Directories can be accessed at
41 <http://www.ietf.org/shadow.html>.
43 Copyright (C) The Internet Society (2003). All Rights Reserved.
45 Please see the Full Copyright section near the end of this document
51 The Lightweight Directory Access Protocol (LDAP) is an Internet
52 protocol for accessing distributed directory services which act in
53 accordance with X.500 data and service models. This document
54 describes the X.500 Directory Information Models, as used in LDAP.
58 Zeilenga LDAP Models [Page 1]
60 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
69 1.1. Relationship to Other LDAP Specifications
70 1.2. Relationship to X.501 4
72 1.4. Common ABNF Productions
73 2. Model of Directory User Information 6
74 2.1. The Directory Information Tree 7
75 2.2. Naming of Entries
76 2.3. Structure of an Entry 8
78 2.5. Attribute Descriptions 11
80 3. Directory Administrative and Operational Information 17
83 3.3. The 'objectClass' attribute 18
84 3.4. Operational attributes
85 4. Directory Schema 21
86 4.1. Schema Definitions 22
87 4.2. Subschema Subentries 31
88 4.3. 'extensibleObject' 34
89 4.4. Subschema Discovery 35
90 5. DSA (Server) Informational Model
91 5.1. Server-specific Data Requirements 36
92 6. Other Considerations 39
93 6.1. Preservation of User Information
95 6.3. Cache and Shadowing 40
96 7. Implementation Guidelines
97 7.1. Server Guidelines
98 7.2. Client Guidelines 41
99 8. Security Considerations
100 9. IANA Considerations
101 10. Acknowledgments 42
104 12.1. Normative References
105 12.2. Informative References 44
107 A.1 Changes to RFC 2251 44
108 A.2 Changes to RFC 2252 46
109 A.3 Changes to RFC 2256 48
110 Intellectual Property Rights
114 Zeilenga LDAP Models [Page 2]
116 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
124 This document discusses the X.500 Directory Information Models
125 [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
128 The Directory is "a collection of open systems cooperating to provide
129 directory services" [X.500]. The information held in the Directory is
130 collectively known as the Directory Information Base (DIB). A
131 Directory user, which may be a human or other entity, accesses the
132 Directory through a client (or Directory User Agent (DUA)). The
133 client, on behalf of the directory user, interacts with one or more
134 servers (or Directory System Agents (DSA)). A server holds a fragment
137 The DIB contains two classes of information:
139 1) user information (e.g., information provided and administrated
140 by users). Section 2 describes the Model of User Information.
142 2) administrative and operational information (e.g., information
143 used to administer and/or operate the directory). Section 3
144 describes the model of Directory Administrative and Operational
147 These two models, referred to as the generic Directory Information
148 Models, describe how information is represented in the Directory.
149 These generic models provide a framework for other information models.
150 Section 4 discusses the subschema information model and subschema
151 discovery. Section 5 discusses the DSA (Server) Informational Model.
153 Other X.500 information models, such as access control, collective
154 attribute, distribution knowledge, and replication knowledge
155 information models, may be adapted for use in LDAP. Specification of
156 how these models apply to LDAP is left to future documents.
159 1.1. Relationship to Other LDAP Specifications
161 This document is a integral part of the LDAP technical specification
162 [Roadmap] which obsoletes the previously defined LDAP technical
163 specification, RFC 3377, in its entirety.
165 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
166 portions of sections 4 and 6. Appendix A.1 summaries changes to these
170 Zeilenga LDAP Models [Page 3]
172 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
175 sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
176 [AuthMeth], and [Roadmap] documents.
178 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
179 summaries changes to these sections. The remainder of RFC 2252 is
180 obsoleted by [Syntaxes].
182 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
183 Appendix A.3 summarizes changes to these sections. The remainder of
184 RFC 2256 is obsoleted by [Schema] and [Syntaxes].
187 1.2. Relationship to X.501
189 This document includes material, with and without adaptation, from the
190 [X.501]. The material in this document takes precedence over that in
196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
198 document are to be interpreted as described in BCP 14 [RFC2119].
200 Schema definitions are provided using LDAP description formats (as
201 defined in Section 4.1). Definitions provided here are formatted
202 (line wrapped) for readability. Matching rules and LDAP syntaxes
203 referenced in these definitions are specified in [Syntaxes].
206 1.4. Common ABNF Productions
208 A number of syntaxes in this document are described using Augmented
209 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
210 number of syntaxes defined in other documents) rely on the following
213 keystring = leadkeychar *keychar
215 keychar = ALPHA / DIGIT / HYPHEN
217 number = DIGIT / ( LDIGIT 1*DIGIT )
219 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
220 DIGIT = %x30 / LDIGIT ; "0"-"9"
221 LDIGIT = %x31-39 ; "1"-"9"
226 Zeilenga LDAP Models [Page 4]
228 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
231 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
233 SP = 1*SPACE ; one or more " "
234 WSP = 0*SPACE ; zero or more " "
236 NULL = %x00 ; null (0)
237 SPACE = %x20 ; space (" ")
238 DQUOTE = %x22 ; quote (""")
239 SHARP = %x23 ; octothorpe (or sharp sign) ("#")
240 DOLLAR = %x24 ; dollar sign ("$")
241 SQUOTE = %x27 ; single quote ("'")
242 LPAREN = %x28 ; left paren ("(")
243 RPAREN = %x29 ; right paren (")")
244 PLUS = %x2B ; plus sign ("+")
245 COMMA = %x2C ; comma (",")
246 HYPHEN = %x2D ; hyphen ("-")
247 DOT = %x2E ; period (".")
248 SEMI = %x3B ; semicolon (";")
249 LANGLE = %x3C ; left angle bracket ("<")
250 EQUALS = %x3D ; equals sign ("=")
251 RANGLE = %x3E ; right angle bracket (">")
252 X = %x58 ; uppercase x ("X")
253 ESC = %x5C ; backslash ("\")
254 USCORE = %x5F ; underscore ("_")
255 LCURLY = %x7B ; left curly brace "{"
256 RCURLY = %x7D ; right curly brace "}"
258 ; Any UTF-8 character
260 UTFMB = UTF2 / UTF3 / UTF4
264 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
265 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
266 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
272 Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
273 decimal format conforming to the ABNF:
275 numericoid = number *( DOT number )
277 Short names, also known as descriptors, are used as more readable
278 aliases for object identifiers. Short names are case insensitive and
282 Zeilenga LDAP Models [Page 5]
284 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
291 Where either an object identifier or a short name may be specified,
292 the following production is used:
294 oid = descr / numericoid
296 While the <descr> form is generally preferred when the usage is
297 restricted to short names referring to object identifiers which
298 identify like kinds of objects (e.g., attribute type descriptions,
299 matching rule descriptions, object class descriptions), the
300 <numericoid> form should be used when the object identifiers may
301 identify multiple kinds of objects or when an unambiguous short name
302 (descriptor) is not available.
304 When the <descr> form is used, the representation SHALL be considered
305 invalid if the usage is not restricted as discussed above or the
306 implementation cannot determine unambiguously which object identifier
307 the <descr> refers to.
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
333 provides alternative naming. A subentry holds administrative and/or
334 operational information.
338 Zeilenga LDAP Models [Page 6]
340 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
343 The set of entries representing the DIB are organized hierarchically
344 in a tree structure known as the Directory Information Tree (DIT).
346 Section 2.1 describes the Directory Information Tree
347 Section 2.2 discusses naming of entries.
348 Section 2.3 discusses the structure of entries.
349 Section 2.4 discusses object classes.
350 Section 2.5 discusses attribute descriptions.
351 Section 2.6 discusses alias entries.
354 2.1. The Directory Information Tree
356 As noted above, the DIB is composed of a set of entries organized
357 hierarchically in a tree structure known as the Directory Information
358 Tree (DIT). Specifically, a tree where vertices are the entries.
360 The arcs between vertices define relations between entries. If an arc
361 exists from X to Y, then the entry at X is the immediate superior of Y
362 and Y is the immediate subordinate of X. An entry's superiors are the
363 entry's immediate superior and its superiors. An entry's subordinates
364 are all of its immediate subordinates and their subordinates.
366 Similarly, the superior/subordinate relationship between object
367 entries can be used to derive a relation between the objects they
368 represent. DIT structure rules can be used to govern relationships
371 Note: An entry's immediate superior is also known as the entry's
372 parent and an entry's immediate subordinate is also known as the
373 entry's child. Entries which have the same parent are known as
377 2.2. Naming of Entries
379 2.2.1. Relative Distinguished Names
381 Each entry is named relative to its immediate superior. This relative
382 name, known as its Relative Distinguished Name (RDN) [X.501], is
383 composed of an unordered set of one or more attribute value assertions
384 (AVA) consisting of an attribute description with zero options and an
385 attribute value. These AVAs are chosen from the attributes of the
388 An entry's relative distinguished name must be unique among all
389 immediate subordinates of the entry's immediate superior (i.e., all
394 Zeilenga LDAP Models [Page 7]
396 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
399 The following are example string representations of RDNs [LDAPDN]:
402 CN=Kurt Zeilenga+L=Redwood Shores
404 The last is an example of a multi-valued RDN. That is, an RDN
405 composed of multiple AVAs.
408 2.2.2. Distinguished Names
410 An entry's fully qualified name, known as its Distinguished Name (DN)
411 [X.501], is the concatenation of its RDN and its immediate superior's
412 DN. A Distinguished Name unambiguously refers to an entry in the
413 tree. The following are example string representations of DNs
416 UID=nobody@example.com,DC=example,DC=com
417 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
422 An alias, or alias name, is "an name for an object, provided by the
423 use of alias entries" [X.501]. Alias entries are described in Section
427 2.3. Structure of an Entry
429 An entry consists of a set of attributes which hold information about
430 the object which entry represents. Some attributes represent user
431 information and are called user attributes. Other attributes
432 represent operational and/or administrative information and are called
433 operational attributes.
435 An attribute is an attribute description (a type and zero or more
436 options) with one or more associated values. An attribute is often
437 referred to by its attribute description. For example, the
438 'givenName' attribute is the attribute which consists of the attribute
439 description 'givenName' (the 'givenName' attribute type [Schema] and
440 zero options) and one or more associated values.
442 The attribute type governs whether the attribute can have multiple
443 values, the syntax and matching rules used to construct and compare
444 values of that attribute, and other functions. Options indicate
445 subtypes and other functions. No two values of an attribute may be
450 Zeilenga LDAP Models [Page 8]
452 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
455 Two values are considered equivalent if they would match according to
456 the equality matching rule of the attribute type. If the attribute
457 type is defined with no equality matching rule, two values are
458 equivalent if and only if they are identical.
460 For example, the 'givenName' attribute can have can have more than one
461 value, they must be Directory Strings, and they are case insensitive.
462 The 'givenName' attribute cannot hold both "John" and "JOHN" as these
463 are equivalent values per the equality matching rule of the attribute
469 An object class is "an identified family of objects (or conceivable
470 objects) which share certain characteristics" [X.501].
472 As defined in [X.501]:
474 Object classes are used in the Directory for a number of purposes:
476 - describing and categorising objects and the entries that
477 correspond to these objects;
479 - where appropriate, controlling the operation of the Directory;
481 - regulating, in conjunction with DIT structure rule
482 specifications, the position of entries in the DIT;
484 - regulating, in conjunction with DIT content rule
485 specifications, the attributes that are contained in entries;
487 - identifying classes of entry that are to be associated with a
488 particular policy by the appropriate administrative authority.
490 An object class (a subclass) may be derived from an object class
491 (its direct superclass) which is itself derived from an even more
492 generic object class. For structural object classes, this process
493 stops at the most generic object class, 'top' (defined in Section
494 2.4.1). An ordered set of superclasses up to the most superior
495 object class of an object class is its superclass chain.
497 An object class may be derived from two or more direct
498 superclasses (superclasses not part of the same superclass chain).
499 This feature of subclassing is termed multiple inheritance.
501 Each object class identifies the set of attributes required to be
502 present in entries belonging to the class and the set of attributes
506 Zeilenga LDAP Models [Page 9]
508 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
511 allowed to be present in entries belonging to the class. As an entry
512 of a class must meet the requirements of each class it belongs to, it
513 can be said that an object class inherits the sets of allowed and
514 required attributes from its superclasses. A subclass can identify an
515 attribute allowed by its superclass as being required. If an
516 attribute is a member of both sets, it is required to be present.
518 Each object class is defined to be one of three kinds of object
519 classes: Abstract, Structural, or Auxiliary.
521 Each object class is identified by an object identifier (OID) and,
522 optionally, one or more short names (descriptors).
525 2.4.1. Abstract Object Classes
527 An abstract object class, as the name implies, provides a base of
528 characteristics from which other object classes can be defined to
529 inherit from. An entry cannot belong to an abstract object class
530 unless it belongs to a structural or auxiliary class which inherits
531 from that abstract class.
533 Abstract object classes can not derive from structural nor auxiliary
536 All structural object classes derive (directly or indirectly) from the
537 'top' abstract object class. Auxiliary object classes do not
538 necessarily derive from 'top'.
540 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
542 All entries belong to the 'top' abstract object class.
545 2.4.2. Structural Object Classes
547 As stated in [X.501]:
549 An object class defined for use in the structural specification of
550 the DIT is termed a structural object class. Structural object
551 classes are used in the definition of the structure of the names
552 of the objects for compliant entries.
554 An object or alias entry is characterised by precisely one
555 structural object class superclass chain which has a single
556 structural object class as the most subordinate object class.
557 This structural object class is referred to as the structural
558 object class of the entry.
562 Zeilenga LDAP Models [Page 10]
564 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
567 Structural object classes are related to associated entries:
569 - an entry conforming to a structural object class shall
570 represent the real-world object constrained by the object
573 - DIT structure rules only refer to structural object classes;
574 the structural object class of an entry is used to specify the
575 position of the entry in the DIT;
577 - the structural object class of an entry is used, along with an
578 associated DIT content rule, to control the content of an
581 The structural object class of an entry shall not be changed.
583 Each structural object class is a (direct or indirect) subclass of the
584 'top' abstract object class.
586 Structural object classes cannot subclass auxiliary object classes.
588 Each entry is said to belong to its structural object class as well as
589 all classes in its structural object class's superclass chain, which
590 always includes 'top'.
593 2.4.3. Auxiliary Object Classes
595 Auxiliary object classes are used augment the characteristics of
596 entries. They are commonly used to augment the sets of attributes
597 required and allowed attributes to be present in an entry. They can
598 be used to describe entries or classes of entries.
600 Auxiliary object classes cannot subclass structural object classes.
602 An entry can belong to any subset of the set of auxiliary object
603 classes allowed by the DIT content rule associated with structural
604 object class of the entry. If no DIT content rule is associated with
605 the structural object class of the entry, the entry cannot belong to
606 any auxiliary object class.
608 The set of auxiliary object classes which an entry belongs to can
612 2.5. Attribute Descriptions
614 An attribute description is composed of an attribute type (see Section
618 Zeilenga LDAP Models [Page 11]
620 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
623 2.5.1) and a set of zero or more attribute options (see Section
626 An attribute description is represented by the ABNF:
628 attributedescription = attributetype options
632 options = *( SEMI option )
636 where <attributetype> identifies the attribute type and each <option>
637 identifies an attribute option. Both <attributetype> and <option>
638 productions are case insensitive. The order in which <option>s appear
639 is irrelevant. That is, any two <attributedescription>s which consist
640 of the same <attributetype> and same set of <option>s are equivalent.
642 Examples of valid attribute descriptions:
648 An attribute description which consisting of an unrecognized attribute
649 type is to be treated as unrecognized. Servers SHALL treat an
650 attribute description with an unrecognized attribute option as
651 unrecognized. Clients MAY treat an unrecognized attribute option as a
652 tagging option (see Section 2.5.2.1).
654 All attributes of an entry must have distinct attribute descriptions.
657 2.5.1. Attribute Types
659 An attribute type governs whether the attribute can have multiple
660 values, the syntax and matching rules used to construct and compare
661 values of that attribute, and other functions.
663 The attribute type indicates whether the attribute is a user attribute
664 or an operational attribute. If operational, the attribute type
665 indicates the operational usage and whether the attribute can
666 modifiable by users or not. Operational attributes discussed in
669 An attribute type (a subtype) may derive from another attribute type
670 (a direct supertype). The subtype inherits the matching rules and
674 Zeilenga LDAP Models [Page 12]
676 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
679 syntax of its supertype. An attribute type cannot be a subtype of an
680 attribute of different usage.
682 An attribute description consisting of a subtype and no options is
683 said to the direct description subtype of the attribute description
684 consisting of the subtype's direct supertype and no options.
686 Each attribute type is identified by an object identifier (OID) and,
687 optionally, one or more short names (descriptors).
690 2.5.2. Attribute Options
692 There are multiple kinds of attribute description options. The LDAP
693 technical specification details one kind: tagging options.
695 Not all options can be associated with attributes held in the
696 directory. Tagging options can be.
698 Not all options can be used in conjunction with all attribute types.
699 In such cases, the attribute description is to be treated as
702 An attribute description that contains mutually exclusive options
703 shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
704 "x-foo" and "x-bar" are mutually exclusive, is to be treated as
707 Other kinds of options may be specified in future documents. These
708 documents must detail how new kinds of options they define relate to
709 tagging options. In particular, these documents must detail whether
710 or not new kinds of options can be associated with attributes held in
711 the directory, how new kinds of options affect transfer of attribute
712 values, and how new kinds of options are treated in attribute
713 description hierarchies.
715 Options are represented as short case insensitive textual strings
716 conforming to the <option> production defined in Section 2.5 of this
719 Procedures for registering options are detailed in BCP 64 [BCP64bis].
722 2.5.2.1. Tagging Options
724 Attributes held in the directory can have attribute descriptions with
725 any number of tagging options. Tagging options are never mutually
730 Zeilenga LDAP Models [Page 13]
732 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
735 An attribute description with N tagging options is considered a direct
736 (description) subtype of all attribute descriptions of the same
737 attribute type and all but one of the N options. If the attribute
738 type has a supertype, then the attribute description is also
739 considered a direct (description) subtype of the attribute description
740 of the supertype and the N tagging options. That is,
741 'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de',
742 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name',
743 both are defined in [Schema]).
746 2.5.3. Attribute Description Hierarchies
748 An attribute description can be the direct subtype of zero or more
749 other attribute descriptions as indicated by attribute type subtyping
750 (as described in Section 2.5.1) or attribute tagging option subtyping
751 (as described in Section 2.5.2.1). These subtyping relationships are
752 used to form hierarchies of attribute descriptions and attributes.
754 As adapted from [X.501]:
756 Attribute hierarchies allow access to the DIB with varying degrees
757 of granularity. This is achieved by allowing the value components
758 of attributes to be accessed by using either their specific
759 attribute description (a direct reference to the attribute) or by
760 a more generic attribute description (an indirect reference).
762 Semantically related attributes may be placed in a hierarchical
763 relationship, the more specialized being placed subordinate to the
764 more generalized. Searching for, or retrieving attributes and
765 their values is made easier by quoting the more generalized
766 attribute description; a filter item so specified is evaluated for
767 the more specialized descriptions as well as for the quoted
770 Where subordinate specialized descriptions are selected to be
771 returned as part of a search result these descriptions shall be
772 returned if available. Where the more general descriptions are
773 selected to be returned as part of a search result both the
774 general and the specialized descriptions shall be returned, if
775 available. An attribute value shall always be returned as a value
776 of its own attribute description.
778 All of the attribute descriptions in an attribute hierarchy are
779 treated as distinct and unrelated descriptions for user
780 modification of entry content.
782 An attribute value stored in a object or alias entry is of
786 Zeilenga LDAP Models [Page 14]
788 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
791 precisely one attribute description. The description is indicated
792 when the value is originally added to the entry.
794 For the purpose of subschema administration of the entry, a required
795 attribute specification is fulfilled if the entry contains a value of
796 an attribute description belonging to an attribute hierarchy if the
797 attribute type of that description is the same as the required
798 attribute's type. That is, a "MUST name" specification is fulfilled
799 by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor by
800 'CN;x-tag-option'. Likewise, an entry may contain a value of an
801 attribute description belonging to an attribute hierarchy if the
802 attribute type of that description is either explicitly included in
803 the definition of an object class to which the entry belongs or
804 allowed by the DIT content rule applicable to that entry. That is,
805 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
806 name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
807 (nor by "MUST name").
809 For the purposes of other policy administration, unless stated
810 otherwise in the specification of the particular administrative model,
811 all of the attribute descriptions in an attribute hierarchy are
812 treated as distinct and unrelated descriptions.
815 2.5.4. Attribute Values
817 Attribute values conform to the defined syntax of the attribute.
819 When an attribute is used for naming of the entry, one and only one
820 value of the attribute is selected to appear in the Relative
821 Distinguished Name. This value is known as a distinguished value.
823 Only attributes whose descriptions have no options can be used for
829 As adapted from [X.501]:
831 An alias, or an alias name, for an object is a an alternative name
832 for an object or object entry which is provided by the use of
835 Each alias entry contains, within the 'aliasedObjectName'
836 attribute (known as the 'aliasedEntryName' attribute in X.500]), a
837 name of some object. The distinguished name of the alias entry is
838 thus also a name for this object.
842 Zeilenga LDAP Models [Page 15]
844 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
847 NOTE - The name within the 'aliasedObjectName' is said to be
848 pointed to by the alias. It does not have to be the
849 distinguished name of any entry.
851 The conversion of an alias name to an object name is termed
852 (alias) dereferencing and comprises the systematic replacement of
853 alias names, where found within a purported name, by the value of
854 the corresponding 'aliasedObjectName' attribute. The process may
855 require the examination of more than one alias entry.
857 Any particular entry in the DIT may have zero or more alias names.
858 It therefore follows that several alias entries may point to the
859 same entry. An alias entry may point to an entry that is not a
860 leaf entry and may point to another alias entry.
862 An alias entry shall have no subordinates, so that an alias entry
863 is always a leaf entry.
865 Every alias entry shall belong to the 'alias' object class.
867 An entry with the 'alias' object class must also belong to an object
868 class (or classes), or be governed by a DIT content rule, which allows
869 suitable naming attributes to be present.
872 dn: cn=bar,dc=example,dc=com
875 objectClass: extensibleObject
877 aliasedObjectName: cn=foo,dc=example,dc=com
880 2.6.1. 'alias' object class
882 Alias entries belong to the 'alias' object class.
884 ( 2.5.6.1 NAME 'alias'
886 MUST aliasedObjectName )
889 2.6.2. 'aliasedObjectName' attribute type
891 The 'aliasedObjectName' attribute holds the name of the entry an alias
892 points to. The 'aliasedObjectName' attribute is known as the
893 'aliasedEntryName' attribute in X.500.
898 Zeilenga LDAP Models [Page 16]
900 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
903 ( 2.5.4.1 NAME 'aliasedObjectName'
904 EQUALITY distinguishedNameMatch
905 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
908 The 'distinguishedNameMatch' matching rule and the DistinguishedName
909 (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [Syntaxes].
912 3. Directory Administrative and Operational Information
914 This section discusses select aspects of the X.500 Directory
915 Administrative and Operational Information model [X.501]. LDAP
916 implementations MAY support other aspects of this model.
921 As defined in [X.501]:
923 A subtree is a collection of object and alias entries situated at
924 the vertices of a tree. Subtrees do not contain subentries. The
925 prefix sub, in subtree, emphasizes that the base (or root) vertex
926 of this tree is usually subordinate to the root of the DIT.
928 A subtree begins at some vertex and extends to some identifiable
929 lower boundary, possibly extending to leaves. A subtree is always
930 defined within a context which implicitly bounds the subtree. For
931 example, the vertex and lower boundaries of a subtree defining a
932 replicated area are bounded by a naming context. Similarly, the
933 scope of a subtree defining a specific administrative area is
934 limited to the context of an enclosing autonomous administrative
940 A subentry is a "special sort of entry, known by the Directory, used
941 to hold information associated with a subtree or subtree refinement"
942 [X.501]. Subentries are used in Directory to hold for administrative
943 and operational purposes as defined in [X.501]. Their use in LDAP is
944 not detailed in this technical specification, but may be detailed in
947 The term "(sub)entry" in this specification indicates that servers
948 implementing X.500(93) models are, in accordance with X.500(93), to
949 use a subentry and that other servers are to use an object entry
950 belonging to the appropriate auxiliary class normally used with the
954 Zeilenga LDAP Models [Page 17]
956 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
959 subentry (e.g., 'subschema' for subschema subentries) to mimic the
960 subentry. This object entry's RDN SHALL be formed from a value of the
961 'cn' (commonName) attribute [Schema].
964 3.3. The 'objectClass' attribute
966 Each entry in the DIT has an 'objectClass' attribute.
968 ( 2.5.4.0 NAME 'objectClass'
969 EQUALITY objectIdentifierMatch
970 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
972 The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
973 (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
975 The 'objectClass' attribute specifies the object classes of an entry,
976 which (among other things) is used in conjunction with user and system
977 schema to determine the permitted attributes of an entry. Values of
978 this attribute can be modified by clients, but the 'objectClass'
979 attribute cannot be removed.
981 Servers which follow X.500(93) models SHALL restrict modifications of
982 this attribute to prevent the basic structural class of the entry from
983 being changed. That is, one cannot change a 'person' into a
986 When creating an entry or adding an 'objectClass' value to an entry,
987 all superclasses of the named classes SHALL be implicitly added as
988 well if not already present. That is, if the auxiliary class 'x-a' is
989 a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
990 'x-b' to be implicitly added (if is not already present).
992 Servers SHALL restrict modifications of this attribute to prevent a
993 superclasses of remaining 'objectClass' values from being deleted.
994 That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
995 class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
996 an attempt to delete only 'x-b' from the 'objectClass' attribute is an
1000 3.4. Operational attributes
1002 Some attributes, termed operational attributes, are used or maintained
1003 by servers for administrative and operational purposes. As stated in
1004 [X.501]: "There are three varieties of operational attributes:
1005 Directory operational attributes, DSA-shared operational attributes,
1006 and DSA-specific operational attributes."
1010 Zeilenga LDAP Models [Page 18]
1012 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1015 A directory operational attribute is used to represent operational
1016 and/or administrative information in the Directory Information Model.
1017 This includes operational attributes maintained by the server (e.g.
1018 'createTimestamp') as well as operational attributes which hold values
1019 administrated by the user (e.g. 'ditContentRules').
1021 A DSA-shared operational attribute is used to represent information of
1022 the DSA Information Model. Its values, if shared between DSAs
1023 (servers) are identical (except during periods of transient
1026 A DSA-specific operational attribute is used to represent information
1027 of the DSA Information Model. Its values, if shared between DSAs
1028 (servers), need not be identical.
1030 The DSA Information Model operational attributes are detailed in
1033 Operational attributes are not normally visible. They are not
1034 returned in search results unless explicitly requested by name.
1036 Not all operational attributes are user modifiable.
1038 Entries may contain, among others, the following operational
1041 - creatorsName: the Distinguished Name of the user who added this
1042 entry to the directory.
1044 - createTimestamp: the time this entry was added to the directory.
1046 - modifiersName: the Distinguished Name of the user who last
1047 modified this entry.
1049 - modifyTimestamp: the time this entry was last modified.
1051 Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
1052 'modifiersName', and 'modifyTimestamp' for all entries of the DIT.
1055 3.4.1. 'creatorsName'
1057 This attribute appears in entries which were added using the protocol
1058 (e.g., using the Add operation). The value is the distinguished name
1061 ( 2.5.18.3 NAME 'creatorsName'
1062 EQUALITY distinguishedNameMatch
1066 Zeilenga LDAP Models [Page 19]
1068 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1071 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1072 SINGLE-VALUE NO-USER-MODIFICATION
1073 USAGE directoryOperation )
1075 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1076 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1079 3.4.2. 'createTimestamp'
1081 This attribute appears in entries which were added using the protocol
1082 (e.g., using the Add operation). The value is the time the entry was
1085 ( 2.5.18.1 NAME 'createTimestamp'
1086 EQUALITY generalizedTimeMatch
1087 ORDERING generalizedTimeOrderingMatch
1088 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1089 SINGLE-VALUE NO-USER-MODIFICATION
1090 USAGE directoryOperation )
1092 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1093 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1094 are defined in [Syntaxes].
1097 3.4.3. 'modifiersName'
1099 This attribute appears in entries which have been modified using the
1100 protocol (e.g., using Modify operation). The value is the
1101 distinguished name of the last modifier.
1103 ( 2.5.18.4 NAME 'modifiersName'
1104 EQUALITY distinguishedNameMatch
1105 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1106 SINGLE-VALUE NO-USER-MODIFICATION
1107 USAGE directoryOperation )
1109 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1110 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1113 3.4.4. 'modifyTimestamp'
1115 This attribute appears in entries which have been modified using the
1116 protocol (e.g., using the Modify operation). The value is the time
1117 the entry was last modified.
1122 Zeilenga LDAP Models [Page 20]
1124 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1127 ( 2.5.18.2 NAME 'modifyTimestamp'
1128 EQUALITY generalizedTimeMatch
1129 ORDERING generalizedTimeOrderingMatch
1130 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1131 SINGLE-VALUE NO-USER-MODIFICATION
1132 USAGE directoryOperation )
1134 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1135 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1136 are defined in [Syntaxes].
1141 As defined in [X.501]:
1143 The Directory Schema is a set of definitions and constraints
1144 concerning the structure of the DIT, the possible ways entries are
1145 named, the information that can be held in an entry, the
1146 attributes used to represent that information and their
1147 organization into hierarchies to facilitate search and retrieval
1148 of the information and the ways in which values of attributes may
1149 be matched in attribute value and matching rule assertions.
1151 NOTE 1 - The schema enables the Directory system to, for example:
1153 - prevent the creation of subordinate entries of the wrong
1154 object-class (e.g. a country as a subordinate of a person);
1156 - prevent the addition of attribute-types to an entry
1157 inappropriate to the object-class (e.g. a serial number to a
1160 - prevent the addition of an attribute value of a syntax not
1161 matching that defined for the attribute-type (e.g. a printable
1162 string to a bit string).
1164 Formally, the Directory Schema comprises a set of:
1166 a) Name Form definitions that define primitive naming relations
1167 for structural object classes;
1169 b) DIT Structure Rule definitions that define the names that
1170 entries may have and the ways in which the entries may be
1171 related to one another in the DIT;
1173 c) DIT Content Rule definitions that extend the specification of
1174 allowable attributes for entries beyond those indicated by the
1178 Zeilenga LDAP Models [Page 21]
1180 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1183 structural object classes of the entries;
1185 d) Object Class definitions that define the basic set of mandatory
1186 and optional attributes that shall be present, and may be
1187 present, respectively, in an entry of a given class, and which
1188 indicate the kind of object class that is being defined;
1190 e) Attribute Type definitions that identify the object identifier
1191 by which an attribute is known, its syntax, associated matching
1192 rules, whether it is an operational attribute and if so its
1193 type, whether it is a collective attribute, whether it is
1194 permitted to have multiple values and whether or not it is
1195 derived from another attribute type;
1197 f) Matching Rule definitions that define matching rules.
1201 g) LDAP Syntaxes definitions that define encodings used in LDAP.
1204 4.1. Schema Definitions
1206 Schema definitions in this section are described using ABNF and rely
1207 on the common productions specified in Section 1.2 as well as these:
1209 noidlen = numericoid [ LCURLY len RCURLY ]
1213 oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
1215 oidlist = oid *( WSP DOLLAR WSP oid )
1217 extensions = *( SP xstring SP qdstrings )
1219 xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE )
1221 qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
1223 qdescrlist = [ qdescr *( SP qdescr ) ]
1225 qdescr = SQUOTE descr SQUOTE
1227 qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
1229 qdstringlist = [ qdstring *( SP qdstring ) ]
1234 Zeilenga LDAP Models [Page 22]
1236 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1239 qdstring = SQUOTE dstring SQUOTE
1241 dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string
1243 QQ = ESC %x32 %x37 ; "\27"
1245 QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
1247 ; Any UTF-8 encoded UCS character
1248 ; except %x27 ("'") and %x5C ("\")
1249 QUTF8 = QUTF1 / UTFMB
1251 ; Any ASCII character except %x27 ("'") and %x5C ("\")
1252 QUTF1 = %x00-26 / %x28-5B / %x5D-7F
1254 Schema definitions in this section also share a number of common
1257 The NAME field provides a set of short names (descriptors) which are
1258 be used as aliases for the OID.
1260 The DESC field optionally allows a descriptive string to be provided
1261 by the directory administrator and/or implementor. While
1262 specifications may suggest a descriptive string, there is no
1263 requirement that the suggested (or any) descriptive string be used.
1265 The OBSOLETE field, if present, indicates the element is not active.
1267 Implementors should note that future versions of this document may
1268 expand these definitions to include additional terms. Terms whose
1269 identifier begins with "X-" are reserved for private experiments, and
1270 are followed by <SP> and <qdstrings> tokens.
1273 4.1.1. Object Class Definitions
1275 Object Class definitions are written according to the ABNF:
1277 ObjectClassDescription = LPAREN WSP
1278 numericoid ; object identifier
1279 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1280 [ SP "DESC" SP qdstring ] ; description
1281 [ SP "OBSOLETE" ] ; not active
1282 [ SP "SUP" SP oids ] ; superior object classes
1283 [ SP kind ] ; kind of class
1284 [ SP "MUST" SP oids ] ; attribute types
1285 [ SP "MAY" SP oids ] ; attribute types
1286 extensions WSP RPAREN
1290 Zeilenga LDAP Models [Page 23]
1292 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1295 kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
1298 <numericoid> is object identifier assigned to this object class;
1299 NAME <qdescrs> are short names (descriptors) identifying this object
1301 DESC <qdstring> is a short descriptive string;
1302 OBSOLETE indicates this object class is not active;
1303 SUP <oids> specifies the direct superclasses of this object class;
1304 the kind of object class is indicated by one of ABSTRACT,
1305 STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
1306 MUST and MAY specify the sets of required and allowed attribute
1307 types, respectively; and
1308 <extensions> describe extensions.
1311 4.1.2. Attribute Types
1313 Attribute Type definitions are written according to the ABNF:
1315 AttributeTypeDescription = LPAREN WSP
1316 numericoid ; object identifier
1317 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1318 [ SP "DESC" SP qdstring ] ; description
1319 [ SP "OBSOLETE" ] ; not active
1320 [ SP "SUP" SP oid ] ; supertype
1321 [ SP "EQUALITY" SP oid ] ; equality matching rule
1322 [ SP "ORDERING" SP oid ] ; ordering matching rule
1323 [ SP "SUBSTR" SP oid ] ; substrings matching rule
1324 [ SP "SYNTAX" SP noidlen ] ; value syntax
1325 [ SP "SINGLE-VALUE" ] ; single-value
1326 [ SP "COLLECTIVE" ] ; collective
1327 [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
1328 [ SP "USAGE" SP usage ] ; usage
1329 extensions WSP RPAREN ; extensions
1331 usage = "userApplications" / ; user
1332 "directoryOperation" / ; directory operational
1333 "distributedOperation" / ; DSA-shared operational
1334 "dSAOperation" ; DSA-specific operational
1337 <numericoid> is object identifier assigned to this attribute type;
1338 NAME <qdescrs> are short names (descriptors) identifying this
1340 DESC <qdstring> is a short descriptive string;
1341 OBSOLETE indicates this attribute type is not active;
1342 SUP oid specifies the direct supertype of this type;
1346 Zeilenga LDAP Models [Page 24]
1348 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1351 EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
1352 ordering, and substrings matching rules, respectively;
1353 SYNTAX identifies value syntax by object identifier and may suggest
1354 a minimum upper bound;
1355 COLLECTIVE indicates this attribute type is collective [X.501];
1356 NO-USER-MODIFICATION indicates this attribute type is not user
1358 USAGE indicates the application of this attribute type; and
1359 <extensions> describe extensions.
1361 Each attribute type description must contain at least one of the SUP
1364 Usage of userApplications, the default, indicates that attributes of
1365 this type represent user information. That is, they are user
1368 COLLECTIVE requires usage userApplications. Use of collective
1369 attribute types in LDAP is not discussed in this technical
1372 A usage of directoryOperation, distributedOperation, or dSAOperation
1373 indicates that attributes of this type represent operational and/or
1374 administrative information. That is, they are operational attributes.
1376 directoryOperation usage indicates that the attribute of this type is
1377 a directory operational attribute. distributedOperation usage
1378 indicates that the attribute of this DSA-shared usage operational
1379 attribute. dSAOperation usage indicates that the attribute of this
1380 type is a DSA-specific operational attribute.
1382 NO-USER-MODIFICATION requires an operational usage.
1384 Note that the <AttributeTypeDescription> does not list the matching
1385 rules which can be used with that attribute type in an extensibleMatch
1386 search filter. This is done using the 'matchingRuleUse' attribute
1387 described in Section 4.1.4.
1389 This document refines the schema description of X.501 by requiring
1390 that the SYNTAX field in an <AttributeTypeDescription> be a string
1391 representation of an object identifier for the LDAP string syntax
1392 definition with an optional indication of the suggested minimum bound
1393 of a value of this attribute.
1395 A suggested minimum upper bound on the number of characters in a value
1396 with a string-based syntax, or the number of bytes in a value for all
1397 other syntaxes, may be indicated by appending this bound count inside
1398 of curly braces following the syntax's OBJECT IDENTIFIER in an
1402 Zeilenga LDAP Models [Page 25]
1404 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1407 Attribute Type Description. This bound is not part of the syntax name
1408 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
1409 implementations should allow a string to be 64 characters long,
1410 although they may allow longer strings. Note that a single character
1411 of the Directory String syntax may be encoded in more than one octet
1412 since UTF-8 is a variable-length encoding.
1415 4.1.3. Matching Rules
1417 Matching rules are used by servers to compare attribute values against
1418 assertion values when performing Search and Compare operations. They
1419 are also used to identify the value to be added or deleted when
1420 modifying entries, and are used when comparing a purported
1421 distinguished name with the name of an entry.
1423 A matching rule specifies the syntax of the assertion value.
1425 Each matching rule is identified by an object identifier (OID) and,
1426 optionally, one or more short names (descriptors).
1428 Matching rule definitions are written according to the ABNF:
1430 MatchingRuleDescription = LPAREN WSP
1431 numericoid ; object identifier
1432 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1433 [ SP "DESC" SP qdstring ] ; description
1434 [ SP "OBSOLETE" ] ; not active
1435 SP "SYNTAX" SP numericoid ; assertion syntax
1436 extensions WSP RPAREN ; extensions
1439 <numericoid> is object identifier assigned to this matching rule;
1440 NAME <qdescrs> are short names (descriptors) identifying this
1442 DESC <qdstring> is a short descriptive string;
1443 OBSOLETE indicates this matching rule is not active;
1444 SYNTAX identifies the assertion syntax by object identifier; and
1445 <extensions> describe extensions.
1448 4.1.4. Matching Rule Uses
1450 A matching rule use lists the attributes which are suitable for use
1451 with an extensibleMatch search filter.
1453 Matching rule use descriptions are written according to the following
1458 Zeilenga LDAP Models [Page 26]
1460 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1463 MatchingRuleUseDescription = LPAREN WSP
1464 numericoid ; object identifier
1465 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1466 [ SP "DESC" SP qdstring ] ; description
1467 [ SP "OBSOLETE" ] ; not active
1468 SP "APPLIES" SP oids ; attribute types
1469 extensions WSP RPAREN ; extensions
1472 <numericoid> is the object identifier of the matching rule
1473 associated with this matching rule use description;
1474 NAME <qdescrs> are short names (descriptors) identifying this
1476 DESC <qdstring> is a short descriptive string;
1477 OBSOLETE indicates this matching rule use is not active;
1478 APPLIES provides a list of attribute types the matching rule applies
1480 <extensions> describe extensions.
1483 4.1.5. LDAP Syntaxes
1485 LDAP Syntaxes of (attribute and assertion) values are described in
1486 terms of ASN.1 [X.680] and, optionally, have an octet string encoding
1487 known as the LDAP-specific encoding. Commonly, the LDAP-specific
1488 encoding is constrained to string of Universal Character Set (UCS)
1489 [ISO10646] characters in UTF-8 [UTF-8] form.
1491 Each LDAP syntax is identified by an object identifier (OID).
1493 LDAP syntax definitions are written according to the ABNF:
1495 SyntaxDescription = LPAREN WSP
1496 numericoid ; object identifier
1497 [ SP "DESC" SP qdstring ] ; description
1498 extensions WSP RPAREN ; extensions
1501 <numericoid> is object identifier assigned to this LDAP syntax;
1502 DESC <qdstring> is a short descriptive string; and
1503 <extensions> describe extensions.
1506 4.1.6. DIT Content Rules
1508 A DIT content rule is a "rule governing the content of entries of a
1509 particular structural object class" [X.501].
1514 Zeilenga LDAP Models [Page 27]
1516 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1519 For DIT entries of a particular structural object class, a DIT content
1520 rule specifies which auxiliary object classes the entries are allowed
1521 to belong to and which additional attributes (by type) are required,
1522 allowed or not allowed to appear in the entries.
1524 The list of precluded attributes cannot include any attribute listed
1525 as mandatory in rule, the structural object class, or any of the
1526 allowed auxiliary object classes.
1528 Each content rule is identified by the object identifier, as well as
1529 any short names (descriptors), of the structural object class it
1532 An entry may only belong to auxiliary object classes listed in the
1533 governing content rule.
1535 An entry must contain all attributes required by the object classes
1536 the entry belongs to as well as all attributed required by the
1537 governing content rule.
1539 An entry may contain any non-precluded attributes allowed by the
1540 object classes the entry belongs to as well as all attributes allowed
1541 by the governing content rule.
1543 An entry cannot include any attribute precluded by the governing
1546 An entry is governed by (if present and active in the subschema) the
1547 DIT content rule which applies to the structural object class of the
1548 entry (see Section 2.4.2). If no active rule is present for the
1549 entry's structural object class, the entry's content is governed by
1550 the structural object class (and possibly other aspects of user and
1553 DIT content rule descriptions are written according to the ABNF:
1555 DITContentRuleDescription = LPAREN WSP
1556 numericoid ; object identifier
1557 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1558 [ SP "DESC" SP qdstring ] ; description
1559 [ SP "OBSOLETE" ] ; not active
1560 [ SP "AUX" SP oids ] ; auxiliary object classes
1561 [ SP "MUST" SP oids ] ; attribute types
1562 [ SP "MAY" SP oids ] ; attribute types
1563 [ SP "NOT" SP oids ] ; attribute types
1564 extensions WSP RPAREN ; extensions
1570 Zeilenga LDAP Models [Page 28]
1572 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1575 <numericoid> is the object identifier of the structural object class
1576 associated with this DIT content rule;
1577 NAME <qdescrs> are short names (descriptors) identifying this DIT
1579 DESC <qdstring> is a short descriptive string;
1580 OBSOLETE indicates this DIT content rule use is not active;
1581 AUX specifies a list of auxiliary object classes which entries
1582 subject to this DIT content rule may belong to;
1583 MUST, MAY, and NOT specify lists of attribute types which are
1584 required, allowed, or precluded, respectively, from appearing in
1585 entries subject to this DIT content rule; and
1586 <extensions> describe extensions.
1589 4.1.7. DIT Structure Rules and Name Forms
1591 It is sometimes desirable to regulate where object entries can be
1592 placed in the DIT and how they can be named based upon their
1593 structural object class.
1596 4.1.7.1. DIT Structure Rules
1598 A DIT structure rule is a "rule governing the structure of the DIT by
1599 specifying a permitted superior to subordinate entry relationship. A
1600 structure rule relates a name form, and therefore a structural object
1601 class, to superior structure rules. This permits entries of the
1602 structural object class identified by the name form to exist in the
1603 DIT as subordinates to entries governed by the indicated superior
1604 structure rules" [X.501].
1606 DIT structure rule descriptions are written according to the ABNF:
1608 DITStructureRuleDescription = LPAREN WSP
1609 ruleid ; rule identifier
1610 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1611 [ SP "DESC" SP qdstring ] ; description
1612 [ SP "OBSOLETE" ] ; not active
1613 SP "FORM" SP oid ; NameForm
1614 [ SP "SUP" ruleids ] ; superior rules
1615 extensions WSP RPAREN ; extensions
1617 ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
1619 ruleidlist = ruleid *( SP ruleid )
1626 Zeilenga LDAP Models [Page 29]
1628 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1632 <ruleid> is the rule identifier of this DIT structure rule;
1633 NAME <qdescrs> are short names (descriptors) identifying this DIT
1635 DESC <qdstring> is a short descriptive string;
1636 OBSOLETE indicates this DIT structure rule use is not active;
1637 FORM is specifies the name form associated with this DIT structure
1639 SUP identifies superior rules (by rule id); and
1640 <extensions> describe extensions.
1642 If no superior rules are identified, the DIT structure rule applies
1643 to an autonomous administrative point (e.g. the root vertex of the
1644 subtree controlled by the subschema) [X.501].
1649 A name form "specifies a permissible RDN for entries of a particular
1650 structural object class. A name form identifies a named object
1651 class and one or more attribute types to be used for naming (i.e.
1652 for the RDN). Name forms are primitive pieces of specification
1653 used in the definition of DIT structure rules" [X.501].
1655 Each name form indicates the structural object class to be named,
1656 a set of required attribute types, and a set of allowed attributes
1657 types. A particular attribute type cannot be listed in both sets.
1659 Entries governed by the form must be named using a value from each
1660 required attribute type and zero or more values from the allowed
1663 Each name form is identified by an object identifier (OID) and,
1664 optionally, one or more short names (descriptors).
1666 Name form descriptions are written according to the ABNF:
1668 NameFormDescription = LPAREN WSP
1669 numericoid ; object identifier
1670 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1671 [ SP "DESC" SP qdstring ] ; description
1672 [ SP "OBSOLETE" ] ; not active
1673 SP "OC" SP oid ; structural object class
1674 SP "MUST" SP oids ; attribute types
1675 [ SP "MAY" SP oids ] ; attribute types
1676 extensions WSP RPAREN ; extensions
1682 Zeilenga LDAP Models [Page 30]
1684 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1687 <numericoid> is object identifier which identifies this name form;
1688 NAME <qdescrs> are short names (descriptors) identifying this name
1690 DESC <qdstring> is a short descriptive string;
1691 OBSOLETE indicates this name form is not active;
1692 OC identifies the structural object class this rule applies to,
1693 MUST and MAY specify the sets of required and allowed, respectively,
1694 naming attributes for this name form; and
1695 <extensions> describe extensions.
1697 All attribute types in the required ("MUST") and allowed ("MAY") lists
1701 4.2. Subschema Subentries
1703 Subschema (sub)entries are used for administering information about
1704 the directory schema. A single subschema (sub)entry contains all
1705 schema definitions (see Section 4.1) used by entries in a particular
1706 part of the directory tree.
1708 Servers which follow X.500(93) models SHOULD implement subschema using
1709 the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
1710 and so these are not ordinary object entries but subentries (see
1711 Section 3.2). LDAP clients SHOULD NOT assume that servers implement
1712 any of the other aspects of X.500 subschema.
1714 Servers MAY allow subschema modification. Procedures for subschema
1715 modification are discussed in Section 14.5 of [X.501].
1717 A server which masters entries and permits clients to modify these
1718 entries SHALL implement and provide access to these subschema
1719 (sub)entries including providing a 'subschemaSubentry' attribute in
1720 each modifiable entry. This so clients may discover the attributes
1721 and object classes which are permitted to be present. It is strongly
1722 RECOMMENDED that all other servers implement this as well.
1724 The value of the 'subschemaSubentry' attribute is the name of the
1725 subschema (sub)entry holding the subschema controlling the entry.
1727 ( 2.5.18.10 NAME 'subschemaSubentry'
1728 EQUALITY distinguishedNameMatch
1729 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1730 NO-USER-MODIFICATION SINGLE-VALUE
1731 USAGE directoryOperation )
1733 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1734 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1738 Zeilenga LDAP Models [Page 31]
1740 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1743 Subschema is held in (sub)entries belonging to the subschema auxiliary
1746 ( 2.5.20.1 NAME 'subschema' AUXILIARY
1747 MAY ( dITStructureRules $ nameForms $ ditContentRules $
1748 objectClasses $ attributeTypes $ matchingRules $
1751 The 'ldapSyntaxes' operational attribute may also be present in
1754 Servers MAY provide additional attributes (described in other
1755 documents) in subschema (sub)entries.
1757 Servers SHOULD provide the attributes 'createTimestamp' and
1758 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
1759 to maintain their caches of schema information.
1761 The following subsections provide attribute type definitions for each
1762 of schema definition attribute types.
1765 4.2.1. 'objectClasses'
1767 This attribute holds definitions of object classes.
1769 ( 2.5.21.6 NAME 'objectClasses'
1770 EQUALITY objectIdentifierFirstComponentMatch
1771 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
1772 USAGE directoryOperation )
1774 The 'objectIdentifierFirstComponentMatch' matching rule and the
1775 ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
1776 defined in [Syntaxes].
1779 4.2.2. 'attributeTypes'
1781 This attribute holds definitions of attribute types.
1783 ( 2.5.21.5 NAME 'attributeTypes'
1784 EQUALITY objectIdentifierFirstComponentMatch
1785 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
1786 USAGE directoryOperation )
1788 The 'objectIdentifierFirstComponentMatch' matching rule and the
1789 AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
1790 defined in [Syntaxes].
1794 Zeilenga LDAP Models [Page 32]
1796 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1799 4.2.3. 'matchingRules'
1801 This attribute holds definitions of matching rules.
1803 ( 2.5.21.4 NAME 'matchingRules'
1804 EQUALITY objectIdentifierFirstComponentMatch
1805 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
1806 USAGE directoryOperation )
1808 The 'objectIdentifierFirstComponentMatch' matching rule and the
1809 MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
1810 defined in [Syntaxes].
1813 4.2.4 'matchingRuleUse'
1815 This attribute holds definitions of matching rule uses.
1817 ( 2.5.21.8 NAME 'matchingRuleUse'
1818 EQUALITY objectIdentifierFirstComponentMatch
1819 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
1820 USAGE directoryOperation )
1822 The 'objectIdentifierFirstComponentMatch' matching rule and the
1823 MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
1824 defined in [Syntaxes].
1827 4.2.5. 'ldapSyntaxes'
1829 This attribute holds definitions of LDAP syntaxes.
1831 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
1832 EQUALITY objectIdentifierFirstComponentMatch
1833 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
1834 USAGE directoryOperation )
1836 The 'objectIdentifierFirstComponentMatch' matching rule and the
1837 SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
1841 4.2.6. 'dITContentRules'
1843 This attribute lists DIT Content Rules which are in force.
1845 ( 2.5.21.2 NAME 'dITContentRules'
1846 EQUALITY objectIdentifierFirstComponentMatch
1850 Zeilenga LDAP Models [Page 33]
1852 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1855 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
1856 USAGE directoryOperation )
1858 The 'objectIdentifierFirstComponentMatch' matching rule and the
1859 DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
1860 defined in [Syntaxes].
1863 4.2.7. 'dITStructureRules'
1865 This attribute lists DIT Structure Rules which are in force.
1867 ( 2.5.21.1 NAME 'dITStructureRules'
1868 EQUALITY integerFirstComponentMatch
1869 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
1870 USAGE directoryOperation )
1872 The 'integerFirstComponentMatch' matching rule and the
1873 DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
1874 defined in [Syntaxes].
1879 This attribute lists Name Forms which are in force.
1881 ( 2.5.21.7 NAME 'nameForms'
1882 EQUALITY objectIdentifierFirstComponentMatch
1883 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
1884 USAGE directoryOperation )
1886 The 'objectIdentifierFirstComponentMatch' matching rule and the
1887 NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
1891 4.3. 'extensibleObject' object class
1893 The 'extensibleObject auxiliary object class allows entries belong to
1894 it to hold any attribute type. The set of allowed attributes of this
1895 class is implicitly the set of all user attributes.
1897 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
1900 The mandatory attributes of the other object classes of this entry are
1901 still required to be present and any precluded attributes are still
1902 not allowed to be present.
1906 Zeilenga LDAP Models [Page 34]
1908 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1911 Note that not all servers will implement this object class, and those
1912 which do not will reject requests to add entries which contain this
1913 object class, or modify an entry to add this object class.
1916 4.4. Subschema Discovery
1918 To discover the DN of the subschema (sub)entry holding the subschema
1919 controlling a particular entry, a client reads that entry's
1920 'subschemaSubentry' operational attribute. To read schema attributes
1921 from the subschema (sub)entry, clients MUST issue a base object search
1922 where the filter is "(objectClass=subschema)" [Filters] and the list
1923 of attributes includes the names of the desired schema attributes (as
1924 they are operational). This filter allows LDAP servers which gateway
1925 to X.500 to detect that subentry information is being requested.
1927 Clients SHOULD NOT assume a published subschema is complete nor assume
1928 the server supports all of the schema elements it publishes nor assume
1929 the server does not support an unpublished element.
1932 5. DSA (Server) Informational Model
1934 The LDAP protocol assumes there are one or more servers which jointly
1935 provide access to a Directory Information Tree (DIT).
1937 As defined in [X.501]:
1939 context prefix: The sequence of RDNs leading from the Root of the
1940 DIT to the initial vertex of a naming context; corresponds to
1941 the distinguished name of that vertex.
1943 DIB fragment: The portion of the DIB that is held by one master
1944 DSA, comprising one or more naming contexts.
1946 naming context: A subtree of entries held in a single master DSA.
1948 That is, a naming context is the largest collection of entries,
1949 starting at an entry that is mastered by a particular server, and
1950 including all its subordinates and their subordinates, down to the
1951 entries which are mastered by different servers. The context prefix
1952 is the name of the initial entry.
1954 The root of the DIT is a DSA-specific Entry (DSE) and not part of any
1955 naming context (or any subtree); each server has different attribute
1956 values in the root DSE.
1962 Zeilenga LDAP Models [Page 35]
1964 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
1967 5.1. Server-specific Data Requirements
1969 An LDAP server SHALL provide information about itself and other
1970 information that is specific to each server. This is represented as a
1971 group of attributes located in the root DSE (DSA-Specific Entry),
1972 which is named with the zero-length LDAPDN. These attributes are
1973 retrievable, subject to access control and other restrictions, if a
1974 client performs a base object search of the root with the filter
1975 "(objectClass=*)" [Filters] requesting the desired attributes. It is
1976 noted that root DSE attributes are operational, and like other
1977 operational attributes, are not returned in search requests unless
1980 The root DSE SHALL NOT be included if the client performs a subtree
1981 search starting from the root.
1983 Servers may allow clients to modify attributes of the root DSE where
1986 The following attributes of the root DSE are defined in [Syntaxes].
1987 Additional attributes may be defined in other documents.
1989 - altServer: alternative servers;
1991 - namingContexts: naming contexts;
1993 - supportedControl: recognized LDAP controls;
1995 - supportedExtension: recognized LDAP extended operations;
1997 - supportedLDAPVersion: LDAP versions supported; and
1999 - supportedSASLMechanisms: recognized Simple Authentication and
2000 Security Layers (SASL) [SASL] mechanisms.
2002 The values of these attributes provided may depend on session specific
2003 and other factors. For example, a server supporting the SASL EXTERNAL
2004 mechanism might only list "EXTERNAL" when the client's identity has
2005 been established by a lower level. See [AuthMeth].
2007 The root DSE may also include a 'subschemaSubentry' attribute. If so,
2008 it refers to the subschema (sub)entry holding schema controlling
2009 attributes of the root DSE. Client SHOULD NOT assume that the
2010 subschema (sub)entry controlling the root DSE controls any entry held
2011 by the server. General subschema discovery procedures are provided in
2018 Zeilenga LDAP Models [Page 36]
2020 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2025 The 'altServer' attribute lists URLs referring to alternative servers
2026 which may be contacted when this server becomes unavailable. If the
2027 server does not know of any other servers which could be used this
2028 attribute will be absent. Clients may cache this information in case
2029 their preferred server later becomes unavailable.
2031 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
2032 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
2033 USAGE dSAOperation )
2035 The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
2039 5.1.2. 'namingContexts'
2041 The 'namingContexts' attribute lists the context prefixes of the
2042 naming contexts the server masters or shadows (in part or in whole).
2043 If the server is a first-level DSA [X.501], it should list (in
2044 addition) an empty string (indicating the root of the DIT). If the
2045 server does not master or shadow any information (e.g. it is an LDAP
2046 gateway to a public X.500 directory) this attribute will be absent.
2047 If the server believes it masters or shadows the entire directory, the
2048 attribute will have a single value, and that value will be the empty
2049 string (indicating the root of the DIT). This attribute allows a
2050 client to choose suitable base objects for searching when it has
2053 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
2054 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2055 USAGE dSAOperation )
2057 The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
2058 defined in [Syntaxes].
2061 5.1.3. 'supportedControl'
2063 The 'supportedControl' attribute lists object identifiers identifying
2064 the request controls the server supports. If the server does not
2065 support any request controls, this attribute will be absent.
2067 Object identifiers identifying response controls need not be listed.
2069 Procedures for registering object identifiers used to discovery of
2070 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2074 Zeilenga LDAP Models [Page 37]
2076 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2079 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
2080 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2081 USAGE dSAOperation )
2083 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2084 defined in [Syntaxes].
2087 5.1.4. 'supportedExtension'
2089 The 'supportedExtension' attribute lists object identifiers
2090 identifying the extended operations which the server supports. If the
2091 server does not support any extended operations, this attribute will
2094 An extended operation comprises a ExtendedRequest, possibly other PDUs
2095 defined by extension, and an ExtendedResponse [Protocol]. The object
2096 identifier assigned to the ExtendedRequest is used to identify the
2097 extended operation. Other object identifiers associated with the
2098 extended operation need not be listed.
2100 Procedures for registering object identifiers used to discovery of
2101 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2103 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
2104 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2105 USAGE dSAOperation )
2107 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2108 defined in [Syntaxes].
2111 5.1.5. 'supportedLDAPVersion'
2113 The 'supportedLDAPVersion' attribute lists the versions of LDAP which
2114 the server supports.
2116 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
2117 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2118 USAGE dSAOperation )
2120 The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
2124 5.1.6. 'supportedSASLMechanisms'
2126 The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
2130 Zeilenga LDAP Models [Page 38]
2132 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2135 [RFC2222] which the server recognizes. The contents of this attribute
2136 may depend on the current session state. If the server does not
2137 support any SASL mechanisms this attribute will not be present.
2139 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
2140 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2141 USAGE dSAOperation )
2143 The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
2147 6. Other Considerations
2149 6.1. Preservation of User Information
2151 Syntaxes may be defined which have specific value and/or value form
2152 (representation) preservation requirements. For example, a syntax
2153 containing digitally signed data can mandate the server preserve both
2154 the value and form of value presented to ensure signature is not
2157 Where such requirements have not be explicitly stated, servers SHOULD
2158 preserve the value of user information but MAY return the value in a
2159 different form. And where a server is unable (or unwilling) to
2160 preserve the value of user information, the server SHALL ensure that
2161 an equivalent value (per Section 2.3) is returned.
2166 Short names, also known as descriptors, are used as more readable
2167 aliases for object identifiers and are used to identify various schema
2168 elements. However, it is not expected that LDAP implementations with
2169 human user interface would display these short names (nor the object
2170 identifiers they refer to) to the user, but would most likely be
2171 performing translations (such as expressing the short name in one of
2172 the local national languages). For example, the short name "st"
2173 (stateOrProvinceName) might be displayed to a German-speaking user as
2176 The same short name might have different meaning in different
2177 subschemas and, within a particular subschema, the same short name
2178 might refer to different object identifiers each identifying a
2179 different kind of schema element.
2181 Implementations MUST be prepared that the same short name might be
2182 used in a subschema to refer to the different kinds of schema
2186 Zeilenga LDAP Models [Page 39]
2188 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2191 elements. That is, there might be an object class 'x-fubar' and an
2192 attribute type 'x-fubar' in a subschema.
2194 Implementations MUST be prepared that the same short name might be
2195 used in the different subschemas to refer to the different schema
2196 elements. That is, there might be two matching rules 'x-fubar', each
2197 in different subschemas.
2199 Procedures for registering short names (descriptors) are detailed in
2203 6.3. Cache and Shadowing
2205 Some servers may hold cache or shadow copies of entries, which can be
2206 used to answer search and comparison queries, but will return
2207 referrals or contact other servers if modification operations are
2208 requested. Servers that perform shadowing or caching MUST ensure that
2209 they do not violate any access control constraints placed on the data
2210 by the originating server.
2213 7. Implementation Guidelines
2215 7.1 Server Guidelines
2217 Servers MUST recognize all attribute types and object classes names
2218 defined in this document but, unless stated otherwise, need not
2219 support the associated functionality. Servers SHOULD recognize all
2220 the names of attribute types and object classes defined in Section 3
2221 and 4, respectively, of [Schema].
2223 Servers MUST ensure that entries conform to user and system schema
2224 rules or other data model constraints.
2226 Servers MAY support the 'extensibleObject' object class.
2228 Servers MAY support DIT Content Rules. Servers MAY support DIT
2229 Structure Rules and Name Forms.
2231 Servers MAY support alias entries.
2233 Servers MAY support subentries. If so, they MUST do so in accordance
2234 with [X.501]. Servers which do not support subentries SHOULD use
2235 object entries to mimic subentries as detailed in Section 3.2.
2237 Servers MAY implement additional schema elements. Servers SHOULD
2238 provide definitions of all schema elements they support in subschema
2242 Zeilenga LDAP Models [Page 40]
2244 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2250 7.2 Client Guidelines
2252 Clients MUST NOT display nor attempt to decode as ASN.1, a value if
2253 its syntax is not known. The implementation may attempt to discover
2254 the subschema of the source entry, and retrieve the values of
2255 'attributeTypes' from the subschema (sub)entry.
2257 Clients MUST NOT assume the LDAP-specific string encoding is
2258 restricted to a UTF-8 encoded string of UCS characters or any
2259 particular subset of particular subset of UCS (such as a printable
2260 subset) unless such restriction is explicitly stated.
2262 Clients MUST NOT send attribute values in a request that are not valid
2263 according to the syntax defined for the attributes.
2266 8. Security Considerations
2268 Attributes of directory entries are used to provide descriptive
2269 information about the real-world objects they represent, which can be
2270 people, organizations or devices. Most countries have privacy laws
2271 regarding the publication of information about people.
2273 General security considerations for accessing directory information
2274 with LDAP are discussed in [Protocol] and [AuthMeth].
2277 9. IANA Considerations
2279 It is requested that the Internet Assigned Numbers Authority (IANA)
2280 update the LDAP descriptors registry as indicated the following
2283 Subject: Request for LDAP Descriptor Registration Update
2284 Descriptor (short name): see comment
2285 Object Identifier: see comment
2286 Person & email address to contact for further information:
2287 Kurt Zeilenga <kurt@OpenLDAP.org>
2289 Specification: RFC XXXX
2290 Author/Change Controller: IESG
2293 The following descriptors (short names) should be updated to refer
2298 Zeilenga LDAP Models [Page 41]
2300 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2304 ------------------------ ---- -----------------
2306 aliasedEntryName A 2.5.4.1
2307 aliasedObjectName A 2.5.4.1
2308 altServer A 1.3.6.1.4.1.1466.101.120.6
2309 attributeTypes A 2.5.21.5
2310 createTimestamp A 2.5.18.1
2311 creatorsName A 2.5.18.3
2312 dITContentRules A 2.5.21.2
2313 dITStructureRules A 2.5.21.1
2314 extensibleObject O 1.3.6.1.4.1.1466.101.120.111
2315 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
2316 matchingRuleUse A 2.5.21.8
2317 matchingRules A 2.5.21.4
2318 modifiersName A 2.5.18.4
2319 modifyTimestamp A 2.5.18.2
2320 nameForms A 2.5.21.7
2321 namingContexts A 1.3.6.1.4.1.1466.101.120.5
2322 objectClass A 2.5.4.0
2323 objectClasses A 2.5.21.6
2324 subschema O 2.5.20.1
2325 subschemaSubentry A 2.5.18.10
2326 supportedControl A 1.3.6.1.4.1.1466.101.120.13
2327 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
2328 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
2329 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
2335 This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
2336 S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
2337 RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
2338 Indexing of Directories (ASID) Working Group. This document is also
2339 based in part on "The Directory: Models" [X.501], a product of the
2340 International Telephone Union (ITU). Additional text was borrowed
2341 from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
2343 This document is a product of the IETF LDAP Revison (LDAPBIS) Working
2347 11. Author's Address
2350 E-mail: <kurt@openldap.org>
2354 Zeilenga LDAP Models [Page 42]
2356 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2361 12.1. Normative References
2363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2364 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
2366 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2367 Specifications: ABNF", RFC 2234, November 1997.
2369 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
2370 ietf-ldapbis-bcp64-xx.txt, a work in progress.
2372 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
2373 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
2376 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
2377 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
2379 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
2380 Connection Level Security Mechanisms",
2381 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
2383 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
2384 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
2387 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
2388 Representation of Search Filters",
2389 draft-ietf-ldapbis-filter-xx.txt, a work in progress.
2391 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
2392 draft-ietf-ldapbis-url-xx.txt, a work in progress.
2394 [SASL] Melnikov, A. (Editor), "Simple Authentication and
2395 Security Layer (SASL)",
2396 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
2398 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
2399 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
2401 [Schema] Dally, K. (editor), "LDAP: User Schema",
2402 draft-ietf-ldapbis-user-schema-xx.txt, a work in
2405 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
2406 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
2410 Zeilenga LDAP Models [Page 43]
2412 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2417 [ISO10646] International Organization for Standardization,
2418 "Universal Multiple-Octet Coded Character Set (UCS) -
2419 Architecture and Basic Multilingual Plane", ISO/IEC
2422 [ASCII] Coded Character Set--7-bit American Standard Code for
2423 Information Interchange, ANSI X3.4-1986.
2425 [X.500] International Telecommunication Union -
2426 Telecommunication Standardization Sector, "The Directory
2427 -- Overview of concepts, models and services,"
2428 X.500(1993) (also ISO/IEC 9594-1:1994).
2430 [X.501] International Telecommunication Union -
2431 Telecommunication Standardization Sector, "The Directory
2432 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
2434 [X.680] International Telecommunication Union -
2435 Telecommunication Standardization Sector, "Abstract
2436 Syntax Notation One (ASN.1) - Specification of Basic
2437 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
2440 12.2. Informative References
2447 This appendix is non-normative.
2449 This document amounts to nearly a complete rewrite of portions of RFC
2450 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
2451 overall clarity of technical specification. This appendix provides a
2452 summary of substantive changes made to the portions of these documents
2453 incorporated into this document. Readers should consult [Roadmap],
2454 [Protocol], [Syntaxes], and [Schema] for summaries of remaining
2455 portions of these documents.
2458 A.1 Changes to RFC 2251
2460 This document incorporates from RFC 2251 sections 3.2 and 3.4,
2461 portions of Section 4 and 6 as summarized below.
2466 Zeilenga LDAP Models [Page 44]
2468 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2471 A.1.1 Section 3.2 of RFC 2251
2473 Section 3.2 of RFC 2251 provided a brief introduction to the X.500
2474 data model, as used by LDAP. The previous specification relied on
2475 [X.501] but lacked clarity in how X.500 models are adapted for use by
2476 LDAP. This document describes the X.500 data models, as used by LDAP
2477 in greater detail, especially in areas where the models require
2478 adaptation is needed.
2480 Section 3.2.1 of RFC 2251 described an attribute as "a type with one
2481 or more associated values." In LDAP, an attribute is better described
2482 as an attribute description, a type with zero or more options, and one
2483 or more associated values.
2485 Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
2486 objectClasses and attributeTypes attributes, yet X.500(93) treats
2487 these attributes as optional. While generally all implementations
2488 that support X.500(93) subschema mechanisms will provide both of these
2489 attributes, it is not absolutely required for interoperability that
2490 all servers do. The mandate was removed for consistency with
2491 X.500(93). The subschema discovery mechanism was also clarified to
2492 indicate that subschema controlling an entry is obtained by reading
2493 the (sub)entry referred to by that entry's 'subschemaSubentry'
2497 A.1.2 Section 3.4 of RFC 2251
2499 Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
2500 This material, with changes, was incorporated in Section 5.1 of this
2505 - Clarify that attributes of the root DSE are subject to "other
2506 restrictions" in addition to access controls.
2508 - Clarify that only recognized extended requests need to be enumerated
2509 'supportedExtension'.
2511 - Clarify that only recognized request controls need to be enumerated
2514 - Clarify that root DSE attributes are operational and, like other
2515 operational attributes, will not be returned in search requests
2516 unless requested by name.
2518 - Clarify that not all root DSE attributes are user modifiable.
2522 Zeilenga LDAP Models [Page 45]
2524 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2527 - Remove inconsistent text regarding handling of the
2528 'subschemaSubentry' attribute within the root DSE. The previous
2529 specification stated that the 'subschemaSubentry' attribute held in
2530 the root DSE referred to "subschema entries (or subentries) known by
2531 this server." This is inconsistent with the attribute intended use
2532 as well as its formal definition as a single valued attribute
2533 [X.501]. It is also noted that a simple (possibly incomplete) list
2534 of subschema (sub)entries is not terrible useful. This document (in
2535 section 5.1) specifies that the 'subschemaSubentry' attribute of the
2536 root DSE refers to the subschema controlling the root DSE. It is
2537 noted that the general subschema discovery mechanism remains
2538 available (see Section 4.4 of this document).
2541 A.1.2 Section 4 of RFC 2251
2543 Portions of Section 4 of RFC 2251 detailing aspects of the information
2544 model used by LDAP were incorporated in this document, including:
2546 - Restriction of distinguished values to attributes whose descriptions
2547 have no options (from Section 4.1.3).
2549 - Data model aspects of Attribute Types (from Section 4.1.4),
2550 Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8),
2551 Matching Rule Identifier (from 4.1.9).
2553 - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
2556 A.1.3 Section 6 of RFC 2251
2558 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
2559 where incorporated into this document.
2562 A.2 Changes to RFC 2252
2564 This document incorporates Sections 4, 5 and 7 from RFC 2252.
2567 A.2.1 Section 4 of RFC 2252
2569 The specification was updated to use Augmented BNF [RFC2234]. The
2570 string representation of an OBJECT IDENTIFIER was tighten to
2571 disallow leading zeros as described in RFC 2252 text.
2573 The <descr> syntax was changed to disallow semicolon (U+003B)
2574 characters to appear to be consistent its natural language
2578 Zeilenga LDAP Models [Page 46]
2580 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2583 specification "descr is the syntactic representation of an object
2584 descriptor, which consists of letters and digits, starting with a
2585 letter." In a related change, the statement "an
2586 AttributeDescription can be used as the value in a NAME part of an
2587 AttributeTypeDescription" was deleted. RFC 2252 provided no
2588 specification as to the semantics of attribute options appearing in
2591 RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
2592 over the <numericoid> form. However, <descr> form can be ambiguous.
2593 To address this issue, the imperative was replaced with a statement
2594 (in Section 1.4) that while the <descr> form is generally preferred,
2595 <numericoid> should be used where an unambiguous <descr> is not
2596 available. Additionally, an expanded discussion of descriptor
2597 issues is discussed in Section 6.2 (Short Names).
2599 The ABNF for a quoted string (qdstring) was updated to reflect
2600 support for the escaping mechanism described in 4.3 of RFC 2252.
2603 A.2.2 Section 5 of RFC 2252
2605 Definitions of operational attributes provided in Section 5 of RFC
2606 2252 where incorporated into this document.
2608 The 'namingContexts' description was clarified. A first-level DSA
2609 should publish, in addition to other values, "" indicating the root
2612 The 'supportedExtension' description was clarified. A server need
2613 only list the OBJECT IDENTIFIERs associated with the extended
2614 requests of the extended operations it recognizes.
2616 The 'supportedControl' description was clarified. A server need
2617 only list the OBJECT IDENTIFIERs associated with the request
2618 controls it recognizes.
2621 A.2.3 Section 7 of RFC 2252
2623 Section 7 of RFC 2252 provides definitions of the 'subschema' and
2624 'extensibleObject' object classes. These definitions where
2625 integrated into Section 4.2 and Section 4.3 of this document,
2626 respectively. Section 7 of RFC 2252 also contained the object class
2627 implementation requirement. This was incorporated into Section 7 of
2630 The specification of 'extensibleObject' was clarified of how it
2634 Zeilenga LDAP Models [Page 47]
2636 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2639 interacts with precluded attributes.
2642 A.3 Changes to RFC 2256
2644 This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2647 Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
2648 attribute type. This was integrated into Section 2.4.1 of this
2649 document. The statement "One of the values is either 'top' or
2650 'alias'" was replaced with statement that one of the values is 'top'
2651 as entries belonging to 'alias' also belong to 'top'.
2653 Section 5.2 of RFC 2256 provided the definition of the
2654 'aliasedObjectName' attribute type. This was integrated into
2655 Section 2.6.2 of this document.
2657 Section 7.1 of RFC 2256 provided the definition of the 'top' object
2658 class. This was integrated into Section 2.4.1 of this document.
2660 Section 7.2 of RFC 2256 provided the definition of the 'alias'
2661 object class. This was integrated into Section 2.6.1 of this
2666 Intellectual Property Rights
2668 The IETF takes no position regarding the validity or scope of any
2669 intellectual property or other rights that might be claimed to pertain
2670 to the implementation or use of the technology described in this
2671 document or the extent to which any license under such rights might or
2672 might not be available; neither does it represent that it has made any
2673 effort to identify any such rights. Information on the IETF's
2674 procedures with respect to rights in standards-track and
2675 standards-related documentation can be found in BCP-11. Copies of
2676 claims of rights made available for publication and any assurances of
2677 licenses to be made available, or the result of an attempt made to
2678 obtain a general license or permission for the use of such proprietary
2679 rights by implementors or users of this specification can be obtained
2680 from the IETF Secretariat.
2682 The IETF invites any interested party to bring to its attention any
2683 copyrights, patents or patent applications, or other proprietary
2684 rights which may cover technology that may be required to practice
2685 this standard. Please address the information to the IETF Executive
2690 Zeilenga LDAP Models [Page 48]
2692 INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2697 Copyright (C) The Internet Society (2003). All Rights Reserved.
2699 This document and translations of it may be copied and furnished to
2700 others, and derivative works that comment on or otherwise explain it
2701 or assist in its implmentation may be prepared, copied, published and
2702 distributed, in whole or in part, without restriction of any kind,
2703 provided that the above copyright notice and this paragraph are
2704 included on all such copies and derivative works. However, this
2705 document itself may not be modified in any way, such as by removing
2706 the copyright notice or references to the Internet Society or other
2707 Internet organizations, except as needed for the purpose of
2708 developing Internet standards in which case the procedures for
2709 copyrights defined in the Internet Standards process must be followed,
2710 or as required to translate it into languages other than English.
2746 Zeilenga LDAP Models [Page 49]
projects / openldap / blob