7 INTERNET-DRAFT Editor: Kurt D. Zeilenga
8 Intended Category: Standard Track OpenLDAP Foundation
9 Expires in six months 15 February 2004
10 Obsoletes: RFC 2251, RFC 2252, RFC 2256
14 LDAP: Directory Information Models
15 <draft-ietf-ldapbis-models-10.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 editor <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 (2004). 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-10 15 February 2004
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
84 3.4. Operational attributes 18
85 4. Directory Schema 21
86 4.1. Schema Definitions 22
87 4.2. Subschema Subentries 31
88 4.3. 'extensibleObject' 35
89 4.4. Subschema Discovery
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
96 7. Implementation Guidelines
97 7.1. Server Guidelines
98 7.2. Client Guidelines 41
99 8. Security Considerations
100 9. IANA Considerations 42
101 10. Acknowledgments 43
104 12.1. Normative References
105 12.2. Informative References 45
107 Intellectual Property Rights 49
114 Zeilenga LDAP Models [Page 2]
116 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
121 This document discusses the X.500 Directory Information Models
122 [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
125 The Directory is "a collection of open systems cooperating to provide
126 directory services" [X.500]. The information held in the Directory is
127 collectively known as the Directory Information Base (DIB). A
128 Directory user, which may be a human or other entity, accesses the
129 Directory through a client (or Directory User Agent (DUA)). The
130 client, on behalf of the directory user, interacts with one or more
131 servers (or Directory System Agents (DSA)). A server holds a fragment
134 The DIB contains two classes of information:
136 1) user information (e.g., information provided and administrated
137 by users). Section 2 describes the Model of User Information.
139 2) administrative and operational information (e.g., information
140 used to administer and/or operate the directory). Section 3
141 describes the model of Directory Administrative and Operational
144 These two models, referred to as the generic Directory Information
145 Models, describe how information is represented in the Directory.
146 These generic models provide a framework for other information models.
147 Section 4 discusses the subschema information model and subschema
148 discovery. Section 5 discusses the DSA (Server) Informational Model.
150 Other X.500 information models, such as access control distribution
151 knowledge, and replication knowledge information models, may be
152 adapted for use in LDAP. Specification of how these models apply to
153 LDAP is left to future documents.
156 1.1. Relationship to Other LDAP Specifications
158 This document is a integral part of the LDAP technical specification
159 [Roadmap] which obsoletes the previously defined LDAP technical
160 specification, RFC 3377, in its entirety.
162 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
163 portions of sections 4 and 6. Appendix A.1 summaries changes to these
164 sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
165 [AuthMeth], and [Roadmap] documents.
170 Zeilenga LDAP Models [Page 3]
172 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
175 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
176 summaries changes to these sections. The remainder of RFC 2252 is
177 obsoleted by [Syntaxes].
179 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
180 Appendix A.3 summarizes changes to these sections. The remainder of
181 RFC 2256 is obsoleted by [Schema] and [Syntaxes].
184 1.2. Relationship to X.501
186 This document includes material, with and without adaptation, from
187 [X.501]. The material in this document takes precedence over that in
193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
195 document are to be interpreted as described in BCP 14 [RFC2119].
197 Schema definitions are provided using LDAP description formats (as
198 defined in Section 4.1). Definitions provided here are formatted
199 (line wrapped) for readability. Matching rules and LDAP syntaxes
200 referenced in these definitions are specified in [Syntaxes].
203 1.4. Common ABNF Productions
205 A number of syntaxes in this document are described using Augmented
206 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
207 number of syntaxes defined in other documents) rely on the following
210 keystring = leadkeychar *keychar
212 keychar = ALPHA / DIGIT / HYPHEN
213 number = DIGIT / ( LDIGIT 1*DIGIT )
215 ALPHA = UALPHA / %x61-7A ; "A"-"Z" / "a"-"z"
216 UALPHA = %x41-5A ; "A"-"Z"
217 DIGIT = %x30 / LDIGIT ; "0"-"9"
218 LDIGIT = %x31-39 ; "1"-"9"
219 HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
221 SP = 1*SPACE ; one or more " "
222 WSP = 0*SPACE ; zero or more " "
226 Zeilenga LDAP Models [Page 4]
228 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
231 NULL = %x00 ; null (0)
232 SPACE = %x20 ; space (" ")
233 DQUOTE = %x22 ; quote (""")
234 SHARP = %x23 ; octothorpe (or sharp sign) ("#")
235 DOLLAR = %x24 ; dollar sign ("$")
236 SQUOTE = %x27 ; single quote ("'")
237 LPAREN = %x28 ; left paren ("(")
238 RPAREN = %x29 ; right paren (")")
239 PLUS = %x2B ; plus sign ("+")
240 COMMA = %x2C ; comma (",")
241 HYPHEN = %x2D ; hyphen ("-")
242 DOT = %x2E ; period (".")
243 SEMI = %x3B ; semicolon (";")
244 LANGLE = %x3C ; left angle bracket ("<")
245 EQUALS = %x3D ; equals sign ("=")
246 RANGLE = %x3E ; right angle bracket (">")
247 ESC = %x5C ; backslash ("\")
248 USCORE = %x5F ; underscore ("_")
249 LCURLY = %x7B ; left curly brace "{"
250 RCURLY = %x7D ; right curly brace "}"
252 ; Any UTF-8 [UTF-8] encoded UCS [ISO10646] character
254 UTFMB = UTF2 / UTF3 / UTF4
258 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
259 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
260 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
263 OCTET = %x00-FF ; Any octet
265 Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
266 decimal format conforming to the ABNF:
268 numericoid = number 1*( DOT number )
270 Short names, also known as descriptors, are used as more readable
271 aliases for object identifiers. Short names are case insensitive and
276 Where either an object identifier or a short name may be specified,
277 the following production is used:
282 Zeilenga LDAP Models [Page 5]
284 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
287 oid = descr / numericoid
289 While the <descr> form is generally preferred when the usage is
290 restricted to short names referring to object identifiers which
291 identify like kinds of objects (e.g., attribute type descriptions,
292 matching rule descriptions, object class descriptions), the
293 <numericoid> form should be used when the object identifiers may
294 identify multiple kinds of objects or when an unambiguous short name
295 (descriptor) is not available.
297 Implementations SHOULD treat short names (descriptors) used in an
298 unambiguous manner (as discussed above) as unrecognized.
300 Short Names (descriptors) are discussed further in Section 6.2.
303 2. Model of Directory User Information
307 The purpose of the Directory is to hold, and provide access to,
308 information about objects of interest (objects) in some 'world'.
309 An object can be anything which is identifiable (can be named).
311 An object class is an identified family of objects, or conceivable
312 objects, which share certain characteristics. Every object belongs
313 to at least one class. An object class may be a subclass of other
314 object classes, in which case the members of the former class, the
315 subclass, are also considered to be members of the latter classes,
316 the superclasses. There may be subclasses of subclasses, etc., to
319 A directory entry, a named collection of information, is the basic
320 unit of information held in the Directory. There are multiple kinds
321 of directory entries.
323 An object entry represents a particular object. An alias entry
324 provides alternative naming. A subentry holds administrative and/or
325 operational information.
327 The set of entries representing the DIB are organized hierarchically
328 in a tree structure known as the Directory Information Tree (DIT).
330 Section 2.1 describes the Directory Information Tree
331 Section 2.2 discusses naming of entries.
332 Section 2.3 discusses the structure of entries.
333 Section 2.4 discusses object classes.
334 Section 2.5 discusses attribute descriptions.
338 Zeilenga LDAP Models [Page 6]
340 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
343 Section 2.6 discusses alias entries.
346 2.1. The Directory Information Tree
348 As noted above, the DIB is composed of a set of entries organized
349 hierarchically in a tree structure known as the Directory Information
350 Tree (DIT). Specifically, a tree where vertices are the entries.
352 The arcs between vertices define relations between entries. If an arc
353 exists from X to Y, then the entry at X is the immediate superior of Y
354 and Y is the immediate subordinate of X. An entry's superiors are the
355 entry's immediate superior and its superiors. An entry's subordinates
356 are all of its immediate subordinates and their subordinates.
358 Similarly, the superior/subordinate relationship between object
359 entries can be used to derive a relation between the objects they
360 represent. DIT structure rules can be used to govern relationships
363 Note: An entry's immediate superior is also known as the entry's
364 parent and an entry's immediate subordinate is also known as the
365 entry's child. Entries which have the same parent are known as
369 2.2. Naming of Entries
371 2.2.1. Relative Distinguished Names
373 Each entry is named relative to its immediate superior. This relative
374 name, known as its Relative Distinguished Name (RDN) [X.501], is
375 composed of an unordered set of one or more attribute value assertions
376 (AVA) consisting of an attribute description with zero options and an
377 attribute value. These AVAs are chosen from the attributes of the
380 An entry's relative distinguished name must be unique among all
381 immediate subordinates of the entry's immediate superior (i.e., all
384 The following are examples of string representations of RDNs [LDAPDN]:
388 CN=Kurt Zeilenga+L=Redwood Shores
390 The last is an example of a multi-valued RDN. That is, an RDN
394 Zeilenga LDAP Models [Page 7]
396 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
399 composed of multiple AVAs.
402 2.2.2. Distinguished Names
404 An entry's fully qualified name, known as its Distinguished Name (DN)
405 [X.501], is the concatenation of its RDN and its immediate superior's
406 DN. A Distinguished Name unambiguously refers to an entry in the
407 tree. The following are examples of string representations of DNs
410 UID=nobody@example.com,DC=example,DC=com
411 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
416 An alias, or alias name, is "an name for an object, provided by the
417 use of alias entries" [X.501]. Alias entries are described in Section
421 2.3. Structure of an Entry
423 An entry consists of a set of attributes which hold information about
424 the object which the entry represents. Some attributes represent user
425 information and are called user attributes. Other attributes
426 represent operational and/or administrative information and are called
427 operational attributes.
429 An attribute is an attribute description (a type and zero or more
430 options) with one or more associated values. An attribute is often
431 referred to by its attribute description. For example, the
432 'givenName' attribute is the attribute which consists of the attribute
433 description 'givenName' (the 'givenName' attribute type [Schema] and
434 zero options) and one or more associated values.
436 The attribute type governs whether the attribute can have multiple
437 values, the syntax and matching rules used to construct and compare
438 values of that attribute, and other functions. Options indicate
439 subtypes and other functions. No two values of an attribute may be
442 Two values are considered equivalent if they would match according to
443 the equality matching rule of the attribute type. If the attribute
444 type is defined with no equality matching rule, two values are
445 equivalent if and only if they are identical.
450 Zeilenga LDAP Models [Page 8]
452 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
455 For example, a 'givenName' attribute can have can have more than one
456 value, they must be Directory Strings, and they are case insensitive.
457 A 'givenName' attribute cannot hold both "John" and "JOHN" as these
458 are equivalent values per the equality matching rule of the attribute
464 An object class is "an identified family of objects (or conceivable
465 objects) which share certain characteristics" [X.501].
467 As defined in [X.501]:
469 Object classes are used in the Directory for a number of purposes:
471 - describing and categorising objects and the entries that
472 correspond to these objects;
474 - where appropriate, controlling the operation of the Directory;
476 - regulating, in conjunction with DIT structure rule
477 specifications, the position of entries in the DIT;
479 - regulating, in conjunction with DIT content rule
480 specifications, the attributes that are contained in entries;
482 - identifying classes of entry that are to be associated with a
483 particular policy by the appropriate administrative authority.
485 An object class (a subclass) may be derived from an object class
486 (its direct superclass) which is itself derived from an even more
487 generic object class. For structural object classes, this process
488 stops at the most generic object class, 'top' (defined in Section
489 2.4.1). An ordered set of superclasses up to the most superior
490 object class of an object class is its superclass chain.
492 An object class may be derived from two or more direct
493 superclasses (superclasses not part of the same superclass chain).
494 This feature of subclassing is termed multiple inheritance.
496 Each object class identifies the set of attributes required to be
497 present in entries belonging to the class and the set of attributes
498 allowed to be present in entries belonging to the class. As an entry
499 of a class must meet the requirements of each class it belongs to, it
500 can be said that an object class inherits the sets of allowed and
501 required attributes from its superclasses. A subclass can identify an
502 attribute allowed by its superclass as being required. If an
506 Zeilenga LDAP Models [Page 9]
508 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
511 attribute is a member of both sets, it is required to be present.
513 Each object class is defined to be one of three kinds of object
514 classes: Abstract, Structural, or Auxiliary.
516 Each object class is identified by an object identifier (OID) and,
517 optionally, one or more short names (descriptors).
520 2.4.1. Abstract Object Classes
522 An abstract object class, as the name implies, provides a base of
523 characteristics from which other object classes can be defined to
524 inherit from. An entry cannot belong to an abstract object class
525 unless it belongs to a structural or auxiliary class which inherits
526 from that abstract class.
528 Abstract object classes can not derive from structural nor auxiliary
531 All structural object classes derive (directly or indirectly) from the
532 'top' abstract object class. Auxiliary object classes do not
533 necessarily derive from 'top'.
535 The following is the object class definition (see Section 4.1.1) for
536 the 'top' object class:
538 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
540 All entries belong to the 'top' abstract object class.
543 2.4.2. Structural Object Classes
545 As stated in [X.501]:
547 An object class defined for use in the structural specification of
548 the DIT is termed a structural object class. Structural object
549 classes are used in the definition of the structure of the names
550 of the objects for compliant entries.
552 An object or alias entry is characterised by precisely one
553 structural object class superclass chain which has a single
554 structural object class as the most subordinate object class.
555 This structural object class is referred to as the structural
556 object class of the entry.
558 Structural object classes are related to associated entries:
562 Zeilenga LDAP Models [Page 10]
564 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
567 - an entry conforming to a structural object class shall
568 represent the real-world object constrained by the object
571 - DIT structure rules only refer to structural object classes;
572 the structural object class of an entry is used to specify the
573 position of the entry in the DIT;
575 - the structural object class of an entry is used, along with an
576 associated DIT content rule, to control the content of an
579 The structural object class of an entry shall not be changed.
581 Each structural object class is a (direct or indirect) subclass of the
582 'top' abstract object class.
584 Structural object classes cannot subclass auxiliary object classes.
586 Each entry is said to belong to its structural object class as well as
587 all classes in its structural object class's superclass chain.
590 2.4.3. Auxiliary Object Classes
592 Auxiliary object classes are used augment the characteristics of
593 entries. They are commonly used to augment the sets of attributes
594 required and allowed to be present in an entry. They can be used to
595 describe entries or classes of entries.
597 Auxiliary object classes cannot subclass structural object classes.
599 An entry can belong to any subset of the set of auxiliary object
600 classes allowed by the DIT content rule associated with the structural
601 object class of the entry. If no DIT content rule is associated with
602 the structural object class of the entry, the entry cannot belong to
603 any auxiliary object class.
605 The set of auxiliary object classes which an entry belongs to can
609 2.5. Attribute Descriptions
611 An attribute description is composed of an attribute type (see Section
612 2.5.1) and a set of zero or more attribute options (see Section
618 Zeilenga LDAP Models [Page 11]
620 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
623 An attribute description is represented by the ABNF:
625 attributedescription = attributetype options
627 options = *( SEMI option )
630 where <attributetype> identifies the attribute type and each <option>
631 identifies an attribute option. Both <attributetype> and <option>
632 productions are case insensitive. The order in which <option>s appear
633 is irrelevant. That is, any two <attributedescription>s which consist
634 of the same <attributetype> and same set of <option>s are equivalent.
636 Examples of valid attribute descriptions:
642 An attribute description with an unrecognized attribute type is to be
643 treated as unrecognized. Servers SHALL treat an attribute description
644 with an unrecognized attribute option as unrecognized. Clients MAY
645 treat an unrecognized attribute option as a tagging option (see
648 All attributes of an entry must have distinct attribute descriptions.
651 2.5.1. Attribute Types
653 An attribute type governs whether the attribute can have multiple
654 values, the syntax and matching rules used to construct and compare
655 values of that attribute, and other functions.
657 The attribute type indicates whether the attribute is a user attribute
658 or an operational attribute. If operational, the attribute type
659 indicates the operational usage and whether the attribute is
660 modifiable by users or not. Operational attributes are discussed in
663 An attribute type (a subtype) may derive from a more generic attribute
664 type (a direct supertype). The following restrictions apply to
666 - a subtype must have the same usage as its direct supertype,
667 - a subtype's syntax must be the same, or a refine of, its
668 supertype's syntax, and
669 - a subtype must be collective [RFC3671] if its supertype is
674 Zeilenga LDAP Models [Page 12]
676 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
679 An attribute description consisting of a subtype and no options is
680 said to be the direct description subtype of the attribute description
681 consisting of the subtype's direct supertype and no options.
683 Each attribute type is identified by an object identifier (OID) and,
684 optionally, one or more short names (descriptors).
687 2.5.2. Attribute Options
689 There are multiple kinds of attribute description options. The LDAP
690 technical specification details one kind: tagging options.
692 Not all options can be associated with attributes held in the
693 directory. Tagging options can be.
695 Not all options can be used in conjunction with all attribute types.
696 In such cases, the attribute description is to be treated as
699 An attribute description that contains mutually exclusive options
700 shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
701 "x-foo" and "x-bar" are mutually exclusive, is to be treated as
704 Other kinds of options may be specified in future documents. These
705 documents must detail how new kinds of options they define relate to
706 tagging options. In particular, these documents must detail whether
707 or not new kinds of options can be associated with attributes held in
708 the directory, how new kinds of options affect transfer of attribute
709 values, and how new kinds of options are treated in attribute
710 description hierarchies.
712 Options are represented as short case insensitive textual strings
713 conforming to the <option> production defined in Section 2.5 of this
716 Procedures for registering options are detailed in BCP 64 [BCP64bis].
719 2.5.2.1. Tagging Options
721 Attributes held in the directory can have attribute descriptions with
722 any number of tagging options. Tagging options are never mutually
725 An attribute description with N tagging options is a direct
726 (description) subtype of all attribute descriptions of the same
730 Zeilenga LDAP Models [Page 13]
732 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
735 attribute type and all but one of the N options. If the attribute
736 type has a supertype, then the attribute description is also a direct
737 (description) subtype of the attribute description of the supertype
738 and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
739 (description) subtype of 'cn;lang-de', 'cn;lang-en', and
740 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
744 2.5.3. Attribute Description Hierarchies
746 An attribute description can be the direct subtype of zero or more
747 other attribute descriptions as indicated by attribute type subtyping
748 (as described in Section 2.5.1) or attribute tagging option subtyping
749 (as described in Section 2.5.2.1). These subtyping relationships are
750 used to form hierarchies of attribute descriptions and attributes.
752 As adapted from [X.501]:
754 Attribute hierarchies allow access to the DIB with varying degrees
755 of granularity. This is achieved by allowing the value components
756 of attributes to be accessed by using either their specific
757 attribute description (a direct reference to the attribute) or by
758 a more generic attribute description (an indirect reference).
760 Semantically related attributes may be placed in a hierarchical
761 relationship, the more specialized being placed subordinate to the
762 more generalized. Searching for, or retrieving attributes and
763 their values is made easier by quoting the more generalized
764 attribute description; a filter item so specified is evaluated for
765 the more specialized descriptions as well as for the quoted
768 Where subordinate specialized descriptions are selected to be
769 returned as part of a search result these descriptions shall be
770 returned if available. Where the more general descriptions are
771 selected to be returned as part of a search result both the
772 general and the specialized descriptions shall be returned, if
773 available. An attribute value shall always be returned as a value
774 of its own attribute description.
776 All of the attribute descriptions in an attribute hierarchy are
777 treated as distinct and unrelated descriptions for user
778 modification of entry content.
780 An attribute value stored in a object or alias entry is of
781 precisely one attribute description. The description is indicated
782 when the value is originally added to the entry.
786 Zeilenga LDAP Models [Page 14]
788 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
791 For the purpose of subschema administration of the entry, a
792 specification that an attribute is required is fulfilled if the entry
793 contains a value of an attribute description belonging to an attribute
794 hierarchy where the attribute type of that description is the same as
795 the required attribute's type. That is, a "MUST name" specification
796 is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
797 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
798 'name'). Likewise, an entry may contain a value of an attribute
799 description belonging to an attribute hierarchy where the attribute
800 type of that description is either explicitly included in the
801 definition of an object class to which the entry belongs or allowed by
802 the DIT content rule applicable to that entry. That is, 'name' and
803 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
804 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
807 For the purposes of other policy administration, unless stated
808 otherwise in the specification of the particular administrative model,
809 all of the attribute descriptions in an attribute hierarchy are
810 treated as distinct and unrelated descriptions.
813 2.5.4. Attribute Values
815 Attribute values conform to the defined syntax of the attribute.
817 When an attribute is used for naming of the entry, one and only one
818 value of the attribute is selected to appear in the Relative
819 Distinguished Name. This value is known as a distinguished value.
821 Only attributes whose descriptions have no options can be used for
827 As adapted from [X.501]:
829 An alias, or an alias name, for an object is a an alternative name
830 for an object or object entry which is provided by the use of
833 Each alias entry contains, within the 'aliasedObjectName'
834 attribute (known as the 'aliasedEntryName' attribute in X.500]), a
835 name of some object. The distinguished name of the alias entry is
836 thus also a name for this object.
838 NOTE - The name within the 'aliasedObjectName' is said to be
842 Zeilenga LDAP Models [Page 15]
844 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
847 pointed to by the alias. It does not have to be the
848 distinguished name of any entry.
850 The conversion of an alias name to an object name is termed
851 (alias) dereferencing and comprises the systematic replacement of
852 alias names, where found within a purported name, by the value of
853 the corresponding 'aliasedObjectName' attribute. The process may
854 require the examination of more than one alias entry.
856 Any particular entry in the DIT may have zero or more alias names.
857 It therefore follows that several alias entries may point to the
858 same entry. An alias entry may point to an entry that is not a
859 leaf entry and may point to another alias entry.
861 An alias entry shall have no subordinates, so that an alias entry
862 is always a leaf entry.
864 Every alias entry shall belong to the 'alias' object class.
866 An entry with the 'alias' object class must also belong to an object
867 class (or classes), or be governed by a DIT content rule, which allows
868 suitable naming attributes to be present.
871 dn: cn=bar,dc=example,dc=com
874 objectClass: extensibleObject
876 aliasedObjectName: cn=foo,dc=example,dc=com
879 2.6.1. 'alias' object class
881 Alias entries belong to the 'alias' object class.
883 ( 2.5.6.1 NAME 'alias'
885 MUST aliasedObjectName )
888 2.6.2. 'aliasedObjectName' attribute type
890 The 'aliasedObjectName' attribute holds the name of the entry an alias
891 points to. The 'aliasedObjectName' attribute is known as the
892 'aliasedEntryName' attribute in X.500.
894 ( 2.5.4.1 NAME 'aliasedObjectName'
898 Zeilenga LDAP Models [Page 16]
900 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
903 EQUALITY distinguishedNameMatch
904 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
907 The 'distinguishedNameMatch' matching rule and the DistinguishedName
908 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
911 3. Directory Administrative and Operational Information
913 This section discusses select aspects of the X.500 Directory
914 Administrative and Operational Information model [X.501]. LDAP
915 implementations MAY support other aspects of this model.
920 As defined in [X.501]:
922 A subtree is a collection of object and alias entries situated at
923 the vertices of a tree. Subtrees do not contain subentries. The
924 prefix sub, in subtree, emphasizes that the base (or root) vertex
925 of this tree is usually subordinate to the root of the DIT.
927 A subtree begins at some vertex and extends to some identifiable
928 lower boundary, possibly extending to leaves. A subtree is always
929 defined within a context which implicitly bounds the subtree. For
930 example, the vertex and lower boundaries of a subtree defining a
931 replicated area are bounded by a naming context.
936 A subentry is a "special sort of entry, known by the Directory, used
937 to hold information associated with a subtree or subtree refinement"
938 [X.501]. Subentries are used in Directory to hold for administrative
939 and operational purposes as defined in [X.501]. Their use in LDAP is
940 detailed in [RFC3672].
942 The term "(sub)entry" in this specification indicates that servers
943 implementing X.500(93) models are, in accordance with X.500(93) as
944 described in [RFC3672], to use a subentry and that other servers are
945 to use an object entry belonging to the appropriate auxiliary class
946 normally used with the subentry (e.g., 'subschema' for subschema
947 subentries) to mimic the subentry. This object entry's RDN SHALL be
948 formed from a value of the 'cn' (commonName) attribute [Schema] (as
949 all subentries are named with 'cn').
954 Zeilenga LDAP Models [Page 17]
956 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
959 3.3. The 'objectClass' attribute
961 Each entry in the DIT has an 'objectClass' attribute.
963 ( 2.5.4.0 NAME 'objectClass'
964 EQUALITY objectIdentifierMatch
965 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
967 The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
968 (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
970 The 'objectClass' attribute specifies the object classes of an entry,
971 which (among other things) is used in conjunction with the controlling
972 schema to determine the permitted attributes of an entry. Values of
973 this attribute can be modified by clients, but the 'objectClass'
974 attribute cannot be removed.
976 Servers which follow X.500(93) models SHALL restrict modifications of
977 this attribute to prevent the basic structural class of the entry from
978 being changed. That is, one cannot change a 'person' into a
981 When creating an entry or adding an 'objectClass' value to an entry,
982 all superclasses of the named classes SHALL be implicitly added as
983 well if not already present. That is, if the auxiliary class 'x-a' is
984 a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
985 'x-b' to be implicitly added (if is not already present).
987 Servers SHALL restrict modifications of this attribute to prevent
988 superclasses of remaining 'objectClass' values from being deleted.
989 That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
990 class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
991 an attempt to delete only 'x-b' from the 'objectClass' attribute is an
995 3.4. Operational attributes
997 Some attributes, termed operational attributes, are used or maintained
998 by servers for administrative and operational purposes. As stated in
999 [X.501]: "There are three varieties of operational attributes:
1000 Directory operational attributes, DSA-shared operational attributes,
1001 and DSA-specific operational attributes."
1003 A directory operational attribute is used to represent operational
1004 and/or administrative information in the Directory Information Model.
1005 This includes operational attributes maintained by the server (e.g.
1006 'createTimestamp') as well as operational attributes which hold values
1010 Zeilenga LDAP Models [Page 18]
1012 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1015 administrated by the user (e.g. 'ditContentRules').
1017 A DSA-shared operational attribute is used to represent information of
1018 the DSA Information Model which is shared between DSAs.
1020 A DSA-specific operational attribute is used to represent information
1021 of the DSA Information Model which is specific to the DSA (though, in
1022 some cases, may be derived from information shared between DSAs)
1023 (e.g., 'namingContexts').
1025 The DSA Information Model operational attributes are detailed in
1028 Operational attributes are not normally visible. They are not
1029 returned in search results unless explicitly requested by name.
1031 Not all operational attributes are user modifiable.
1033 Entries may contain, among others, the following operational
1036 - creatorsName: the Distinguished Name of the user who added this
1037 entry to the directory,
1039 - createTimestamp: the time this entry was added to the directory,
1041 - modifiersName: the Distinguished Name of the user who last
1042 modified this entry, and
1044 - modifyTimestamp: the time this entry was last modified.
1046 Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
1047 'modifiersName', and 'modifyTimestamp' attributes for all entries of
1051 3.4.1. 'creatorsName'
1053 This attribute appears in entries which were added using the protocol
1054 (e.g., using the Add operation). The value is the distinguished name
1057 ( 2.5.18.3 NAME 'creatorsName'
1058 EQUALITY distinguishedNameMatch
1059 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1060 SINGLE-VALUE NO-USER-MODIFICATION
1061 USAGE directoryOperation )
1066 Zeilenga LDAP Models [Page 19]
1068 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1071 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1072 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1075 3.4.2. 'createTimestamp'
1077 This attribute appears in entries which were added using the protocol
1078 (e.g., using the Add operation). The value is the time the entry was
1081 ( 2.5.18.1 NAME 'createTimestamp'
1082 EQUALITY generalizedTimeMatch
1083 ORDERING generalizedTimeOrderingMatch
1084 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1085 SINGLE-VALUE NO-USER-MODIFICATION
1086 USAGE directoryOperation )
1088 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1089 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1090 are defined in [Syntaxes].
1093 3.4.3. 'modifiersName'
1095 This attribute appears in entries which have been modified using the
1096 protocol (e.g., using Modify operation). The value is the
1097 distinguished name of the last modifier.
1099 ( 2.5.18.4 NAME 'modifiersName'
1100 EQUALITY distinguishedNameMatch
1101 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1102 SINGLE-VALUE NO-USER-MODIFICATION
1103 USAGE directoryOperation )
1105 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1106 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1109 3.4.4. 'modifyTimestamp'
1111 This attribute appears in entries which have been modified using the
1112 protocol (e.g., using the Modify operation). The value is the time
1113 the entry was last modified.
1115 ( 2.5.18.2 NAME 'modifyTimestamp'
1116 EQUALITY generalizedTimeMatch
1117 ORDERING generalizedTimeOrderingMatch
1118 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1122 Zeilenga LDAP Models [Page 20]
1124 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1127 SINGLE-VALUE NO-USER-MODIFICATION
1128 USAGE directoryOperation )
1130 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
1131 rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
1132 are defined in [Syntaxes].
1135 3.4.5. 'structuralObjectClass'
1137 This attribute indicates the structural object class of the entry.
1139 ( 2.5.21.9 NAME 'structuralObjectClass'
1140 EQUALITY objectIdentifierMatch
1141 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
1142 SINGLE-VALUE NO-USER-MODIFICATION
1143 USAGE directoryOperation )
1145 The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
1146 (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
1149 3.4.6. 'governingStructureRule'
1151 This attribute indicates the structure rule governing the entry.
1153 ( 2.5.21.10 NAME 'governingStructureRule'
1154 EQUALITY integerMatch
1155 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1156 SINGLE-VALUE NO-USER-MODIFICATION
1157 USAGE directoryOperation )
1159 The 'integerMatch' matching rule and INTEGER
1160 (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
1165 As defined in [X.501]:
1167 The Directory Schema is a set of definitions and constraints
1168 concerning the structure of the DIT, the possible ways entries are
1169 named, the information that can be held in an entry, the
1170 attributes used to represent that information and their
1171 organization into hierarchies to facilitate search and retrieval
1172 of the information and the ways in which values of attributes may
1173 be matched in attribute value and matching rule assertions.
1178 Zeilenga LDAP Models [Page 21]
1180 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1183 NOTE 1 - The schema enables the Directory system to, for example:
1185 - prevent the creation of subordinate entries of the wrong
1186 object-class (e.g. a country as a subordinate of a person);
1188 - prevent the addition of attribute-types to an entry
1189 inappropriate to the object-class (e.g. a serial number to a
1192 - prevent the addition of an attribute value of a syntax not
1193 matching that defined for the attribute-type (e.g. a printable
1194 string to a bit string).
1196 Formally, the Directory Schema comprises a set of:
1198 a) Name Form definitions that define primitive naming relations
1199 for structural object classes;
1201 b) DIT Structure Rule definitions that define the names that
1202 entries may have and the ways in which the entries may be
1203 related to one another in the DIT;
1205 c) DIT Content Rule definitions that extend the specification of
1206 allowable attributes for entries beyond those indicated by the
1207 structural object classes of the entries;
1209 d) Object Class definitions that define the basic set of mandatory
1210 and optional attributes that shall be present, and may be
1211 present, respectively, in an entry of a given class, and which
1212 indicate the kind of object class that is being defined;
1214 e) Attribute Type definitions that identify the object identifier
1215 by which an attribute is known, its syntax, associated matching
1216 rules, whether it is an operational attribute and if so its
1217 type, whether it is a collective attribute, whether it is
1218 permitted to have multiple values and whether or not it is
1219 derived from another attribute type;
1221 f) Matching Rule definitions that define matching rules.
1225 g) LDAP Syntax definitions that define encodings used in LDAP.
1228 4.1. Schema Definitions
1230 Schema definitions in this section are described using ABNF and rely
1234 Zeilenga LDAP Models [Page 22]
1236 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1239 on the common productions specified in Section 1.2 as well as these:
1241 noidlen = numericoid [ LCURLY len RCURLY ]
1244 oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
1245 oidlist = oid *( WSP DOLLAR WSP oid )
1247 extensions = *( SP xstring SP qdstrings )
1248 xstring = "X" HYPHEN 1*( UALPHA / HYPHEN / USCORE )
1250 qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
1251 qdescrlist = [ qdescr *( SP qdescr ) ]
1252 qdescr = SQUOTE descr SQUOTE
1254 qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
1255 qdstringlist = [ qdstring *( SP qdstring ) ]
1256 qdstring = SQUOTE dstring SQUOTE
1257 dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
1259 QQ = ESC %x32 %x37 ; "\27"
1260 QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
1262 ; Any UTF-8 encoded Unicode character
1263 ; except %x27 ("'") and %x5C ("\")
1264 QUTF8 = QUTF1 / UTFMB
1266 ; Any ASCII character except %x27 ("'") and %x5C ("\")
1267 QUTF1 = %x00-26 / %x28-5B / %x5D-7F
1269 Schema definitions in this section also share a number of common
1272 The NAME field provides a set of short names (descriptors) which are
1273 be used as aliases for the OID.
1275 The DESC field optionally allows a descriptive string to be provided
1276 by the directory administrator and/or implementor. While
1277 specifications may suggest a descriptive string, there is no
1278 requirement that the suggested (or any) descriptive string be used.
1280 The OBSOLETE field, if present, indicates the element is not active.
1282 Implementors should note that future versions of this document may
1283 expand these definitions to include additional terms. Terms whose
1284 identifier begins with "X-" are reserved for private experiments, and
1285 are followed by <SP> and <qdstrings> tokens.
1290 Zeilenga LDAP Models [Page 23]
1292 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1295 4.1.1. Object Class Definitions
1297 Object Class definitions are written according to the ABNF:
1299 ObjectClassDescription = LPAREN WSP
1300 numericoid ; object identifier
1301 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1302 [ SP "DESC" SP qdstring ] ; description
1303 [ SP "OBSOLETE" ] ; not active
1304 [ SP "SUP" SP oids ] ; superior object classes
1305 [ SP kind ] ; kind of class
1306 [ SP "MUST" SP oids ] ; attribute types
1307 [ SP "MAY" SP oids ] ; attribute types
1308 extensions WSP RPAREN
1310 kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
1313 <numericoid> is object identifier assigned to this object class;
1314 NAME <qdescrs> are short names (descriptors) identifying this object
1316 DESC <qdstring> is a short descriptive string;
1317 OBSOLETE indicates this object class is not active;
1318 SUP <oids> specifies the direct superclasses of this object class;
1319 the kind of object class is indicated by one of ABSTRACT,
1320 STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
1321 MUST and MAY specify the sets of required and allowed attribute
1322 types, respectively; and
1323 <extensions> describe extensions.
1326 4.1.2. Attribute Types
1328 Attribute Type definitions are written according to the ABNF:
1330 AttributeTypeDescription = LPAREN WSP
1331 numericoid ; object identifier
1332 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1333 [ SP "DESC" SP qdstring ] ; description
1334 [ SP "OBSOLETE" ] ; not active
1335 [ SP "SUP" SP oid ] ; supertype
1336 [ SP "EQUALITY" SP oid ] ; equality matching rule
1337 [ SP "ORDERING" SP oid ] ; ordering matching rule
1338 [ SP "SUBSTR" SP oid ] ; substrings matching rule
1339 [ SP "SYNTAX" SP noidlen ] ; value syntax
1340 [ SP "SINGLE-VALUE" ] ; single-value
1341 [ SP "COLLECTIVE" ] ; collective
1342 [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
1346 Zeilenga LDAP Models [Page 24]
1348 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1351 [ SP "USAGE" SP usage ] ; usage
1352 extensions WSP RPAREN ; extensions
1354 usage = "userApplications" / ; user
1355 "directoryOperation" / ; directory operational
1356 "distributedOperation" / ; DSA-shared operational
1357 "dSAOperation" ; DSA-specific operational
1360 <numericoid> is object identifier assigned to this attribute type;
1361 NAME <qdescrs> are short names (descriptors) identifying this
1363 DESC <qdstring> is a short descriptive string;
1364 OBSOLETE indicates this attribute type is not active;
1365 SUP oid specifies the direct supertype of this type;
1366 EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
1367 ordering, and substrings matching rules, respectively;
1368 SYNTAX identifies value syntax by object identifier and may suggest
1369 a minimum upper bound;
1370 COLLECTIVE indicates this attribute type is collective
1372 NO-USER-MODIFICATION indicates this attribute type is not user
1374 USAGE indicates the application of this attribute type; and
1375 <extensions> describe extensions.
1377 Each attribute type description must contain at least one of the SUP
1378 or SYNTAX fields. If no SYNTAX field is provided, the attribute type
1379 description takes its value from the supertype.
1381 If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
1382 fields, if not specified, take their value from the supertype.
1384 Usage of userApplications, the default, indicates that attributes of
1385 this type represent user information. That is, they are user
1388 A usage of directoryOperation, distributedOperation, or dSAOperation
1389 indicates that attributes of this type represent operational and/or
1390 administrative information. That is, they are operational attributes.
1392 directoryOperation usage indicates that the attribute of this type is
1393 a directory operational attribute. distributedOperation usage
1394 indicates that the attribute of this DSA-shared usage operational
1395 attribute. dSAOperation usage indicates that the attribute of this
1396 type is a DSA-specific operational attribute.
1398 COLLECTIVE requires usage userApplications. Use of collective
1402 Zeilenga LDAP Models [Page 25]
1404 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1407 attribute types in LDAP is discussed in [RFC3671].
1409 NO-USER-MODIFICATION requires an operational usage.
1411 Note that the <AttributeTypeDescription> does not list the matching
1412 rules which can be used with that attribute type in an extensibleMatch
1413 search filter [Protocol]. This is done using the 'matchingRuleUse'
1414 attribute described in Section 4.1.4.
1416 This document refines the schema description of X.501 by requiring
1417 that the SYNTAX field in an <AttributeTypeDescription> be a string
1418 representation of an object identifier for the LDAP string syntax
1419 definition with an optional indication of the suggested minimum bound
1420 of a value of this attribute.
1422 A suggested minimum upper bound on the number of characters in a value
1423 with a string-based syntax, or the number of bytes in a value for all
1424 other syntaxes, may be indicated by appending this bound count inside
1425 of curly braces following the syntax's OBJECT IDENTIFIER in an
1426 Attribute Type Description. This bound is not part of the syntax name
1427 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
1428 implementations should allow a string to be 64 characters long,
1429 although they may allow longer strings. Note that a single character
1430 of the Directory String syntax may be encoded in more than one octet
1431 since UTF-8 [RFC3629] is a variable-length encoding.
1434 4.1.3. Matching Rules
1436 Matching rules are used in performance of attribute value assertions,
1437 such as in performance of a Compare operation. They are also used in
1438 evaluation of a Search filters, in determining which individual values
1439 are be added or deleted during performance of a Modify operation, and
1440 used in comparison of distinguished names
1442 Each matching rule is identified by an object identifier (OID) and,
1443 optionally, one or more short names (descriptors).
1445 Matching rule definitions are written according to the ABNF:
1447 MatchingRuleDescription = LPAREN WSP
1448 numericoid ; object identifier
1449 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1450 [ SP "DESC" SP qdstring ] ; description
1451 [ SP "OBSOLETE" ] ; not active
1452 SP "SYNTAX" SP numericoid ; assertion syntax
1453 extensions WSP RPAREN ; extensions
1458 Zeilenga LDAP Models [Page 26]
1460 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1464 <numericoid> is object identifier assigned to this matching rule;
1465 NAME <qdescrs> are short names (descriptors) identifying this
1467 DESC <qdstring> is a short descriptive string;
1468 OBSOLETE indicates this matching rule is not active;
1469 SYNTAX identifies the assertion syntax (the syntax of the assertion
1470 value) by object identifier; and
1471 <extensions> describe extensions.
1474 4.1.4. Matching Rule Uses
1476 A matching rule use lists the attributes which are suitable for use
1477 with an extensibleMatch search filter.
1479 Matching rule use descriptions are written according to the following
1482 MatchingRuleUseDescription = LPAREN WSP
1483 numericoid ; object identifier
1484 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1485 [ SP "DESC" SP qdstring ] ; description
1486 [ SP "OBSOLETE" ] ; not active
1487 SP "APPLIES" SP oids ; attribute types
1488 extensions WSP RPAREN ; extensions
1491 <numericoid> is the object identifier of the matching rule
1492 associated with this matching rule use description;
1493 NAME <qdescrs> are short names (descriptors) identifying this
1495 DESC <qdstring> is a short descriptive string;
1496 OBSOLETE indicates this matching rule use is not active;
1497 APPLIES provides a list of attribute types the matching rule applies
1499 <extensions> describe extensions.
1502 4.1.5. LDAP Syntaxes
1504 LDAP Syntaxes of (attribute and assertion) values are described in
1505 terms of ASN.1 [X.680] and, optionally, have an octet string encoding
1506 known as the LDAP-specific encoding. Commonly, the LDAP-specific
1507 encoding is constrained to string of Unicode [Unicode] characters in
1508 UTF-8 [RFC3629] form.
1510 Each LDAP syntax is identified by an object identifier (OID).
1514 Zeilenga LDAP Models [Page 27]
1516 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1519 LDAP syntax definitions are written according to the ABNF:
1521 SyntaxDescription = LPAREN WSP
1522 numericoid ; object identifier
1523 [ SP "DESC" SP qdstring ] ; description
1524 extensions WSP RPAREN ; extensions
1527 <numericoid> is object identifier assigned to this LDAP syntax;
1528 DESC <qdstring> is a short descriptive string; and
1529 <extensions> describe extensions.
1532 4.1.6. DIT Content Rules
1534 A DIT content rule is a "rule governing the content of entries of a
1535 particular structural object class" [X.501].
1537 For DIT entries of a particular structural object class, a DIT content
1538 rule specifies which auxiliary object classes the entries are allowed
1539 to belong to and which additional attributes (by type) are required,
1540 allowed or not allowed to appear in the entries.
1542 The list of precluded attributes cannot include any attribute listed
1543 as mandatory in rule, the structural object class, or any of the
1544 allowed auxiliary object classes.
1546 Each content rule is identified by the object identifier, as well as
1547 any short names (descriptors), of the structural object class it
1550 An entry may only belong to auxiliary object classes listed in the
1551 governing content rule.
1553 An entry must contain all attributes required by the object classes
1554 the entry belongs to as well as all attributed required by the
1555 governing content rule.
1557 An entry may contain any non-precluded attributes allowed by the
1558 object classes the entry belongs to as well as all attributes allowed
1559 by the governing content rule.
1561 An entry cannot include any attribute precluded by the governing
1564 An entry is governed by (if present and active in the subschema) the
1565 DIT content rule which applies to the structural object class of the
1566 entry (see Section 2.4.2). If no active rule is present for the
1570 Zeilenga LDAP Models [Page 28]
1572 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1575 entry's structural object class, the entry's content is governed by
1576 the structural object class (and possibly other aspects of user and
1577 system schema). DIT content rules for superclasses of the structural
1578 object class of an entry are not applicable to that entry.
1580 DIT content rule descriptions are written according to the ABNF:
1582 DITContentRuleDescription = LPAREN WSP
1583 numericoid ; object identifier
1584 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1585 [ SP "DESC" SP qdstring ] ; description
1586 [ SP "OBSOLETE" ] ; not active
1587 [ SP "AUX" SP oids ] ; auxiliary object classes
1588 [ SP "MUST" SP oids ] ; attribute types
1589 [ SP "MAY" SP oids ] ; attribute types
1590 [ SP "NOT" SP oids ] ; attribute types
1591 extensions WSP RPAREN ; extensions
1594 <numericoid> is the object identifier of the structural object class
1595 associated with this DIT content rule;
1596 NAME <qdescrs> are short names (descriptors) identifying this DIT
1598 DESC <qdstring> is a short descriptive string;
1599 OBSOLETE indicates this DIT content rule use is not active;
1600 AUX specifies a list of auxiliary object classes which entries
1601 subject to this DIT content rule may belong to;
1602 MUST, MAY, and NOT specify lists of attribute types which are
1603 required, allowed, or precluded, respectively, from appearing in
1604 entries subject to this DIT content rule; and
1605 <extensions> describe extensions.
1608 4.1.7. DIT Structure Rules and Name Forms
1610 It is sometimes desirable to regulate where object and alias entries
1611 can be placed in the DIT and how they can be named based upon their
1612 structural object class.
1615 4.1.7.1. DIT Structure Rules
1617 A DIT structure rule is a "rule governing the structure of the DIT by
1618 specifying a permitted superior to subordinate entry relationship. A
1619 structure rule relates a name form, and therefore a structural object
1620 class, to superior structure rules. This permits entries of the
1621 structural object class identified by the name form to exist in the
1622 DIT as subordinates to entries governed by the indicated superior
1626 Zeilenga LDAP Models [Page 29]
1628 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1631 structure rules" [X.501].
1633 DIT structure rule descriptions are written according to the ABNF:
1635 DITStructureRuleDescription = LPAREN WSP
1636 ruleid ; rule identifier
1637 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1638 [ SP "DESC" SP qdstring ] ; description
1639 [ SP "OBSOLETE" ] ; not active
1640 SP "FORM" SP oid ; NameForm
1641 [ SP "SUP" ruleids ] ; superior rules
1642 extensions WSP RPAREN ; extensions
1644 ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
1645 ruleidlist = ruleid *( SP ruleid )
1649 <ruleid> is the rule identifier of this DIT structure rule;
1650 NAME <qdescrs> are short names (descriptors) identifying this DIT
1652 DESC <qdstring> is a short descriptive string;
1653 OBSOLETE indicates this DIT structure rule use is not active;
1654 FORM is specifies the name form associated with this DIT structure
1656 SUP identifies superior rules (by rule id); and
1657 <extensions> describe extensions.
1659 If no superior rules are identified, the DIT structure rule applies
1660 to an autonomous administrative point (e.g. the root vertex of the
1661 subtree controlled by the subschema) [X.501].
1666 A name form "specifies a permissible RDN for entries of a particular
1667 structural object class. A name form identifies a named object
1668 class and one or more attribute types to be used for naming (i.e.
1669 for the RDN). Name forms are primitive pieces of specification
1670 used in the definition of DIT structure rules" [X.501].
1672 Each name form indicates the structural object class to be named,
1673 a set of required attribute types, and a set of allowed attribute
1674 types. A particular attribute type cannot be in both sets.
1676 Entries governed by the form must be named using a value from each
1677 required attribute type and zero or more values from the allowed
1682 Zeilenga LDAP Models [Page 30]
1684 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1687 Each name form is identified by an object identifier (OID) and,
1688 optionally, one or more short names (descriptors).
1690 Name form descriptions are written according to the ABNF:
1692 NameFormDescription = LPAREN WSP
1693 numericoid ; object identifier
1694 [ SP "NAME" SP qdescrs ] ; short names (descriptors)
1695 [ SP "DESC" SP qdstring ] ; description
1696 [ SP "OBSOLETE" ] ; not active
1697 SP "OC" SP oid ; structural object class
1698 SP "MUST" SP oids ; attribute types
1699 [ SP "MAY" SP oids ] ; attribute types
1700 extensions WSP RPAREN ; extensions
1703 <numericoid> is object identifier which identifies this name form;
1704 NAME <qdescrs> are short names (descriptors) identifying this name
1706 DESC <qdstring> is a short descriptive string;
1707 OBSOLETE indicates this name form is not active;
1708 OC identifies the structural object class this rule applies to,
1709 MUST and MAY specify the sets of required and allowed, respectively,
1710 naming attributes for this name form; and
1711 <extensions> describe extensions.
1713 All attribute types in the required ("MUST") and allowed ("MAY") lists
1717 4.2. Subschema Subentries
1719 Subschema (sub)entries are used for administering information about
1720 the directory schema. A single subschema (sub)entry contains all
1721 schema definitions (see Section 4.1) used by entries in a particular
1722 part of the directory tree.
1724 Servers which follow X.500(93) models SHOULD implement subschema using
1725 the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
1726 and so these are not ordinary object entries but subentries (see
1727 Section 3.2). LDAP clients SHOULD NOT assume that servers implement
1728 any of the other aspects of X.500 subschema.
1730 Servers MAY allow subschema modification. Procedures for subschema
1731 modification are discussed in Section 14.5 of [X.501].
1733 A server which masters entries and permits clients to modify these
1734 entries SHALL implement and provide access to these subschema
1738 Zeilenga LDAP Models [Page 31]
1740 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1743 (sub)entries including providing a 'subschemaSubentry' attribute in
1744 each modifiable entry. This so clients may discover the attributes
1745 and object classes which are permitted to be present. It is strongly
1746 RECOMMENDED that all other servers implement this as well.
1748 The value of the 'subschemaSubentry' attribute is the name of the
1749 subschema (sub)entry holding the subschema controlling the entry.
1751 ( 2.5.18.10 NAME 'subschemaSubentry'
1752 EQUALITY distinguishedNameMatch
1753 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1754 NO-USER-MODIFICATION SINGLE-VALUE
1755 USAGE directoryOperation )
1757 The 'distinguishedNameMatch' matching rule and the DistinguishedName
1758 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
1760 Subschema is held in (sub)entries belonging to the subschema auxiliary
1763 ( 2.5.20.1 NAME 'subschema' AUXILIARY
1764 MAY ( dITStructureRules $ nameForms $ ditContentRules $
1765 objectClasses $ attributeTypes $ matchingRules $
1768 The 'ldapSyntaxes' operational attribute may also be present in
1771 Servers MAY provide additional attributes (described in other
1772 documents) in subschema (sub)entries.
1774 Servers SHOULD provide the attributes 'createTimestamp' and
1775 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
1776 to maintain their caches of schema information.
1778 The following subsections provide attribute type definitions for each
1779 of schema definition attribute types.
1782 4.2.1. 'objectClasses'
1784 This attribute holds definitions of object classes.
1786 ( 2.5.21.6 NAME 'objectClasses'
1787 EQUALITY objectIdentifierFirstComponentMatch
1788 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
1789 USAGE directoryOperation )
1794 Zeilenga LDAP Models [Page 32]
1796 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1799 The 'objectIdentifierFirstComponentMatch' matching rule and the
1800 ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
1801 defined in [Syntaxes].
1804 4.2.2. 'attributeTypes'
1806 This attribute holds definitions of attribute types.
1808 ( 2.5.21.5 NAME 'attributeTypes'
1809 EQUALITY objectIdentifierFirstComponentMatch
1810 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
1811 USAGE directoryOperation )
1813 The 'objectIdentifierFirstComponentMatch' matching rule and the
1814 AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
1815 defined in [Syntaxes].
1818 4.2.3. 'matchingRules'
1820 This attribute holds definitions of matching rules.
1822 ( 2.5.21.4 NAME 'matchingRules'
1823 EQUALITY objectIdentifierFirstComponentMatch
1824 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
1825 USAGE directoryOperation )
1827 The 'objectIdentifierFirstComponentMatch' matching rule and the
1828 MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
1829 defined in [Syntaxes].
1832 4.2.4 'matchingRuleUse'
1834 This attribute holds definitions of matching rule uses.
1836 ( 2.5.21.8 NAME 'matchingRuleUse'
1837 EQUALITY objectIdentifierFirstComponentMatch
1838 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
1839 USAGE directoryOperation )
1841 The 'objectIdentifierFirstComponentMatch' matching rule and the
1842 MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
1843 defined in [Syntaxes].
1846 4.2.5. 'ldapSyntaxes'
1850 Zeilenga LDAP Models [Page 33]
1852 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1855 This attribute holds definitions of LDAP syntaxes.
1857 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
1858 EQUALITY objectIdentifierFirstComponentMatch
1859 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
1860 USAGE directoryOperation )
1862 The 'objectIdentifierFirstComponentMatch' matching rule and the
1863 SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
1867 4.2.6. 'dITContentRules'
1869 This attribute lists DIT Content Rules which are present in the
1872 ( 2.5.21.2 NAME 'dITContentRules'
1873 EQUALITY objectIdentifierFirstComponentMatch
1874 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
1875 USAGE directoryOperation )
1877 The 'objectIdentifierFirstComponentMatch' matching rule and the
1878 DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
1879 defined in [Syntaxes].
1882 4.2.7. 'dITStructureRules'
1884 This attribute lists DIT Structure Rules which present in the
1887 ( 2.5.21.1 NAME 'dITStructureRules'
1888 EQUALITY integerFirstComponentMatch
1889 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
1890 USAGE directoryOperation )
1892 The 'integerFirstComponentMatch' matching rule and the
1893 DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
1894 defined in [Syntaxes].
1899 This attribute lists Name Forms which are in force.
1901 ( 2.5.21.7 NAME 'nameForms'
1902 EQUALITY objectIdentifierFirstComponentMatch
1906 Zeilenga LDAP Models [Page 34]
1908 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1911 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
1912 USAGE directoryOperation )
1914 The 'objectIdentifierFirstComponentMatch' matching rule and the
1915 NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
1919 4.3. 'extensibleObject' object class
1921 The 'extensibleObject' auxiliary object class allows entries that
1922 belong to it to hold any user attribute. The set of allowed attribute
1923 types of this object class is implicitly the set of all attribute
1924 types of userApplications usage.
1926 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
1929 The mandatory attributes of the other object classes of this entry are
1930 still required to be present and any precluded attributes are still
1931 not allowed to be present.
1935 4.4. Subschema Discovery
1937 To discover the DN of the subschema (sub)entry holding the subschema
1938 controlling a particular entry, a client reads that entry's
1939 'subschemaSubentry' operational attribute. To read schema attributes
1940 from the subschema (sub)entry, clients MUST issue a Search operation
1941 [Protocol] where baseObject is the DN of the subschema (sub)entry,
1942 scope is baseObject, filter is "(objectClass=subschema)" [Filters],
1943 and attributes field lists the names of the desired schema attributes
1944 (as they are operational). Note: the "(objectClass=subschema)" filter
1945 allows LDAP servers which gateway to X.500 to detect that subentry
1946 information is being requested.
1948 Clients SHOULD NOT assume a published subschema is complete nor assume
1949 the server supports all of the schema elements it publishes nor assume
1950 the server does not support an unpublished element.
1953 5. DSA (Server) Informational Model
1955 The LDAP protocol assumes there are one or more servers which jointly
1956 provide access to a Directory Information Tree (DIT). The server
1957 holding the original information is called the "master" (for that
1958 information). Servers which hold copies of the original information
1962 Zeilenga LDAP Models [Page 35]
1964 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
1967 are referred to as "shadowing" or "caching" servers.
1969 As defined in [X.501]:
1971 context prefix: The sequence of RDNs leading from the Root of the
1972 DIT to the initial vertex of a naming context; corresponds to
1973 the distinguished name of that vertex.
1977 naming context: A subtree of entries held in a single master DSA.
1979 That is, a naming context is the largest collection of entries,
1980 starting at an entry that is mastered by a particular server, and
1981 including all its subordinates and their subordinates, down to the
1982 entries which are mastered by different servers. The context prefix
1983 is the name of the initial entry.
1985 The root of the DIT is a DSA-specific Entry (DSE) and not part of any
1986 naming context (or any subtree); each server has different attribute
1987 values in the root DSE.
1990 5.1. Server-specific Data Requirements
1992 An LDAP server SHALL provide information about itself and other
1993 information that is specific to each server. This is represented as a
1994 group of attributes located in the root DSE, which is named with the
1995 DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
1998 These attributes are retrievable, subject to access control and other
1999 restrictions, if a client performs a Search operation [Protocol] with
2000 an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
2001 [Filters], and with the attributes field listing the names of the
2002 desired attributes. It is noted that root DSE attributes are
2003 operational, and like other operational attributes, are not returned
2004 in search requests unless requested by name.
2006 The root DSE SHALL NOT be included if the client performs a subtree
2007 search starting from the root.
2009 Servers may allow clients to modify attributes of the root DSE where
2012 The following attributes of the root DSE are defined in [Syntaxes].
2013 Additional attributes may be defined in other documents.
2018 Zeilenga LDAP Models [Page 36]
2020 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2023 - altServer: alternative servers;
2025 - namingContexts: naming contexts;
2027 - supportedControl: recognized LDAP controls;
2029 - supportedExtension: recognized LDAP extended operations;
2031 - supportedLDAPVersion: LDAP versions supported; and
2033 - supportedSASLMechanisms: recognized Simple Authentication and
2034 Security Layers (SASL) [SASL] mechanisms.
2036 The values provided for these attributes may depend on
2037 session-specific and other factors. For example, a server supporting
2038 the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
2039 client's identity has been established by a lower level. See
2042 The root DSE may also include a 'subschemaSubentry' attribute. If so,
2043 it refers to the subschema (sub)entry holding the schema controlling
2044 the root DSE. Clients SHOULD NOT assume that this subschema
2045 (sub)entry controls other entries held by the server. General
2046 subschema discovery procedures are provided in Section 4.4.
2051 The 'altServer' attribute lists URIs referring to alternative servers
2052 which may be contacted when this server becomes unavailable. URIs for
2053 servers implementing the LDAP are written according to [LDAPURL].
2054 Other kinds of URIs may be provided. If the server does not know of
2055 any other servers which could be used this attribute will be absent.
2056 Clients may cache this information in case their preferred server
2057 later becomes unavailable.
2059 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
2060 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
2061 USAGE dSAOperation )
2063 The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
2067 5.1.2. 'namingContexts'
2069 The 'namingContexts' attribute lists the context prefixes of the
2070 naming contexts the server masters or shadows (in part or in whole).
2074 Zeilenga LDAP Models [Page 37]
2076 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2079 If the server is a first-level DSA [X.501], it should list (in
2080 addition) an empty string (indicating the root of the DIT). If the
2081 server does not master or shadow any information (e.g. it is an LDAP
2082 gateway to a public X.500 directory) this attribute will be absent.
2083 If the server believes it masters or shadows the entire directory, the
2084 attribute will have a single value, and that value will be the empty
2085 string (indicating the root of the DIT).
2087 This attribute may be used, for example, to select a suitable entry
2088 name for subsequent operations with this server.
2090 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
2091 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2092 USAGE dSAOperation )
2094 The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
2095 defined in [Syntaxes].
2098 5.1.3. 'supportedControl'
2100 The 'supportedControl' attribute lists object identifiers identifying
2101 the request controls [Protocol] the server supports. If the server
2102 does not support any request controls, this attribute will be absent.
2103 Object identifiers identifying response controls need not be listed.
2105 Procedures for registering object identifiers used to discovery of
2106 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2108 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
2109 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2110 USAGE dSAOperation )
2112 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2113 defined in [Syntaxes].
2116 5.1.4. 'supportedExtension'
2118 The 'supportedExtension' attribute lists object identifiers
2119 identifying the extended operations [Protocol] which the server
2120 supports. If the server does not support any extended operations,
2121 this attribute will be absent.
2123 An extended operation generally consists of an extended request and an
2124 extended response but may also include other protocol data units (such
2125 as intermediate responses). The object identifier assigned to the
2126 extended request is used to identify the extended operation. Other
2130 Zeilenga LDAP Models [Page 38]
2132 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2135 object identifiers used in the extended operation need not be listed
2136 as values of this attribute.
2138 Procedures for registering object identifiers used to discovery of
2139 protocol mechanisms are detailed in BCP 64 [BCP64bis].
2141 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
2142 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2143 USAGE dSAOperation )
2145 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2146 defined in [Syntaxes].
2149 5.1.5. 'supportedLDAPVersion'
2151 The 'supportedLDAPVersion' attribute lists the versions of LDAP which
2152 the server supports.
2154 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
2155 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2156 USAGE dSAOperation )
2158 The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
2162 5.1.6. 'supportedSASLMechanisms'
2164 The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
2165 [SASL] which the server recognizes and/or supports [AuthMeth]. The
2166 contents of this attribute may depend on the current session state.
2167 If the server does not support any SASL mechanisms this attribute will
2170 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
2171 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2172 USAGE dSAOperation )
2174 The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
2178 6. Other Considerations
2180 6.1. Preservation of User Information
2182 Syntaxes may be defined which have specific value and/or value form
2186 Zeilenga LDAP Models [Page 39]
2188 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2191 (representation) preservation requirements. For example, a syntax
2192 containing digitally signed data can mandate the server preserve both
2193 the value and form of value presented to ensure signature is not
2196 Where such requirements have not been explicitly stated, servers
2197 SHOULD preserve the value of user information but MAY return the value
2198 in a different form. And where a server is unable (or unwilling) to
2199 preserve the value of user information, the server SHALL ensure that
2200 an equivalent value (per Section 2.3) is returned.
2205 Short names, also known as descriptors, are used as more readable
2206 aliases for object identifiers and are used to identify various schema
2207 elements. However, it is not expected that LDAP implementations with
2208 human user interface would display these short names (nor the object
2209 identifiers they refer to) to the user, but would most likely be
2210 performing translations (such as expressing the short name in one of
2211 the local national languages). For example, the short name "st"
2212 (stateOrProvinceName) might be displayed to a German-speaking user as
2215 The same short name might have different meaning in different
2216 subschemas and, within a particular subschema, the same short name
2217 might refer to different object identifiers each identifying a
2218 different kind of schema element.
2220 Implementations MUST be prepared that the same short name might be
2221 used in a subschema to refer to the different kinds of schema
2222 elements. That is, there might be an object class 'x-fubar' and an
2223 attribute type 'x-fubar' in a subschema.
2225 Implementations MUST be prepared that the same short name might be
2226 used in the different subschemas to refer to the different schema
2227 elements. That is, there might be two matching rules 'x-fubar', each
2228 in different subschemas.
2230 Procedures for registering short names (descriptors) are detailed in
2234 6.3. Cache and Shadowing
2236 Some servers may hold cache or shadow copies of entries, which can be
2237 used to answer search and comparison queries, but will return
2238 referrals or contact other servers if modification operations are
2242 Zeilenga LDAP Models [Page 40]
2244 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2247 requested. Servers that perform shadowing or caching MUST ensure that
2248 they do not violate any access control constraints placed on the data
2249 by the originating server.
2252 7. Implementation Guidelines
2254 7.1 Server Guidelines
2256 Servers MUST recognize all names of attribute types and object classes
2257 defined in this document but, unless stated otherwise, need not
2258 support the associated functionality. Servers SHOULD recognize all
2259 the names of attribute types and object classes defined in Section 3
2260 and 4, respectively, of [Schema].
2262 Servers MUST ensure that entries conform to user and system schema
2263 rules or other data model constraints.
2265 Servers MAY support DIT Content Rules. Servers MAY support DIT
2266 Structure Rules and Name Forms.
2268 Servers MAY support alias entries.
2270 Servers MAY support the 'extensibleObject' object class.
2272 Servers MAY support subentries. If so, they MUST do so in accordance
2273 with [RFC3672]. Servers which do not support subentries SHOULD use
2274 object entries to mimic subentries as detailed in Section 3.2.
2276 Servers MAY implement additional schema elements. Servers SHOULD
2277 provide definitions of all schema elements they support in subschema
2281 7.2 Client Guidelines
2283 In the absence of prior agreements with servers, clients SHOULD NOT
2284 assume that servers support any particular schema elements beyond
2285 those referenced in Section 7.1. The client can retrieve subschema
2286 information as described in Section 4.4.
2288 Clients MUST NOT display nor attempt to decode as ASN.1, a value if
2289 its syntax is not known. Clients MUST NOT assume the LDAP-specific
2290 string encoding is restricted to a UTF-8 encoded string of Unicode
2291 characters or any particular subset of Unicode (such as a printable
2292 subset) unless such restriction is explicitly stated. Clients SHOULD
2293 NOT send attribute values in a request that are not valid according to
2294 the syntax defined for the attributes.
2298 Zeilenga LDAP Models [Page 41]
2300 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2303 8. Security Considerations
2305 Attributes of directory entries are used to provide descriptive
2306 information about the real-world objects they represent, which can be
2307 people, organizations or devices. Most countries have privacy laws
2308 regarding the publication of information about people.
2310 General security considerations for accessing directory information
2311 with LDAP are discussed in [Protocol] and [AuthMeth].
2314 9. IANA Considerations
2316 It is requested that the Internet Assigned Numbers Authority (IANA)
2317 update the LDAP descriptors registry as indicated the following
2320 Subject: Request for LDAP Descriptor Registration Update
2321 Descriptor (short name): see comment
2322 Object Identifier: see comment
2323 Person & email address to contact for further information:
2324 Kurt Zeilenga <kurt@OpenLDAP.org>
2326 Specification: RFC XXXX
2327 Author/Change Controller: IESG
2330 The following descriptors (short names) should be added to
2334 ------------------------ ---- -----------------
2335 governingStructureRule A 2.5.21.10
2336 structuralObjectClass A 2.5.21.5
2338 The following descriptors (short names) should be updated to
2342 ------------------------ ---- -----------------
2344 aliasedObjectName A 2.5.4.1
2345 altServer A 1.3.6.1.4.1.1466.101.120.6
2346 attributeTypes A 2.5.21.5
2347 createTimestamp A 2.5.18.1
2348 creatorsName A 2.5.18.3
2349 dITContentRules A 2.5.21.2
2350 dITStructureRules A 2.5.21.1
2354 Zeilenga LDAP Models [Page 42]
2356 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2359 extensibleObject O 1.3.6.1.4.1.1466.101.120.111
2360 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
2361 matchingRuleUse A 2.5.21.8
2362 matchingRules A 2.5.21.4
2363 modifiersName A 2.5.18.4
2364 modifyTimestamp A 2.5.18.2
2365 nameForms A 2.5.21.7
2366 namingContexts A 1.3.6.1.4.1.1466.101.120.5
2367 objectClass A 2.5.4.0
2368 objectClasses A 2.5.21.6
2369 subschema O 2.5.20.1
2370 subschemaSubentry A 2.5.18.10
2371 supportedControl A 1.3.6.1.4.1.1466.101.120.13
2372 supportedExtension A 1.3.6.1.4.1.1466.101.120.7
2373 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
2374 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
2380 This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
2381 S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
2382 RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
2383 Indexing of Directories (ASID) Working Group. This document is also
2384 based in part on "The Directory: Models" [X.501], a product of the
2385 International Telephone Union (ITU). Additional text was borrowed
2386 from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
2388 This document is a product of the IETF LDAP Revision (LDAPBIS) Working
2392 11. Editor's Address
2395 E-mail: <kurt@openldap.org>
2400 12.1. Normative References
2402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2403 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
2405 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2406 Specifications: ABNF", RFC 2234, November 1997.
2410 Zeilenga LDAP Models [Page 43]
2412 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2415 [RFC3639] Yergeau, F., "UTF-8, a transformation format of ISO
2416 10646", RFC 3639 (also STD 63), November 2003.
2418 [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
2421 [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
2422 3672, December 2003.
2424 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
2425 ietf-ldapbis-bcp64-xx.txt, a work in progress.
2427 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
2428 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
2431 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
2432 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
2434 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
2435 Connection Level Security Mechanisms",
2436 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
2438 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
2439 Representation of Search Filters",
2440 draft-ietf-ldapbis-filter-xx.txt, a work in progress.
2442 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
2443 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
2446 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
2447 draft-ietf-ldapbis-url-xx.txt, a work in progress.
2449 [SASL] Melnikov, A. (Editor), "Simple Authentication and
2450 Security Layer (SASL)",
2451 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
2453 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
2454 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
2456 [Schema] Dally, K. (editor), "LDAP: User Schema",
2457 draft-ietf-ldapbis-user-schema-xx.txt, a work in
2460 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
2461 3.2.0" is defined by "The Unicode Standard, Version 3.0"
2462 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
2466 Zeilenga LDAP Models [Page 44]
2468 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2471 as amended by the "Unicode Standard Annex #27: Unicode
2472 3.1" (http://www.unicode.org/reports/tr27/) and by the
2473 "Unicode Standard Annex #28: Unicode 3.2"
2474 (http://www.unicode.org/reports/tr28/).
2476 [X.500] International Telecommunication Union -
2477 Telecommunication Standardization Sector, "The Directory
2478 -- Overview of concepts, models and services,"
2479 X.500(1993) (also ISO/IEC 9594-1:1994).
2481 [X.501] International Telecommunication Union -
2482 Telecommunication Standardization Sector, "The Directory
2483 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
2485 [X.680] International Telecommunication Union -
2486 Telecommunication Standardization Sector, "Abstract
2487 Syntax Notation One (ASN.1) - Specification of Basic
2488 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
2491 12.2. Informative References
2498 This appendix is non-normative.
2500 This document amounts to nearly a complete rewrite of portions of RFC
2501 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
2502 overall clarity of technical specification. This appendix provides a
2503 summary of substantive changes made to the portions of these documents
2504 incorporated into this document. Readers should consult [Roadmap],
2505 [Protocol], [Syntaxes], and [Schema] for summaries of remaining
2506 portions of these documents.
2509 A.1 Changes to RFC 2251
2511 This document incorporates from RFC 2251 sections 3.2 and 3.4,
2512 portions of Section 4 and 6 as summarized below.
2515 A.1.1 Section 3.2 of RFC 2251
2517 Section 3.2 of RFC 2251 provided a brief introduction to the X.500
2518 data model, as used by LDAP. The previous specification relied on
2522 Zeilenga LDAP Models [Page 45]
2524 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2527 [X.501] but lacked clarity in how X.500 models are adapted for use by
2528 LDAP. This document describes the X.500 data models, as used by LDAP
2529 in greater detail, especially in areas where adaptation is needed.
2531 Section 3.2.1 of RFC 2251 described an attribute as "a type with one
2532 or more associated values." In LDAP, an attribute is better described
2533 as an attribute description, a type with zero or more options, and one
2534 or more associated values.
2536 Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
2537 objectClasses and attributeTypes attributes, yet X.500(93) treats
2538 these attributes as optional. While generally all implementations
2539 that support X.500(93) subschema mechanisms will provide both of these
2540 attributes, it is not absolutely required for interoperability that
2541 all servers do. The mandate was removed for consistency with
2542 X.500(93). The subschema discovery mechanism was also clarified to
2543 indicate that subschema controlling an entry is obtained by reading
2544 the (sub)entry referred to by that entry's 'subschemaSubentry'
2548 A.1.2 Section 3.4 of RFC 2251
2550 Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
2551 This material, with changes, was incorporated in Section 5.1 of this
2556 - Clarify that attributes of the root DSE are subject to "other
2557 restrictions" in addition to access controls.
2559 - Clarify that only recognized extended requests need to be enumerated
2560 'supportedExtension'.
2562 - Clarify that only recognized request controls need to be enumerated
2565 - Clarify that root DSE attributes are operational and, like other
2566 operational attributes, will not be returned in search requests
2567 unless requested by name.
2569 - Clarify that not all root DSE attributes are user modifiable.
2571 - Remove inconsistent text regarding handling of the
2572 'subschemaSubentry' attribute within the root DSE. The previous
2573 specification stated that the 'subschemaSubentry' attribute held in
2574 the root DSE referred to "subschema entries (or subentries) known by
2578 Zeilenga LDAP Models [Page 46]
2580 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2583 this server." This is inconsistent with the attribute intended use
2584 as well as its formal definition as a single valued attribute
2585 [X.501]. It is also noted that a simple (possibly incomplete) list
2586 of subschema (sub)entries is not terrible useful. This document (in
2587 section 5.1) specifies that the 'subschemaSubentry' attribute of the
2588 root DSE refers to the subschema controlling the root DSE. It is
2589 noted that the general subschema discovery mechanism remains
2590 available (see Section 4.4 of this document).
2593 A.1.2 Section 4 of RFC 2251
2595 Portions of Section 4 of RFC 2251 detailing aspects of the information
2596 model used by LDAP were incorporated in this document, including:
2598 - Restriction of distinguished values to attributes whose descriptions
2599 have no options (from Section 4.1.3).
2601 - Data model aspects of Attribute Types (from Section 4.1.4),
2602 Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8),
2603 Matching Rule Identifier (from 4.1.9).
2605 - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
2608 A.1.3 Section 6 of RFC 2251
2610 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
2611 where incorporated into this document.
2614 A.2 Changes to RFC 2252
2616 This document incorporates Sections 4, 5 and 7 from RFC 2252.
2619 A.2.1 Section 4 of RFC 2252
2621 The specification was updated to use Augmented BNF [RFC2234]. The
2622 string representation of an OBJECT IDENTIFIER was tighten to
2623 disallow leading zeros as described in RFC 2252 text.
2625 The <descr> syntax was changed to disallow semicolon (U+003B)
2626 characters to appear to be consistent its natural language
2627 specification "descr is the syntactic representation of an object
2628 descriptor, which consists of letters and digits, starting with a
2629 letter." In a related change, the statement "an
2630 AttributeDescription can be used as the value in a NAME part of an
2634 Zeilenga LDAP Models [Page 47]
2636 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2639 AttributeTypeDescription" was deleted. RFC 2252 provided no
2640 specification of the semantics of attribute options appearing in
2643 RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
2644 over the <numericoid> form. However, <descr> form can be ambiguous.
2645 To address this issue, the imperative was replaced with a statement
2646 (in Section 1.4) that while the <descr> form is generally preferred,
2647 <numericoid> should be used where an unambiguous <descr> is not
2648 available. Additionally, an expanded discussion of descriptor
2649 issues is discussed in Section 6.2 (Short Names).
2651 The ABNF for a quoted string (qdstring) was updated to reflect
2652 support for the escaping mechanism described in 4.3 of RFC 2252.
2655 A.2.2 Section 5 of RFC 2252
2657 Definitions of operational attributes provided in Section 5 of RFC
2658 2252 where incorporated into this document.
2660 The 'namingContexts' description was clarified. A first-level DSA
2661 should publish, in addition to other values, "" indicating the root
2664 The 'altServer' description was clarified. It may hold any URI.
2666 The 'supportedExtension' description was clarified. A server need
2667 only list the OBJECT IDENTIFIERs associated with the extended
2668 requests of the extended operations it recognizes.
2670 The 'supportedControl' description was clarified. A server need
2671 only list the OBJECT IDENTIFIERs associated with the request
2672 controls it recognizes.
2674 Descriptions for the 'structuralObjectClass' and
2675 'governingStructureRule' operational attribute types were added.
2678 A.2.3 Section 7 of RFC 2252
2680 Section 7 of RFC 2252 provides definitions of the 'subschema' and
2681 'extensibleObject' object classes. These definitions where
2682 integrated into Section 4.2 and Section 4.3 of this document,
2683 respectively. Section 7 of RFC 2252 also contained the object class
2684 implementation requirement. This was incorporated into Section 7 of
2690 Zeilenga LDAP Models [Page 48]
2692 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2695 The specification of 'extensibleObject' was clarified of how it
2696 interacts with precluded attributes.
2699 A.3 Changes to RFC 2256
2701 This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2704 Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
2705 attribute type. This was integrated into Section 2.4.1 of this
2706 document. The statement "One of the values is either 'top' or
2707 'alias'" was replaced with statement that one of the values is 'top'
2708 as entries belonging to 'alias' also belong to 'top'.
2710 Section 5.2 of RFC 2256 provided the definition of the
2711 'aliasedObjectName' attribute type. This was integrated into
2712 Section 2.6.2 of this document.
2714 Section 7.1 of RFC 2256 provided the definition of the 'top' object
2715 class. This was integrated into Section 2.4.1 of this document.
2717 Section 7.2 of RFC 2256 provided the definition of the 'alias'
2718 object class. This was integrated into Section 2.6.1 of this
2723 Intellectual Property Rights
2725 The IETF takes no position regarding the validity or scope of any
2726 intellectual property or other rights that might be claimed to pertain
2727 to the implementation or use of the technology described in this
2728 document or the extent to which any license under such rights might or
2729 might not be available; neither does it represent that it has made any
2730 effort to identify any such rights. Information on the IETF's
2731 procedures with respect to rights in standards-track and
2732 standards-related documentation can be found in BCP-11. Copies of
2733 claims of rights made available for publication and any assurances of
2734 licenses to be made available, or the result of an attempt made to
2735 obtain a general license or permission for the use of such proprietary
2736 rights by implementors or users of this specification can be obtained
2737 from the IETF Secretariat.
2739 The IETF invites any interested party to bring to its attention any
2740 copyrights, patents or patent applications, or other proprietary
2741 rights which may cover technology that may be required to practice
2742 this standard. Please address the information to the IETF Executive
2746 Zeilenga LDAP Models [Page 49]
2748 INTERNET-DRAFT draft-ietf-ldapbis-models-10 15 February 2004
2757 Copyright (C) The Internet Society (2004). All Rights Reserved.
2759 This document and translations of it may be copied and furnished to
2760 others, and derivative works that comment on or otherwise explain it
2761 or assist in its implementation may be prepared, copied, published and
2762 distributed, in whole or in part, without restriction of any kind,
2763 provided that the above copyright notice and this paragraph are
2764 included on all such copies and derivative works. However, this
2765 document itself may not be modified in any way, such as by removing
2766 the copyright notice or references to the Internet Society or other
2767 Internet organizations, except as needed for the purpose of
2768 developing Internet standards in which case the procedures for
2769 copyrights defined in the Internet Standards process must be followed,
2770 or as required to translate it into languages other than English.
2802 Zeilenga LDAP Models [Page 50]
projects / openldap / blob