]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4512.txt
Fix prev commit
[openldap] / doc / rfc / rfc4512.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4512                           OpenLDAP Foundation
9 Obsoletes: 2251, 2252, 2256, 3674                              June 2006
10 Category: Standards Track
11
12
13              Lightweight Directory Access Protocol (LDAP):
14                       Directory Information Models
15
16 Status of This Memo
17
18    This document specifies an Internet standards track protocol for the
19    Internet community, and requests discussion and suggestions for
20    improvements.  Please refer to the current edition of the "Internet
21    Official Protocol Standards" (STD 1) for the standardization state
22    and status of this protocol.  Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26    Copyright (C) The Internet Society (2006).
27
28 Abstract
29
30    The Lightweight Directory Access Protocol (LDAP) is an Internet
31    protocol for accessing distributed directory services that act in
32    accordance with X.500 data and service models.  This document
33    describes the X.500 Directory Information Models, as used in LDAP.
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Zeilenga                    Standards Track                     [Page 1]
59 \f
60 RFC 4512                      LDAP Models                      June 2006
61
62
63 Table of Contents
64
65    1. Introduction ....................................................3
66       1.1. Relationship to Other LDAP Specifications ..................3
67       1.2. Relationship to X.501 ......................................4
68       1.3. Conventions ................................................4
69       1.4. Common ABNF Productions ....................................4
70    2. Model of Directory User Information .............................6
71       2.1. The Directory Information Tree .............................7
72       2.2. Structure of an Entry ......................................7
73       2.3. Naming of Entries ..........................................8
74       2.4. Object Classes .............................................9
75       2.5. Attribute Descriptions ....................................12
76       2.6. Alias Entries .............................................16
77    3. Directory Administrative and Operational Information ...........17
78       3.1. Subtrees ..................................................17
79       3.2. Subentries ................................................18
80       3.3. The 'objectClass' attribute ...............................18
81       3.4. Operational Attributes ....................................19
82    4. Directory Schema ...............................................22
83       4.1. Schema Definitions ........................................23
84       4.2. Subschema Subentries ......................................32
85       4.3. 'extensibleObject' object class ...........................35
86       4.4. Subschema Discovery .......................................35
87    5. DSA (Server) Informational Model ...............................36
88       5.1. Server-Specific Data Requirements .........................36
89    6. Other Considerations ...........................................40
90       6.1. Preservation of User Information ..........................40
91       6.2. Short Names ...............................................41
92       6.3. Cache and Shadowing .......................................41
93    7. Implementation Guidelines ......................................42
94       7.1. Server Guidelines .........................................42
95       7.2. Client Guidelines .........................................42
96    8. Security Considerations ........................................43
97    9. IANA Considerations ............................................43
98    10. Acknowledgements ..............................................44
99    11. Normative References ..........................................45
100    Appendix A. Changes ...............................................47
101       A.1. Changes to RFC 2251 .......................................47
102       A.2. Changes to RFC 2252 .......................................49
103       A.3. Changes to RFC 2256 .......................................50
104       A.4. Changes to RFC 3674 .......................................51
105
106
107
108
109
110
111
112
113
114 Zeilenga                    Standards Track                     [Page 2]
115 \f
116 RFC 4512                      LDAP Models                      June 2006
117
118
119 1.  Introduction
120
121    This document discusses the X.500 Directory Information Models
122    [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
123    [RFC4510].
124
125    The Directory is "a collection of open systems cooperating to provide
126    directory services" [X.500].  The information held in the Directory
127    is 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
132    fragment of the DIB.
133
134    The DIB contains two classes of information:
135
136       1) user information (e.g., information provided and administrated
137          by users).  Section 2 describes the Model of User Information.
138
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
142          Information.
143
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
147    models.  Section 4 discusses the subschema information model and
148    subschema discovery.  Section 5 discusses the DSA (Server)
149    Informational Model.
150
151    Other X.500 information models (such as access control distribution
152    knowledge and replication knowledge information models) may be
153    adapted for use in LDAP.  Specification of how these models apply to
154    LDAP is left to future documents.
155
156 1.1.  Relationship to Other LDAP Specifications
157
158    This document is a integral part of the LDAP technical specification
159    [RFC4510], which obsoletes the previously defined LDAP technical
160    specification, RFC 3377, in its entirety.
161
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 summarizes changes to
164    these sections.  The remainder of RFC 2251 is obsoleted by the
165    [RFC4511], [RFC4513], and [RFC4510] documents.
166
167
168
169
170 Zeilenga                    Standards Track                     [Page 3]
171 \f
172 RFC 4512                      LDAP Models                      June 2006
173
174
175    This document obsoletes RFC 2252, Sections 4, 5, and 7.  Appendix A.2
176    summarizes changes to these sections.  The remainder of RFC 2252 is
177    obsoleted by [RFC4517].
178
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 [RFC4519] and [RFC4517].
182
183    This document obsoletes RFC 3674 in its entirety.  Appendix A.4
184    summarizes changes since RFC 3674.
185
186 1.2.  Relationship to X.501
187
188    This document includes material, with and without adaptation, from
189    [X.501] as necessary to describe this protocol.  These adaptations
190    (and any other differences herein) apply to this protocol, and only
191    this protocol.
192
193 1.3.  Conventions
194
195    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
197    document are to be interpreted as described in BCP 14 [RFC2119].
198
199    Schema definitions are provided using LDAP description formats (as
200    defined in Section 4.1).  Definitions provided here are formatted
201    (line wrapped) for readability.  Matching rules and LDAP syntaxes
202    referenced in these definitions are specified in [RFC4517].
203
204 1.4.  Common ABNF Productions
205
206    A number of syntaxes in this document are described using Augmented
207    Backus-Naur Form (ABNF) [RFC4234].  These syntaxes (as well as a
208    number of syntaxes defined in other documents) rely on the following
209    common productions:
210
211       keystring = leadkeychar *keychar
212       leadkeychar = ALPHA
213       keychar = ALPHA / DIGIT / HYPHEN
214       number  = DIGIT / ( LDIGIT 1*DIGIT )
215
216       ALPHA   = %x41-5A / %x61-7A   ; "A"-"Z" / "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"
220
221       SP      = 1*SPACE  ; one or more " "
222       WSP     = 0*SPACE  ; zero or more " "
223
224
225
226 Zeilenga                    Standards Track                     [Page 4]
227 \f
228 RFC 4512                      LDAP Models                      June 2006
229
230
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 "}"
251
252       ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
253       UTF8    = UTF1 / UTFMB
254       UTFMB   = UTF2 / UTF3 / UTF4
255       UTF0    = %x80-BF
256       UTF1    = %x00-7F
257       UTF2    = %xC2-DF UTF0
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) /
261                 %xF4 %x80-8F 2(UTF0)
262
263       OCTET   = %x00-FF ; Any octet (8-bit data unit)
264
265    Object identifiers (OIDs) [X.680] are represented in LDAP using a
266    dot-decimal format conforming to the ABNF:
267
268       numericoid = number 1*( DOT number )
269
270    Short names, also known as descriptors, are used as more readable
271    aliases for object identifiers.  Short names are case insensitive and
272    conform to the ABNF:
273
274       descr = keystring
275
276
277
278
279
280
281
282 Zeilenga                    Standards Track                     [Page 5]
283 \f
284 RFC 4512                      LDAP Models                      June 2006
285
286
287    Where either an object identifier or a short name may be specified,
288    the following production is used:
289
290       oid = descr / numericoid
291
292    While the <descr> form is generally preferred when the usage is
293    restricted to short names referring to object identifiers that
294    identify like kinds of objects (e.g., attribute type descriptions,
295    matching rule descriptions, object class descriptions), the
296    <numericoid> form should be used when the object identifiers may
297    identify multiple kinds of objects or when an unambiguous short name
298    (descriptor) is not available.
299
300    Implementations SHOULD treat short names (descriptors) used in an
301    ambiguous manner (as discussed above) as unrecognized.
302
303    Short Names (descriptors) are discussed further in Section 6.2.
304
305 2.  Model of Directory User Information
306
307    As [X.501] states:
308
309       The purpose of the Directory is to hold, and provide access to,
310       information about objects of interest (objects) in some 'world'.
311       An object can be anything which is identifiable (can be named).
312
313       An object class is an identified family of objects, or conceivable
314       objects, which share certain characteristics.  Every object
315       belongs to at least one class.  An object class may be a subclass
316       of other object classes, in which case the members of the former
317       class, the subclass, are also considered to be members of the
318       latter classes, the superclasses.  There may be subclasses of
319       subclasses, etc., to an arbitrary depth.
320
321    A directory entry, a named collection of information, is the basic
322    unit of information held in the Directory.  There are multiple kinds
323    of directory entries.
324
325    An object entry represents a particular object.  An alias entry
326    provides alternative naming.  A subentry holds administrative and/or
327    operational information.
328
329    The set of entries representing the DIB are organized hierarchically
330    in a tree structure known as the Directory Information Tree (DIT).
331
332    Section 2.1 describes the Directory Information Tree.
333    Section 2.2 discusses the structure of entries.
334    Section 2.3 discusses naming of entries.
335
336
337
338 Zeilenga                    Standards Track                     [Page 6]
339 \f
340 RFC 4512                      LDAP Models                      June 2006
341
342
343    Section 2.4 discusses object classes.
344    Section 2.5 discusses attribute descriptions.
345    Section 2.6 discusses alias entries.
346
347 2.1.  The Directory Information Tree
348
349    As noted above, the DIB is composed of a set of entries organized
350    hierarchically in a tree structure known as the Directory Information
351    Tree (DIT); specifically, a tree where vertices are the entries.
352
353    The arcs between vertices define relations between entries.  If an
354    arc exists from X to Y, then the entry at X is the immediate superior
355    of Y, and Y is the immediate subordinate of X.  An entry's superiors
356    are the entry's immediate superior and its superiors.  An entry's
357    subordinates are all of its immediate subordinates and their
358    subordinates.
359
360    Similarly, the superior/subordinate relationship between object
361    entries can be used to derive a relation between the objects they
362    represent.  DIT structure rules can be used to govern relationships
363    between objects.
364
365    Note: An entry's immediate superior is also known as the entry's
366          parent, and an entry's immediate subordinate is also known as
367          the entry's child.  Entries that have the same parent are known
368          as siblings.
369
370 2.2.  Structure of an Entry
371
372    An entry consists of a set of attributes that hold information about
373    the object that the entry represents.  Some attributes represent user
374    information and are called user attributes.  Other attributes
375    represent operational and/or administrative information and are
376    called operational attributes.
377
378    An attribute is an attribute description (a type and zero or more
379    options) with one or more associated values.  An attribute is often
380    referred to by its attribute description.  For example, the
381    'givenName' attribute is the attribute that consists of the attribute
382    description 'givenName' (the 'givenName' attribute type [RFC4519] and
383    zero options) and one or more associated values.
384
385    The attribute type governs whether the attribute can have multiple
386    values, the syntax and matching rules used to construct and compare
387    values of that attribute, and other functions.  Options indicate
388    subtypes and other functions.
389
390    Attribute values conform to the defined syntax of the attribute type.
391
392
393
394 Zeilenga                    Standards Track                     [Page 7]
395 \f
396 RFC 4512                      LDAP Models                      June 2006
397
398
399    No two values of an attribute may be equivalent.  Two values are
400    considered equivalent if and only if they would match according to
401    the equality matching rule of the attribute type.  Or, if the
402    attribute type is defined with no equality matching rule, two values
403    are equivalent if and only if they are identical.  (See 2.5.1 for
404    other restrictions.)
405
406    For example, a 'givenName' attribute can have more than one value,
407    they must be Directory Strings, and they are case insensitive.  A
408    'givenName' attribute cannot hold both "John" and "JOHN", as these
409    are equivalent values per the equality matching rule of the attribute
410    type.
411
412    Additionally, no attribute is to have a value that is not equivalent
413    to itself.  For example, the 'givenName' attribute cannot have as a
414    value a directory string that includes the REPLACEMENT CHARACTER
415    (U+FFFD) code point, as matching involving that directory string is
416    Undefined per this attribute's equality matching rule.
417
418    When an attribute is used for naming of the entry, one and only one
419    value of the attribute is used in forming the Relative Distinguished
420    Name.  This value is known as a distinguished value.
421
422 2.3.  Naming of Entries
423
424 2.3.1.  Relative Distinguished Names
425
426    Each entry is named relative to its immediate superior.  This
427    relative name, known as its Relative Distinguished Name (RDN)
428    [X.501], is composed of an unordered set of one or more attribute
429    value assertions (AVA) consisting of an attribute description with
430    zero options and an attribute value.  These AVAs are chosen to match
431    attribute values (each a distinguished value) of the entry.
432
433    An entry's relative distinguished name must be unique among all
434    immediate subordinates of the entry's immediate superior (i.e., all
435    siblings).
436
437    The following are examples of string representations of RDNs
438    [RFC4514]:
439
440       UID=12345
441       OU=Engineering
442       CN=Kurt Zeilenga+L=Redwood Shores
443
444    The last is an example of a multi-valued RDN; that is, an RDN
445    composed of multiple AVAs.
446
447
448
449
450 Zeilenga                    Standards Track                     [Page 8]
451 \f
452 RFC 4512                      LDAP Models                      June 2006
453
454
455 2.3.2.  Distinguished Names
456
457    An entry's fully qualified name, known as its Distinguished Name (DN)
458    [X.501], is the concatenation of its RDN and its immediate superior's
459    DN.  A Distinguished Name unambiguously refers to an entry in the
460    tree.  The following are examples of string representations of DNs
461    [RFC4514]:
462
463       UID=nobody@example.com,DC=example,DC=com
464       CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
465
466 2.3.3.  Alias Names
467
468    An alias, or alias name, is "an name for an object, provided by the
469    use of alias entries" [X.501].  Alias entries are described in
470    Section 2.6.
471
472 2.4.  Object Classes
473
474    An object class is "an identified family of objects (or conceivable
475    objects) that share certain characteristics" [X.501].
476
477    As defined in [X.501]:
478
479       Object classes are used in the Directory for a number of purposes:
480
481         - describing and categorizing objects and the entries that
482           correspond to these objects;
483
484         - where appropriate, controlling the operation of the Directory;
485
486         - regulating, in conjunction with DIT structure rule
487           specifications, the position of entries in the DIT;
488
489         - regulating, in conjunction with DIT content rule
490           specifications, the attributes that are contained in entries;
491
492         - identifying classes of entry that are to be associated with a
493           particular policy by the appropriate administrative authority.
494
495       An object class (a subclass) may be derived from an object class
496       (its direct superclass) which is itself derived from an even more
497       generic object class.  For structural object classes, this process
498       stops at the most generic object class, 'top' (defined in Section
499       2.4.1).  An ordered set of superclasses up to the most superior
500       object class of an object class is its superclass chain.
501
502
503
504
505
506 Zeilenga                    Standards Track                     [Page 9]
507 \f
508 RFC 4512                      LDAP Models                      June 2006
509
510
511       An object class may be derived from two or more direct
512       superclasses (superclasses not part of the same superclass chain).
513       This feature of subclassing is termed multiple inheritance.
514
515    Each object class identifies the set of attributes required to be
516    present in entries belonging to the class and the set of attributes
517    allowed to be present in entries belonging to the class.  As an entry
518    of a class must meet the requirements of each class it belongs to, it
519    can be said that an object class inherits the sets of allowed and
520    required attributes from its superclasses.  A subclass can identify
521    an attribute allowed by its superclass as being required.  If an
522    attribute is a member of both sets, it is required to be present.
523
524    Each object class is defined to be one of three kinds of object
525    classes: Abstract, Structural, or Auxiliary.
526
527    Each object class is identified by an object identifier (OID) and,
528    optionally, one or more short names (descriptors).
529
530 2.4.1.  Abstract Object Classes
531
532    An abstract object class, as the name implies, provides a base of
533    characteristics from which other object classes can be defined to
534    inherit from.  An entry cannot belong to an abstract object class
535    unless it belongs to a structural or auxiliary class that inherits
536    from that abstract class.
537
538    Abstract object classes cannot derive from structural or auxiliary
539    object classes.
540
541    All structural object classes derive (directly or indirectly) from
542    the 'top' abstract object class.  Auxiliary object classes do not
543    necessarily derive from 'top'.
544
545    The following is the object class definition (see Section 4.1.1) for
546    the 'top' object class:
547
548       ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
549
550    All entries belong to the 'top' abstract object class.
551
552
553
554
555
556
557
558
559
560
561
562 Zeilenga                    Standards Track                    [Page 10]
563 \f
564 RFC 4512                      LDAP Models                      June 2006
565
566
567 2.4.2.  Structural Object Classes
568
569    As stated in [X.501]:
570
571       An object class defined for use in the structural specification of
572       the DIT is termed a structural object class.  Structural object
573       classes are used in the definition of the structure of the names
574       of the objects for compliant entries.
575
576       An object or alias entry is characterized by precisely one
577       structural object class superclass chain which has a single
578       structural object class as the most subordinate object class.
579       This structural object class is referred to as the structural
580       object class of the entry.
581
582       Structural object classes are related to associated entries:
583
584         - an entry conforming to a structural object class shall
585           represent the real-world object constrained by the object
586           class;
587
588         - DIT structure rules only refer to structural object classes;
589           the structural object class of an entry is used to specify the
590           position of the entry in the DIT;
591
592         - the structural object class of an entry is used, along with an
593           associated DIT content rule, to control the content of an
594           entry.
595
596       The structural object class of an entry shall not be changed.
597
598    Each structural object class is a (direct or indirect) subclass of
599    the 'top' abstract object class.
600
601    Structural object classes cannot subclass auxiliary object classes.
602
603    Each entry is said to belong to its structural object class as well
604    as all classes in its structural object class's superclass chain.
605
606 2.4.3.  Auxiliary Object Classes
607
608    Auxiliary object classes are used to augment the characteristics of
609    entries.  They are commonly used to augment the sets of attributes
610    required and allowed to be present in an entry.  They can be used to
611    describe entries or classes of entries.
612
613    Auxiliary object classes cannot subclass structural object classes.
614
615
616
617
618 Zeilenga                    Standards Track                    [Page 11]
619 \f
620 RFC 4512                      LDAP Models                      June 2006
621
622
623    An entry can belong to any subset of the set of auxiliary object
624    classes allowed by the DIT content rule associated with the
625    structural object class of the entry.  If no DIT content rule is
626    associated with the structural object class of the entry, the entry
627    cannot belong to any auxiliary object class.
628
629    The set of auxiliary object classes that an entry belongs to can
630    change over time.
631
632 2.5.  Attribute Descriptions
633
634    An attribute description is composed of an attribute type (see
635    Section 2.5.1) and a set of zero or more attribute options (see
636    Section 2.5.2).
637
638    An attribute description is represented by the ABNF:
639
640       attributedescription = attributetype options
641       attributetype = oid
642       options = *( SEMI option )
643       option = 1*keychar
644
645    where <attributetype> identifies the attribute type and each <option>
646    identifies an attribute option.  Both <attributetype> and <option>
647    productions are case insensitive.  The order in which <option>s
648    appear is irrelevant.  That is, any two <attributedescription>s that
649    consist of the same <attributetype> and same set of <option>s are
650    equivalent.
651
652    Examples of valid attribute descriptions:
653
654       2.5.4.0
655       cn;lang-de;lang-en
656       owner
657
658    An attribute description with an unrecognized attribute type is to be
659    treated as unrecognized.  Servers SHALL treat an attribute
660    description with an unrecognized attribute option as unrecognized.
661    Clients MAY treat an unrecognized attribute option as a tagging
662    option (see Section 2.5.2.1).
663
664    All attributes of an entry must have distinct attribute descriptions.
665
666 2.5.1.  Attribute Types
667
668    An attribute type governs whether the attribute can have multiple
669    values, the syntax and matching rules used to construct and compare
670    values of that attribute, and other functions.
671
672
673
674 Zeilenga                    Standards Track                    [Page 12]
675 \f
676 RFC 4512                      LDAP Models                      June 2006
677
678
679    If no equality matching is specified for the attribute type:
680
681       - the attribute (of the type) cannot be used for naming;
682       - when adding the attribute (or replacing all values), no two
683         values may be equivalent (see 2.2);
684       - individual values of a multi-valued attribute are not to be
685         independently added or deleted;
686       - attribute value assertions (such as matching in search filters
687         and comparisons) using values of such a type cannot be
688         performed.
689
690    Otherwise, the specified equality matching rule is to be used to
691    evaluate attribute value assertions concerning the attribute type.
692    The specified equality rule is to be transitive and commutative.
693
694    The attribute type indicates whether the attribute is a user
695    attribute or an operational attribute.  If operational, the attribute
696    type indicates the operational usage and whether or not the attribute
697    is modifiable by users.  Operational attributes are discussed in
698    Section 3.4.
699
700    An attribute type (a subtype) may derive from a more generic
701    attribute type (a direct supertype).  The following restrictions
702    apply to subtyping:
703
704       - a subtype must have the same usage as its direct supertype,
705       - a subtype's syntax must be the same, or a refinement of, its
706         supertype's syntax, and
707       - a subtype must be collective [RFC3671] if its supertype is
708         collective.
709
710    An attribute description consisting of a subtype and no options is
711    said to be the direct description subtype of the attribute
712    description consisting of the subtype's direct supertype and no
713    options.
714
715    Each attribute type is identified by an object identifier (OID) and,
716    optionally, one or more short names (descriptors).
717
718 2.5.2.  Attribute Options
719
720    There are multiple kinds of attribute description options.  The LDAP
721    technical specification details one kind: tagging options.
722
723    Not all options can be associated with attributes held in the
724    directory.  Tagging options can be.
725
726
727
728
729
730 Zeilenga                    Standards Track                    [Page 13]
731 \f
732 RFC 4512                      LDAP Models                      June 2006
733
734
735    Not all options can be used in conjunction with all attribute types.
736    In such cases, the attribute description is to be treated as
737    unrecognized.
738
739    An attribute description that contains mutually exclusive options
740    shall be treated as unrecognized.  That is, "cn;x-bar;x-foo", where
741    "x-foo" and "x-bar" are mutually exclusive, is to be treated as
742    unrecognized.
743
744    Other kinds of options may be specified in future documents.  These
745    documents must detail how new kinds of options they define relate to
746    tagging options.  In particular, these documents must detail whether
747    or not new kinds of options can be associated with attributes held in
748    the directory, how new kinds of options affect transfer of attribute
749    values, and how new kinds of options are treated in attribute
750    description hierarchies.
751
752    Options are represented as short, case-insensitive textual strings
753    conforming to the <option> production defined in Section 2.5 of this
754    document.
755
756    Procedures for registering options are detailed in BCP 64, RFC 4520
757    [RFC4520].
758
759 2.5.2.1.  Tagging Options
760
761    Attributes held in the directory can have attribute descriptions with
762    any number of tagging options.  Tagging options are never mutually
763    exclusive.
764
765    An attribute description with N tagging options is a direct
766    (description) subtype of all attribute descriptions of the same
767    attribute type and all but one of the N options.  If the attribute
768    type has a supertype, then the attribute description is also a direct
769    (description) subtype of the attribute description of the supertype
770    and the N tagging options.  That is, 'cn;lang-de;lang-en' is a direct
771    (description) subtype of 'cn;lang-de', 'cn;lang-en', and
772    'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
773    in [RFC4519]).
774
775 2.5.3.  Attribute Description Hierarchies
776
777    An attribute description can be the direct subtype of zero or more
778    other attribute descriptions as indicated by attribute type subtyping
779    (as described in Section 2.5.1) or attribute tagging option subtyping
780    (as described in Section 2.5.2.1).  These subtyping relationships are
781    used to form hierarchies of attribute descriptions and attributes.
782
783
784
785
786 Zeilenga                    Standards Track                    [Page 14]
787 \f
788 RFC 4512                      LDAP Models                      June 2006
789
790
791    As adapted from [X.501]:
792
793       Attribute hierarchies allow access to the DIB with varying degrees
794       of granularity.  This is achieved by allowing the value components
795       of attributes to be accessed by using either their specific
796       attribute description (a direct reference to the attribute) or a
797       more generic attribute description (an indirect reference).
798
799       Semantically related attributes may be placed in a hierarchical
800       relationship, the more specialized being placed subordinate to the
801       more generalized.  Searching for or retrieving attributes and
802       their values is made easier by quoting the more generalized
803       attribute description; a filter item so specified is evaluated for
804       the more specialized descriptions as well as for the quoted
805       description.
806
807       Where subordinate specialized descriptions are selected to be
808       returned as part of a search result these descriptions shall be
809       returned if available.  Where the more general descriptions are
810       selected to be returned as part of a search result both the
811       general and the specialized descriptions shall be returned, if
812       available.  An attribute value shall always be returned as a value
813       of its own attribute description.
814
815       All of the attribute descriptions in an attribute hierarchy are
816       treated as distinct and unrelated descriptions for user
817       modification of entry content.
818
819       An attribute value stored in an object or alias entry is of
820       precisely one attribute description.  The description is indicated
821       when the value is originally added to the entry.
822
823    For the purpose of subschema administration of the entry, a
824    specification that an attribute is required is fulfilled if the entry
825    contains a value of an attribute description belonging to an
826    attribute hierarchy where the attribute type of that description is
827    the same as the required attribute's type.  That is, a "MUST name"
828    specification is fulfilled by 'name' or 'name;x-tag-option', but is
829    not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
830    subtype of 'name').  Likewise, an entry may contain a value of an
831    attribute description belonging to an attribute hierarchy where the
832    attribute type of that description is either explicitly included in
833    the definition of an object class to which the entry belongs or
834    allowed by the DIT content rule applicable to that entry.  That is,
835    'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
836    name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
837    (or by "MUST name").
838
839
840
841
842 Zeilenga                    Standards Track                    [Page 15]
843 \f
844 RFC 4512                      LDAP Models                      June 2006
845
846
847    For the purposes of other policy administration, unless stated
848    otherwise in the specification of the particular administrative
849    model, all of the attribute descriptions in an attribute hierarchy
850    are treated as distinct and unrelated descriptions.
851
852 2.6.  Alias Entries
853
854    As adapted from [X.501]:
855
856       An alias, or an alias name, for an object is an alternative name
857       for an object or object entry which is provided by the use of
858       alias entries.
859
860       Each alias entry contains, within the 'aliasedObjectName'
861       attribute (known as the 'aliasedEntryName' attribute in X.500), a
862       name of some object.  The distinguished name of the alias entry is
863       thus also a name for this object.
864
865           NOTE - The name within the 'aliasedObjectName' is said to be
866                  pointed to by the alias.  It does not have to be the
867                  distinguished name of any entry.
868
869       The conversion of an alias name to an object name is termed
870       (alias) dereferencing and comprises the systematic replacement of
871       alias names, where found within a purported name, by the value of
872       the corresponding 'aliasedObjectName' attribute.  The process may
873       require the examination of more than one alias entry.
874
875       Any particular entry in the DIT may have zero or more alias names.
876       It therefore follows that several alias entries may point to the
877       same entry.  An alias entry may point to an entry that is not a
878       leaf entry and may point to another alias entry.
879
880       An alias entry shall have no subordinates, so that an alias entry
881       is always a leaf entry.
882
883       Every alias entry shall belong to the 'alias' object class.
884
885    An entry with the 'alias' object class must also belong to an object
886    class (or classes), or be governed by a DIT content rule, which
887    allows suitable naming attributes to be present.
888
889    Example:
890
891       dn: cn=bar,dc=example,dc=com
892       objectClass: top
893       objectClass: alias
894       objectClass: extensibleObject
895
896
897
898 Zeilenga                    Standards Track                    [Page 16]
899 \f
900 RFC 4512                      LDAP Models                      June 2006
901
902
903       cn: bar
904       aliasedObjectName: cn=foo,dc=example,dc=com
905
906 2.6.1.  'alias' Object Class
907
908    Alias entries belong to the 'alias' object class.
909
910       ( 2.5.6.1 NAME 'alias'
911         SUP top STRUCTURAL
912         MUST aliasedObjectName )
913
914 2.6.2.  'aliasedObjectName' Attribute Type
915
916    The 'aliasedObjectName' attribute holds the name of the entry an
917    alias points to.  The 'aliasedObjectName' attribute is known as the
918    'aliasedEntryName' attribute in X.500.
919
920       ( 2.5.4.1 NAME 'aliasedObjectName'
921         EQUALITY distinguishedNameMatch
922         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
923         SINGLE-VALUE )
924
925    The 'distinguishedNameMatch' matching rule and the DistinguishedName
926    (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
927
928 3.  Directory Administrative and Operational Information
929
930    This section discusses select aspects of the X.500 Directory
931    Administrative and Operational Information model [X.501].  LDAP
932    implementations MAY support other aspects of this model.
933
934 3.1.  Subtrees
935
936    As defined in [X.501]:
937
938       A subtree is a collection of object and alias entries situated at
939       the vertices of a tree.  Subtrees do not contain subentries.  The
940       prefix sub, in subtree, emphasizes that the base (or root) vertex
941       of this tree is usually subordinate to the root of the DIT.
942
943       A subtree begins at some vertex and extends to some identifiable
944       lower boundary, possibly extending to leaves.  A subtree is always
945       defined within a context which implicitly bounds the subtree.  For
946       example, the vertex and lower boundaries of a subtree defining a
947       replicated area are bounded by a naming context.
948
949
950
951
952
953
954 Zeilenga                    Standards Track                    [Page 17]
955 \f
956 RFC 4512                      LDAP Models                      June 2006
957
958
959 3.2.  Subentries
960
961    A subentry is a "special sort of entry, known by the Directory, used
962    to hold information associated with a subtree or subtree refinement"
963    [X.501].  Subentries are used in Directory to hold for administrative
964    and operational purposes as defined in [X.501].  Their use in LDAP is
965    detailed in [RFC3672].
966
967    The term "(sub)entry" in this specification indicates that servers
968    implementing X.500(93) models are, in accordance with X.500(93) as
969    described in [RFC3672], to use a subentry and that other servers are
970    to use an object entry belonging to the appropriate auxiliary class
971    normally used with the subentry (e.g., 'subschema' for subschema
972    subentries) to mimic the subentry.  This object entry's RDN SHALL be
973    formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
974    all subentries are named with 'cn').
975
976 3.3.  The 'objectClass' attribute
977
978    Each entry in the DIT has an 'objectClass' attribute.
979
980       ( 2.5.4.0 NAME 'objectClass'
981         EQUALITY objectIdentifierMatch
982         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
983
984    The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
985    (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
986
987    The 'objectClass' attribute specifies the object classes of an entry,
988    which (among other things) are used in conjunction with the
989    controlling schema to determine the permitted attributes of an entry.
990    Values of this attribute can be modified by clients, but the
991    'objectClass' attribute cannot be removed.
992
993    Servers that follow X.500(93) models SHALL restrict modifications of
994    this attribute to prevent the basic structural class of the entry
995    from being changed.  That is, one cannot change a 'person' into a
996    'country'.
997
998    When creating an entry or adding an 'objectClass' value to an entry,
999    all superclasses of the named classes SHALL be implicitly added as
1000    well if not already present.  That is, if the auxiliary class 'x-a'
1001    is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
1002    causes 'x-b' to be implicitly added (if is not already present).
1003
1004    Servers SHALL restrict modifications of this attribute to prevent
1005    superclasses of remaining 'objectClass' values from being deleted.
1006    That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
1007
1008
1009
1010 Zeilenga                    Standards Track                    [Page 18]
1011 \f
1012 RFC 4512                      LDAP Models                      June 2006
1013
1014
1015    class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
1016    an attempt to delete only 'x-b' from the 'objectClass' attribute is
1017    an error.
1018
1019 3.4.  Operational Attributes
1020
1021    Some attributes, termed operational attributes, are used or
1022    maintained by servers for administrative and operational purposes.
1023    As stated in [X.501]: "There are three varieties of operational
1024    attributes:  Directory operational attributes, DSA-shared operational
1025    attributes, and DSA-specific operational attributes".
1026
1027    A directory operational attribute is used to represent operational
1028    and/or administrative information in the Directory Information Model.
1029    This includes operational attributes maintained by the server (e.g.,
1030    'createTimestamp') as well as operational attributes that hold values
1031    administrated by the user (e.g., 'ditContentRules').
1032
1033    A DSA-shared operational attribute is used to represent information
1034    of the DSA Information Model that is shared between DSAs.
1035
1036    A DSA-specific operational attribute is used to represent information
1037    of the DSA Information Model that is specific to the DSA (though, in
1038    some cases, may be derived from information shared between DSAs;
1039    e.g., 'namingContexts').
1040
1041    The DSA Information Model operational attributes are detailed in
1042    [X.501].
1043
1044    Operational attributes are not normally visible.  They are not
1045    returned in search results unless explicitly requested by name.
1046
1047    Not all operational attributes are user modifiable.
1048
1049    Entries may contain, among others, the following operational
1050    attributes:
1051
1052       - creatorsName: the Distinguished Name of the user who added this
1053           entry to the directory,
1054
1055       - createTimestamp: the time this entry was added to the directory,
1056
1057       - modifiersName: the Distinguished Name of the user who last
1058           modified this entry, and
1059
1060       - modifyTimestamp: the time this entry was last modified.
1061
1062
1063
1064
1065
1066 Zeilenga                    Standards Track                    [Page 19]
1067 \f
1068 RFC 4512                      LDAP Models                      June 2006
1069
1070
1071    Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
1072    'modifiersName', and 'modifyTimestamp' attributes for all entries of
1073    the DIT.
1074
1075 3.4.1.  'creatorsName'
1076
1077    This attribute appears in entries that were added using the protocol
1078    (e.g., using the Add operation).  The value is the distinguished name
1079    of the creator.
1080
1081       ( 2.5.18.3 NAME 'creatorsName'
1082         EQUALITY distinguishedNameMatch
1083         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1084         SINGLE-VALUE NO-USER-MODIFICATION
1085         USAGE directoryOperation )
1086
1087    The 'distinguishedNameMatch' matching rule and the DistinguishedName
1088    (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
1089
1090 3.4.2.  'createTimestamp'
1091
1092    This attribute appears in entries that were added using the protocol
1093    (e.g., using the Add operation).  The value is the time the entry was
1094    added.
1095
1096       ( 2.5.18.1 NAME 'createTimestamp'
1097         EQUALITY generalizedTimeMatch
1098         ORDERING generalizedTimeOrderingMatch
1099         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1100         SINGLE-VALUE NO-USER-MODIFICATION
1101         USAGE directoryOperation )
1102
1103    The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
1104    matching rules and the GeneralizedTime
1105    (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
1106
1107 3.4.3.  'modifiersName'
1108
1109    This attribute appears in entries that have been modified using the
1110    protocol (e.g., using the Modify operation).  The value is the
1111    distinguished name of the last modifier.
1112
1113       ( 2.5.18.4 NAME 'modifiersName'
1114         EQUALITY distinguishedNameMatch
1115         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1116         SINGLE-VALUE NO-USER-MODIFICATION
1117         USAGE directoryOperation )
1118
1119
1120
1121
1122 Zeilenga                    Standards Track                    [Page 20]
1123 \f
1124 RFC 4512                      LDAP Models                      June 2006
1125
1126
1127    The 'distinguishedNameMatch' matching rule and the DistinguishedName
1128    (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
1129
1130 3.4.4.  'modifyTimestamp'
1131
1132    This attribute appears in entries that have been modified using the
1133    protocol (e.g., using the Modify operation).  The value is the time
1134    the entry was last modified.
1135
1136       ( 2.5.18.2 NAME 'modifyTimestamp'
1137         EQUALITY generalizedTimeMatch
1138         ORDERING generalizedTimeOrderingMatch
1139         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1140         SINGLE-VALUE NO-USER-MODIFICATION
1141         USAGE directoryOperation )
1142
1143    The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
1144    matching rules and the GeneralizedTime
1145    (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
1146
1147 3.4.5.  'structuralObjectClass'
1148
1149    This attribute indicates the structural object class of the entry.
1150
1151       ( 2.5.21.9 NAME 'structuralObjectClass'
1152         EQUALITY objectIdentifierMatch
1153         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
1154         SINGLE-VALUE NO-USER-MODIFICATION
1155         USAGE directoryOperation )
1156
1157    The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
1158    (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
1159
1160 3.4.6.  'governingStructureRule'
1161
1162    This attribute indicates the structure rule governing the entry.
1163
1164       ( 2.5.21.10 NAME 'governingStructureRule'
1165         EQUALITY integerMatch
1166         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1167         SINGLE-VALUE NO-USER-MODIFICATION
1168         USAGE directoryOperation )
1169
1170    The 'integerMatch' matching rule and INTEGER
1171    (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
1172
1173
1174
1175
1176
1177
1178 Zeilenga                    Standards Track                    [Page 21]
1179 \f
1180 RFC 4512                      LDAP Models                      June 2006
1181
1182
1183 4.  Directory Schema
1184
1185    As defined in [X.501]:
1186
1187       The Directory Schema is a set of definitions and constraints
1188       concerning the structure of the DIT, the possible ways entries are
1189       named, the information that can be held in an entry, the
1190       attributes used to represent that information and their
1191       organization into hierarchies to facilitate search and retrieval
1192       of the information and the ways in which values of attributes may
1193       be matched in attribute value and matching rule assertions.
1194
1195       NOTE 1 - The schema enables the Directory system to, for example:
1196
1197       - prevent the creation of subordinate entries of the wrong
1198         object-class (e.g., a country as a subordinate of a person);
1199
1200       - prevent the addition of attribute-types to an entry
1201         inappropriate to the object-class (e.g., a serial number to a
1202         person's entry);
1203
1204       - prevent the addition of an attribute value of a syntax not
1205         matching that defined for the attribute-type (e.g., a printable
1206         string to a bit string).
1207
1208       Formally, the Directory Schema comprises a set of:
1209
1210       a) Name Form definitions that define primitive naming relations
1211          for structural object classes;
1212
1213       b) DIT Structure Rule definitions that define the names that
1214          entries may have and the ways in which the entries may be
1215          related to one another in the DIT;
1216
1217       c) DIT Content Rule definitions that extend the specification of
1218          allowable attributes for entries beyond those indicated by the
1219          structural object classes of the entries;
1220
1221       d) Object Class definitions that define the basic set of mandatory
1222          and optional attributes that shall be present, and may be
1223          present, respectively, in an entry of a given class, and which
1224          indicate the kind of object class that is being defined;
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234 Zeilenga                    Standards Track                    [Page 22]
1235 \f
1236 RFC 4512                      LDAP Models                      June 2006
1237
1238
1239       e) Attribute Type definitions that identify the object identifier
1240          by which an attribute is known, its syntax, associated matching
1241          rules, whether it is an operational attribute and if so its
1242          type, whether it is a collective attribute, whether it is
1243          permitted to have multiple values and whether or not it is
1244          derived from another attribute type;
1245
1246       f) Matching Rule definitions that define matching rules.
1247
1248       And in LDAP:
1249
1250       g) LDAP Syntax definitions that define encodings used in LDAP.
1251
1252 4.1.  Schema Definitions
1253
1254    Schema definitions in this section are described using ABNF and rely
1255    on the common productions specified in Section 1.2 as well as these:
1256
1257       noidlen = numericoid [ LCURLY len RCURLY ]
1258       len = number
1259
1260       oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
1261       oidlist = oid *( WSP DOLLAR WSP oid )
1262
1263       extensions = *( SP xstring SP qdstrings )
1264       xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
1265
1266       qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
1267       qdescrlist = [ qdescr *( SP qdescr ) ]
1268       qdescr = SQUOTE descr SQUOTE
1269
1270       qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
1271       qdstringlist = [ qdstring *( SP qdstring ) ]
1272       qdstring = SQUOTE dstring SQUOTE
1273       dstring = 1*( QS / QQ / QUTF8 )   ; escaped UTF-8 string
1274
1275       QQ =  ESC %x32 %x37 ; "\27"
1276       QS =  ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
1277
1278       ; Any UTF-8 encoded Unicode character
1279       ; except %x27 ("\'") and %x5C ("\")
1280       QUTF8    = QUTF1 / UTFMB
1281
1282       ; Any ASCII character except %x27 ("\'") and %x5C ("\")
1283       QUTF1    = %x00-26 / %x28-5B / %x5D-7F
1284
1285    Schema definitions in this section also share a number of common
1286    terms.
1287
1288
1289
1290 Zeilenga                    Standards Track                    [Page 23]
1291 \f
1292 RFC 4512                      LDAP Models                      June 2006
1293
1294
1295    The NAME field provides a set of short names (descriptors) that are
1296    to be used as aliases for the OID.
1297
1298    The DESC field optionally allows a descriptive string to be provided
1299    by the directory administrator and/or implementor.  While
1300    specifications may suggest a descriptive string, there is no
1301    requirement that the suggested (or any) descriptive string be used.
1302
1303    The OBSOLETE field, if present, indicates the element is not active.
1304
1305    Implementors should note that future versions of this document may
1306    expand these definitions to include additional terms.  Terms whose
1307    identifier begins with "X-" are reserved for private experiments and
1308    are followed by <SP> and <qdstrings> tokens.
1309
1310 4.1.1.  Object Class Definitions
1311
1312    Object Class definitions are written according to the ABNF:
1313
1314      ObjectClassDescription = LPAREN WSP
1315          numericoid                 ; object identifier
1316          [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
1317          [ SP "DESC" SP qdstring ]  ; description
1318          [ SP "OBSOLETE" ]          ; not active
1319          [ SP "SUP" SP oids ]       ; superior object classes
1320          [ SP kind ]                ; kind of class
1321          [ SP "MUST" SP oids ]      ; attribute types
1322          [ SP "MAY" SP oids ]       ; attribute types
1323          extensions WSP RPAREN
1324
1325      kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
1326
1327    where:
1328      <numericoid> is object identifier assigned to this object class;
1329      NAME <qdescrs> are short names (descriptors) identifying this
1330          object class;
1331      DESC <qdstring> is a short descriptive string;
1332      OBSOLETE indicates this object class is not active;
1333      SUP <oids> specifies the direct superclasses of this object class;
1334      the kind of object class is indicated by one of ABSTRACT,
1335          STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
1336      MUST and MAY specify the sets of required and allowed attribute
1337          types, respectively; and
1338      <extensions> describe extensions.
1339
1340
1341
1342
1343
1344
1345
1346 Zeilenga                    Standards Track                    [Page 24]
1347 \f
1348 RFC 4512                      LDAP Models                      June 2006
1349
1350
1351 4.1.2.  Attribute Types
1352
1353    Attribute Type definitions are written according to the ABNF:
1354
1355      AttributeTypeDescription = LPAREN WSP
1356          numericoid                    ; object identifier
1357          [ SP "NAME" SP qdescrs ]      ; short names (descriptors)
1358          [ SP "DESC" SP qdstring ]     ; description
1359          [ SP "OBSOLETE" ]             ; not active
1360          [ SP "SUP" SP oid ]           ; supertype
1361          [ SP "EQUALITY" SP oid ]      ; equality matching rule
1362          [ SP "ORDERING" SP oid ]      ; ordering matching rule
1363          [ SP "SUBSTR" SP oid ]        ; substrings matching rule
1364          [ SP "SYNTAX" SP noidlen ]    ; value syntax
1365          [ SP "SINGLE-VALUE" ]         ; single-value
1366          [ SP "COLLECTIVE" ]           ; collective
1367          [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
1368          [ SP "USAGE" SP usage ]       ; usage
1369          extensions WSP RPAREN         ; extensions
1370
1371      usage = "userApplications"     /  ; user
1372              "directoryOperation"   /  ; directory operational
1373              "distributedOperation" /  ; DSA-shared operational
1374              "dSAOperation"            ; DSA-specific operational
1375
1376    where:
1377      <numericoid> is object identifier assigned to this attribute type;
1378      NAME <qdescrs> are short names (descriptors) identifying this
1379          attribute type;
1380      DESC <qdstring> is a short descriptive string;
1381      OBSOLETE indicates this attribute type is not active;
1382      SUP oid specifies the direct supertype of this type;
1383      EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
1384          ordering, and substrings matching rules, respectively;
1385      SYNTAX identifies value syntax by object identifier and may suggest
1386          a minimum upper bound;
1387      SINGLE-VALUE indicates attributes of this type are restricted to a
1388          single value;
1389      COLLECTIVE indicates this attribute type is collective
1390          [X.501][RFC3671];
1391      NO-USER-MODIFICATION indicates this attribute type is not user
1392          modifiable;
1393      USAGE indicates the application of this attribute type; and
1394      <extensions> describe extensions.
1395
1396    Each attribute type description must contain at least one of the SUP
1397    or SYNTAX fields.  If no SYNTAX field is provided, the attribute type
1398    description takes its value from the supertype.
1399
1400
1401
1402 Zeilenga                    Standards Track                    [Page 25]
1403 \f
1404 RFC 4512                      LDAP Models                      June 2006
1405
1406
1407    If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
1408    fields, if not specified, take their value from the supertype.
1409
1410    Usage of userApplications, the default, indicates that attributes of
1411    this type represent user information.  That is, they are user
1412    attributes.
1413
1414    A usage of directoryOperation, distributedOperation, or dSAOperation
1415    indicates that attributes of this type represent operational and/or
1416    administrative information.  That is, they are operational
1417    attributes.
1418
1419    directoryOperation usage indicates that the attribute of this type is
1420    a directory operational attribute.  distributedOperation usage
1421    indicates that the attribute of this type is a DSA-shared usage
1422    operational attribute.  dSAOperation usage indicates that the
1423    attribute of this type is a DSA-specific operational attribute.
1424
1425    COLLECTIVE requires usage userApplications.  Use of collective
1426    attribute types in LDAP is discussed in [RFC3671].
1427
1428    NO-USER-MODIFICATION requires an operational usage.
1429
1430    Note that the <AttributeTypeDescription> does not list the matching
1431    rules that can be used with that attribute type in an extensibleMatch
1432    search filter [RFC4511].  This is done using the 'matchingRuleUse'
1433    attribute described in Section 4.1.4.
1434
1435    This document refines the schema description of X.501 by requiring
1436    that the SYNTAX field in an <AttributeTypeDescription> be a string
1437    representation of an object identifier for the LDAP string syntax
1438    definition, with an optional indication of the suggested minimum
1439    bound of a value of this attribute.
1440
1441    A suggested minimum upper bound on the number of characters in a
1442    value with a string-based syntax, or the number of bytes in a value
1443    for all other syntaxes, may be indicated by appending this bound
1444    count inside of curly braces following the syntax's OBJECT IDENTIFIER
1445    in an Attribute Type Description.  This bound is not part of the
1446    syntax name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests
1447    that server implementations should allow a string to be 64 characters
1448    long, although they may allow longer strings.  Note that a single
1449    character of the Directory String syntax may be encoded in more than
1450    one octet since UTF-8 [RFC3629] is a variable-length encoding.
1451
1452
1453
1454
1455
1456
1457
1458 Zeilenga                    Standards Track                    [Page 26]
1459 \f
1460 RFC 4512                      LDAP Models                      June 2006
1461
1462
1463 4.1.3.  Matching Rules
1464
1465    Matching rules are used in performance of attribute value assertions,
1466    such as in performance of a Compare operation.  They are also used in
1467    evaluating search filters, determining which individual values are to
1468    be added or deleted during performance of a Modify operation, and in
1469    comparing distinguished names.
1470
1471    Each matching rule is identified by an object identifier (OID) and,
1472    optionally, one or more short names (descriptors).
1473
1474    Matching rule definitions are written according to the ABNF:
1475
1476      MatchingRuleDescription = LPAREN WSP
1477          numericoid                 ; object identifier
1478          [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
1479          [ SP "DESC" SP qdstring ]  ; description
1480          [ SP "OBSOLETE" ]          ; not active
1481          SP "SYNTAX" SP numericoid  ; assertion syntax
1482          extensions WSP RPAREN      ; extensions
1483
1484    where:
1485      <numericoid> is object identifier assigned to this matching rule;
1486      NAME <qdescrs> are short names (descriptors) identifying this
1487          matching rule;
1488      DESC <qdstring> is a short descriptive string;
1489      OBSOLETE indicates this matching rule is not active;
1490      SYNTAX identifies the assertion syntax (the syntax of the assertion
1491          value) by object identifier; and
1492      <extensions> describe extensions.
1493
1494 4.1.4.  Matching Rule Uses
1495
1496    A matching rule use lists the attribute types that are suitable for
1497    use with an extensibleMatch search filter.
1498
1499    Matching rule use descriptions are written according to the following
1500    ABNF:
1501
1502      MatchingRuleUseDescription = LPAREN WSP
1503          numericoid                 ; object identifier
1504          [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
1505          [ SP "DESC" SP qdstring ]  ; description
1506          [ SP "OBSOLETE" ]          ; not active
1507          SP "APPLIES" SP oids       ; attribute types
1508          extensions WSP RPAREN      ; extensions
1509
1510
1511
1512
1513
1514 Zeilenga                    Standards Track                    [Page 27]
1515 \f
1516 RFC 4512                      LDAP Models                      June 2006
1517
1518
1519    where:
1520      <numericoid> is the object identifier of the matching rule
1521          associated with this matching rule use description;
1522      NAME <qdescrs> are short names (descriptors) identifying this
1523          matching rule use;
1524      DESC <qdstring> is a short descriptive string;
1525      OBSOLETE indicates this matching rule use is not active;
1526      APPLIES provides a list of attribute types the matching rule
1527          applies to; and
1528      <extensions> describe extensions.
1529
1530 4.1.5.  LDAP Syntaxes
1531
1532    LDAP Syntaxes of (attribute and assertion) values are described in
1533    terms of ASN.1 [X.680] and, optionally, have an octet string encoding
1534    known as the LDAP-specific encoding.  Commonly, the LDAP-specific
1535    encoding is constrained to a string of Unicode [Unicode] characters
1536    in UTF-8 [RFC3629] form.
1537
1538    Each LDAP syntax is identified by an object identifier (OID).
1539
1540    LDAP syntax definitions are written according to the ABNF:
1541
1542      SyntaxDescription = LPAREN WSP
1543          numericoid                 ; object identifier
1544          [ SP "DESC" SP qdstring ]  ; description
1545          extensions WSP RPAREN      ; extensions
1546
1547    where:
1548      <numericoid> is the object identifier assigned to this LDAP syntax;
1549      DESC <qdstring> is a short descriptive string; and
1550      <extensions> describe extensions.
1551
1552 4.1.6.  DIT Content Rules
1553
1554    A DIT content rule is a "rule governing the content of entries of a
1555    particular structural object class" [X.501].
1556
1557    For DIT entries of a particular structural object class, a DIT
1558    content rule specifies which auxiliary object classes the entries are
1559    allowed to belong to and which additional attributes (by type) are
1560    required, allowed, or not allowed to appear in the entries.
1561
1562    The list of precluded attributes cannot include any attribute listed
1563    as mandatory in the rule, the structural object class, or any of the
1564    allowed auxiliary object classes.
1565
1566
1567
1568
1569
1570 Zeilenga                    Standards Track                    [Page 28]
1571 \f
1572 RFC 4512                      LDAP Models                      June 2006
1573
1574
1575    Each content rule is identified by the object identifier, as well as
1576    any short names (descriptors), of the structural object class it
1577    applies to.
1578
1579    An entry may only belong to auxiliary object classes listed in the
1580    governing content rule.
1581
1582    An entry must contain all attributes required by the object classes
1583    the entry belongs to as well as all attributes required by the
1584    governing content rule.
1585
1586    An entry may contain any non-precluded attributes allowed by the
1587    object classes the entry belongs to as well as all attributes allowed
1588    by the governing content rule.
1589
1590    An entry cannot include any attribute precluded by the governing
1591    content rule.
1592
1593    An entry is governed by (if present and active in the subschema) the
1594    DIT content rule that applies to the structural object class of the
1595    entry (see Section 2.4.2).  If no active rule is present for the
1596    entry's structural object class, the entry's content is governed by
1597    the structural object class (and possibly other aspects of user and
1598    system schema).  DIT content rules for superclasses of the structural
1599    object class of an entry are not applicable to that entry.
1600
1601    DIT content rule descriptions are written according to the ABNF:
1602
1603      DITContentRuleDescription = LPAREN WSP
1604          numericoid                 ; object identifier
1605          [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
1606          [ SP "DESC" SP qdstring ]  ; description
1607          [ SP "OBSOLETE" ]          ; not active
1608          [ SP "AUX" SP oids ]       ; auxiliary object classes
1609          [ SP "MUST" SP oids ]      ; attribute types
1610          [ SP "MAY" SP oids ]       ; attribute types
1611          [ SP "NOT" SP oids ]       ; attribute types
1612          extensions WSP RPAREN      ; extensions
1613
1614    where:
1615      <numericoid> is the object identifier of the structural object
1616          class associated with this DIT content rule;
1617      NAME <qdescrs> are short names (descriptors) identifying this DIT
1618          content rule;
1619      DESC <qdstring> is a short descriptive string;
1620      OBSOLETE indicates this DIT content rule use is not active;
1621      AUX specifies a list of auxiliary object classes that entries
1622          subject to this DIT content rule may belong to;
1623
1624
1625
1626 Zeilenga                    Standards Track                    [Page 29]
1627 \f
1628 RFC 4512                      LDAP Models                      June 2006
1629
1630
1631      MUST, MAY, and NOT specify lists of attribute types that are
1632          required, allowed, or precluded, respectively, from appearing
1633          in entries subject to this DIT content rule; and
1634      <extensions> describe extensions.
1635
1636 4.1.7.  DIT Structure Rules and Name Forms
1637
1638    It is sometimes desirable to regulate where object and alias entries
1639    can be placed in the DIT and how they can be named based upon their
1640    structural object class.
1641
1642 4.1.7.1.  DIT Structure Rules
1643
1644    A DIT structure rule is a "rule governing the structure of the DIT by
1645    specifying a permitted superior to subordinate entry relationship.  A
1646    structure rule relates a name form, and therefore a structural object
1647    class, to superior structure rules.  This permits entries of the
1648    structural object class identified by the name form to exist in the
1649    DIT as subordinates to entries governed by the indicated superior
1650    structure rules" [X.501].
1651
1652    DIT structure rule descriptions are written according to the ABNF:
1653
1654      DITStructureRuleDescription = LPAREN WSP
1655          ruleid                     ; rule identifier
1656          [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
1657          [ SP "DESC" SP qdstring ]  ; description
1658          [ SP "OBSOLETE" ]          ; not active
1659          SP "FORM" SP oid           ; NameForm
1660          [ SP "SUP" ruleids ]       ; superior rules
1661          extensions WSP RPAREN      ; extensions
1662
1663      ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
1664      ruleidlist = ruleid *( SP ruleid )
1665      ruleid = number
1666
1667    where:
1668      <ruleid> is the rule identifier of this DIT structure rule;
1669      NAME <qdescrs> are short names (descriptors) identifying this DIT
1670          structure rule;
1671      DESC <qdstring> is a short descriptive string;
1672      OBSOLETE indicates this DIT structure rule use is not active;
1673      FORM is specifies the name form associated with this DIT structure
1674          rule;
1675      SUP identifies superior rules (by rule id); and
1676      <extensions> describe extensions.
1677
1678
1679
1680
1681
1682 Zeilenga                    Standards Track                    [Page 30]
1683 \f
1684 RFC 4512                      LDAP Models                      June 2006
1685
1686
1687    If no superior rules are identified, the DIT structure rule applies
1688    to an autonomous administrative point (e.g., the root vertex of the
1689    subtree controlled by the subschema) [X.501].
1690
1691 4.1.7.2.  Name Forms
1692
1693    A name form "specifies a permissible RDN for entries of a particular
1694    structural object class.  A name form identifies a named object class
1695    and one or more attribute types to be used for naming (i.e., for the
1696    RDN).  Name forms are primitive pieces of specification used in the
1697    definition of DIT structure rules" [X.501].
1698
1699    Each name form indicates the structural object class to be named, a
1700    set of required attribute types, and a set of allowed attribute
1701    types.  A particular attribute type cannot be in both sets.
1702
1703    Entries governed by the form must be named using a value from each
1704    required attribute type and zero or more values from the allowed
1705    attribute types.
1706
1707    Each name form is identified by an object identifier (OID) and,
1708    optionally, one or more short names (descriptors).
1709
1710    Name form descriptions are written according to the ABNF:
1711
1712      NameFormDescription = LPAREN WSP
1713          numericoid                 ; object identifier
1714          [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
1715          [ SP "DESC" SP qdstring ]  ; description
1716          [ SP "OBSOLETE" ]          ; not active
1717          SP "OC" SP oid             ; structural object class
1718          SP "MUST" SP oids          ; attribute types
1719          [ SP "MAY" SP oids ]       ; attribute types
1720          extensions WSP RPAREN      ; extensions
1721
1722    where:
1723      <numericoid> is object identifier that identifies this name form;
1724      NAME <qdescrs> are short names (descriptors) identifying this name
1725          form;
1726      DESC <qdstring> is a short descriptive string;
1727      OBSOLETE indicates this name form is not active;
1728      OC identifies the structural object class this rule applies to,
1729      MUST and MAY specify the sets of required and allowed,
1730          respectively, naming attributes for this name form; and
1731      <extensions> describe extensions.
1732
1733    All attribute types in the required ("MUST") and allowed ("MAY")
1734    lists shall be different.
1735
1736
1737
1738 Zeilenga                    Standards Track                    [Page 31]
1739 \f
1740 RFC 4512                      LDAP Models                      June 2006
1741
1742
1743 4.2.  Subschema Subentries
1744
1745    Subschema (sub)entries are used for administering information about
1746    the directory schema.  A single subschema (sub)entry contains all
1747    schema definitions (see Section 4.1) used by entries in a particular
1748    part of the directory tree.
1749
1750    Servers that follow X.500(93) models SHOULD implement subschema using
1751    the X.500 subschema mechanisms (as detailed in Section 12 of
1752    [X.501]), so these are not ordinary object entries but subentries
1753    (see Section 3.2).  LDAP clients SHOULD NOT assume that servers
1754    implement any of the other aspects of X.500 subschema.
1755
1756    Servers MAY allow subschema modification.  Procedures for subschema
1757    modification are discussed in Section 14.5 of [X.501].
1758
1759    A server that masters entries and permits clients to modify these
1760    entries SHALL implement and provide access to these subschema
1761    (sub)entries including providing a 'subschemaSubentry' attribute in
1762    each modifiable entry.  This is so clients may discover the
1763    attributes and object classes that are permitted to be present.  It
1764    is strongly RECOMMENDED that all other servers implement this as
1765    well.
1766
1767    The value of the 'subschemaSubentry' attribute is the name of the
1768    subschema (sub)entry holding the subschema controlling the entry.
1769
1770       ( 2.5.18.10 NAME 'subschemaSubentry'
1771         EQUALITY distinguishedNameMatch
1772         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1773         SINGLE-VALUE NO-USER-MODIFICATION
1774         USAGE directoryOperation )
1775
1776    The 'distinguishedNameMatch' matching rule and the DistinguishedName
1777    (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
1778
1779    Subschema is held in (sub)entries belonging to the subschema
1780    auxiliary object class.
1781
1782       ( 2.5.20.1 NAME 'subschema' AUXILIARY
1783         MAY ( dITStructureRules $ nameForms $ ditContentRules $
1784           objectClasses $ attributeTypes $ matchingRules $
1785           matchingRuleUse ) )
1786
1787    The 'ldapSyntaxes' operational attribute may also be present in
1788    subschema entries.
1789
1790
1791
1792
1793
1794 Zeilenga                    Standards Track                    [Page 32]
1795 \f
1796 RFC 4512                      LDAP Models                      June 2006
1797
1798
1799    Servers MAY provide additional attributes (described in other
1800    documents) in subschema (sub)entries.
1801
1802    Servers SHOULD provide the attributes 'createTimestamp' and
1803    'modifyTimestamp' in subschema (sub)entries, in order to allow
1804    clients to maintain their caches of schema information.
1805
1806    The following subsections provide attribute type definitions for each
1807    of schema definition attribute types.
1808
1809 4.2.1.  'objectClasses'
1810
1811    This attribute holds definitions of object classes.
1812
1813       ( 2.5.21.6 NAME 'objectClasses'
1814         EQUALITY objectIdentifierFirstComponentMatch
1815         SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
1816         USAGE directoryOperation )
1817
1818    The 'objectIdentifierFirstComponentMatch' matching rule and the
1819    ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
1820    defined in [RFC4517].
1821
1822 4.2.2.  'attributeTypes'
1823
1824    This attribute holds definitions of attribute types.
1825
1826       ( 2.5.21.5 NAME 'attributeTypes'
1827         EQUALITY objectIdentifierFirstComponentMatch
1828         SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
1829         USAGE directoryOperation )
1830
1831    The 'objectIdentifierFirstComponentMatch' matching rule and the
1832    AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
1833    defined in [RFC4517].
1834
1835 4.2.3.  'matchingRules'
1836
1837    This attribute holds definitions of matching rules.
1838
1839       ( 2.5.21.4 NAME 'matchingRules'
1840         EQUALITY objectIdentifierFirstComponentMatch
1841         SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
1842         USAGE directoryOperation )
1843
1844    The 'objectIdentifierFirstComponentMatch' matching rule and the
1845    MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
1846    defined in [RFC4517].
1847
1848
1849
1850 Zeilenga                    Standards Track                    [Page 33]
1851 \f
1852 RFC 4512                      LDAP Models                      June 2006
1853
1854
1855 4.2.4 'matchingRuleUse'
1856
1857    This attribute holds definitions of matching rule uses.
1858
1859       ( 2.5.21.8 NAME 'matchingRuleUse'
1860         EQUALITY objectIdentifierFirstComponentMatch
1861         SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
1862         USAGE directoryOperation )
1863
1864    The 'objectIdentifierFirstComponentMatch' matching rule and the
1865    MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
1866    defined in [RFC4517].
1867
1868 4.2.5.  'ldapSyntaxes'
1869
1870    This attribute holds definitions of LDAP syntaxes.
1871
1872       ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
1873         EQUALITY objectIdentifierFirstComponentMatch
1874         SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
1875         USAGE directoryOperation )
1876
1877    The 'objectIdentifierFirstComponentMatch' matching rule and the
1878    SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
1879    in [RFC4517].
1880
1881 4.2.6.  'dITContentRules'
1882
1883    This attribute lists DIT Content Rules that are present in the
1884    subschema.
1885
1886       ( 2.5.21.2 NAME 'dITContentRules'
1887         EQUALITY objectIdentifierFirstComponentMatch
1888         SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
1889         USAGE directoryOperation )
1890
1891    The 'objectIdentifierFirstComponentMatch' matching rule and the
1892    DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
1893    defined in [RFC4517].
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906 Zeilenga                    Standards Track                    [Page 34]
1907 \f
1908 RFC 4512                      LDAP Models                      June 2006
1909
1910
1911 4.2.7.  'dITStructureRules'
1912
1913    This attribute lists DIT Structure Rules that are present in the
1914    subschema.
1915
1916       ( 2.5.21.1 NAME 'dITStructureRules'
1917         EQUALITY integerFirstComponentMatch
1918         SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
1919         USAGE directoryOperation )
1920
1921    The 'integerFirstComponentMatch' matching rule and the
1922    DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
1923    are defined in [RFC4517].
1924
1925 4.2.8 'nameForms'
1926
1927    This attribute lists Name Forms that are in force.
1928
1929       ( 2.5.21.7 NAME 'nameForms'
1930         EQUALITY objectIdentifierFirstComponentMatch
1931         SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
1932         USAGE directoryOperation )
1933
1934    The 'objectIdentifierFirstComponentMatch' matching rule and the
1935    NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
1936    defined in [RFC4517].
1937
1938 4.3.  'extensibleObject' object class
1939
1940    The 'extensibleObject' auxiliary object class allows entries that
1941    belong to it to hold any user attribute.  The set of allowed
1942    attribute types of this object class is implicitly the set of all
1943    attribute types of userApplications usage.
1944
1945       ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
1946         SUP top AUXILIARY )
1947
1948    The mandatory attributes of the other object classes of this entry
1949    are still required to be present, and any precluded attributes are
1950    still not allowed to be present.
1951
1952 4.4.  Subschema Discovery
1953
1954    To discover the DN of the subschema (sub)entry holding the subschema
1955    controlling a particular entry, a client reads that entry's
1956    'subschemaSubentry' operational attribute.  To read schema attributes
1957    from the subschema (sub)entry, clients MUST issue a Search operation
1958    [RFC4511] where baseObject is the DN of the subschema (sub)entry,
1959
1960
1961
1962 Zeilenga                    Standards Track                    [Page 35]
1963 \f
1964 RFC 4512                      LDAP Models                      June 2006
1965
1966
1967    scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
1968    and the attributes field lists the names of the desired schema
1969    attributes (as they are operational).  Note: the
1970    "(objectClass=subschema)" filter allows LDAP servers that gateway to
1971    X.500 to detect that subentry information is being requested.
1972
1973    Clients SHOULD NOT assume that a published subschema is complete,
1974    that the server supports all of the schema elements it publishes, or
1975    that the server does not support an unpublished element.
1976
1977 5.  DSA (Server) Informational Model
1978
1979    The LDAP protocol assumes there are one or more servers that jointly
1980    provide access to a Directory Information Tree (DIT).  The server
1981    holding the original information is called the "master" (for that
1982    information).  Servers that hold copies of the original information
1983    are referred to as "shadowing" or "caching" servers.
1984
1985
1986    As defined in [X.501]:
1987
1988       context prefix: The sequence of RDNs leading from the Root of the
1989           DIT to the initial vertex of a naming context; corresponds to
1990           the distinguished name of that vertex.
1991
1992       naming context: A subtree of entries held in a single master DSA.
1993
1994    That is, a naming context is the largest collection of entries,
1995    starting at an entry that is mastered by a particular server, and
1996    including all its subordinates and their subordinates, down to the
1997    entries that are mastered by different servers.  The context prefix
1998    is the name of the initial entry.
1999
2000    The root of the DIT is a DSA-specific Entry (DSE) and not part of any
2001    naming context (or any subtree); each server has different attribute
2002    values in the root DSE.
2003
2004 5.1.  Server-Specific Data Requirements
2005
2006    An LDAP server SHALL provide information about itself and other
2007    information that is specific to each server.  This is represented as
2008    a group of attributes located in the root DSE, which is named with
2009    the DN with zero RDNs (whose [RFC4514] representation is as the
2010    zero-length string).
2011
2012    These attributes are retrievable, subject to access control and other
2013    restrictions, if a client performs a Search operation [RFC4511] with
2014    an empty baseObject, scope of baseObject, the filter
2015
2016
2017
2018 Zeilenga                    Standards Track                    [Page 36]
2019 \f
2020 RFC 4512                      LDAP Models                      June 2006
2021
2022
2023    "(objectClass=*)" [RFC4515], and the attributes field listing the
2024    names of the desired attributes.  It is noted that root DSE
2025    attributes are operational and, like other operational attributes,
2026    are not returned in search requests unless requested by name.
2027
2028    The root DSE SHALL NOT be included if the client performs a subtree
2029    search starting from the root.
2030
2031    Servers may allow clients to modify attributes of the root DSE, where
2032    appropriate.
2033
2034    The following attributes of the root DSE are defined below.
2035    Additional attributes may be defined in other documents.
2036
2037       - altServer: alternative servers;
2038
2039       - namingContexts: naming contexts;
2040
2041       - supportedControl: recognized LDAP controls;
2042
2043       - supportedExtension: recognized LDAP extended operations;
2044
2045       - supportedFeatures: recognized LDAP features;
2046
2047       - supportedLDAPVersion: LDAP versions supported; and
2048
2049       - supportedSASLMechanisms: recognized Simple Authentication and
2050         Security Layers (SASL) [RFC4422] mechanisms.
2051
2052    The values provided for these attributes may depend on session-
2053    specific and other factors.  For example, a server supporting the
2054    SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
2055    identity has been established by a lower level.  See [RFC4513].
2056
2057    The root DSE may also include a 'subschemaSubentry' attribute.  If it
2058    does, the attribute refers to the subschema (sub)entry holding the
2059    schema controlling the root DSE.  Clients SHOULD NOT assume that this
2060    subschema (sub)entry controls other entries held by the server.
2061    General subschema discovery procedures are provided in Section 4.4.
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074 Zeilenga                    Standards Track                    [Page 37]
2075 \f
2076 RFC 4512                      LDAP Models                      June 2006
2077
2078
2079 5.1.1.  'altServer'
2080
2081    The 'altServer' attribute lists URIs referring to alternative servers
2082    that may be contacted when this server becomes unavailable.  URIs for
2083    servers implementing the LDAP are written according to [RFC4516].
2084    Other kinds of URIs may be provided.  If the server does not know of
2085    any other servers that could be used, this attribute will be absent.
2086    Clients may cache this information in case their preferred server
2087    later becomes unavailable.
2088
2089       ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
2090         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
2091         USAGE dSAOperation )
2092
2093    The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
2094    [RFC4517].
2095
2096 5.1.2.  'namingContexts'
2097
2098    The 'namingContexts' attribute lists the context prefixes of the
2099    naming contexts the server masters or shadows (in part or in whole).
2100    If the server is a first-level DSA [X.501], it should list (in
2101    addition) an empty string (indicating the root of the DIT).  If the
2102    server does not master or shadow any information (e.g., it is an LDAP
2103    gateway to a public X.500 directory) this attribute will be absent.
2104    If the server believes it masters or shadows the entire directory,
2105    the attribute will have a single value, and that value will be the
2106    empty string (indicating the root of the DIT).
2107
2108    This attribute may be used, for example, to select a suitable entry
2109    name for subsequent operations with this server.
2110
2111       ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
2112         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2113         USAGE dSAOperation )
2114
2115    The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
2116    defined in [RFC4517].
2117
2118 5.1.3.  'supportedControl'
2119
2120    The 'supportedControl' attribute lists object identifiers identifying
2121    the request controls [RFC4511] the server supports.  If the server
2122    does not support any request controls, this attribute will be absent.
2123    Object identifiers identifying response controls need not be listed.
2124
2125    Procedures for registering object identifiers used to discovery of
2126    protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
2127
2128
2129
2130 Zeilenga                    Standards Track                    [Page 38]
2131 \f
2132 RFC 4512                      LDAP Models                      June 2006
2133
2134
2135       ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
2136         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2137         USAGE dSAOperation )
2138
2139    The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2140    defined in [RFC4517].
2141
2142 5.1.4.  'supportedExtension'
2143
2144    The 'supportedExtension' attribute lists object identifiers
2145    identifying the extended operations [RFC4511] that the server
2146    supports.  If the server does not support any extended operations,
2147    this attribute will be absent.
2148
2149    An extended operation generally consists of an extended request and
2150    an extended response but may also include other protocol data units
2151    (such as intermediate responses).  The object identifier assigned to
2152    the extended request is used to identify the extended operation.
2153    Other object identifiers used in the extended operation need not be
2154    listed as values of this attribute.
2155
2156    Procedures for registering object identifiers used to discovery of
2157    protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
2158
2159       ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
2160         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2161         USAGE dSAOperation )
2162
2163    The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2164    defined in [RFC4517].
2165
2166 5.1.5.  'supportedFeatures'
2167
2168    The 'supportedFeatures' attribute lists object identifiers
2169    identifying elective features that the server supports.  If the
2170    server does not support any discoverable elective features, this
2171    attribute will be absent.
2172
2173       ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
2174           EQUALITY objectIdentifierMatch
2175           SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2176           USAGE dSAOperation )
2177
2178    Procedures for registering object identifiers used to discovery of
2179    protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
2180
2181    The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
2182    objectIdentifierMatch matching rule are defined in [RFC4517].
2183
2184
2185
2186 Zeilenga                    Standards Track                    [Page 39]
2187 \f
2188 RFC 4512                      LDAP Models                      June 2006
2189
2190
2191 5.1.6.  'supportedLDAPVersion'
2192
2193    The 'supportedLDAPVersion' attribute lists the versions of LDAP that
2194    the server supports.
2195
2196       ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
2197         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2198         USAGE dSAOperation )
2199
2200    The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
2201    [RFC4517].
2202
2203 5.1.7.  'supportedSASLMechanisms'
2204
2205    The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
2206    [RFC4422] that the server recognizes and/or supports [RFC4513].  The
2207    contents of this attribute may depend on the current session state.
2208    If the server does not support any SASL mechanisms, this attribute
2209    will not be present.
2210
2211       ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
2212         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2213         USAGE dSAOperation )
2214
2215    The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
2216    defined in [RFC4517].
2217
2218 6.  Other Considerations
2219
2220 6.1.  Preservation of User Information
2221
2222    Syntaxes may be defined that have specific value and/or value form
2223    (representation) preservation requirements.  For example, a syntax
2224    containing digitally signed data can mandate that the server preserve
2225    both the value and form of value presented to ensure that the
2226    signature is not invalidated.
2227
2228    Where such requirements have not been explicitly stated, servers
2229    SHOULD preserve the value of user information but MAY return the
2230    value in a different form.  And where a server is unable (or
2231    unwilling) to preserve the value of user information, the server
2232    SHALL ensure that an equivalent value (per Section 2.3) is returned.
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242 Zeilenga                    Standards Track                    [Page 40]
2243 \f
2244 RFC 4512                      LDAP Models                      June 2006
2245
2246
2247 6.2.  Short Names
2248
2249    Short names, also known as descriptors, are used as more readable
2250    aliases for object identifiers and are used to identify various
2251    schema elements.  However, it is not expected that LDAP
2252    implementations with human user interface would display these short
2253    names (or the object identifiers they refer to) to the user.
2254    Instead, they would most likely be performing translations (such as
2255    expressing the short name in one of the local national languages).
2256    For example, the short name "st" (stateOrProvinceName) might be
2257    displayed to a German-speaking user as "Land".
2258
2259    The same short name might have different meaning in different
2260    subschemas, and, within a particular subschema, the same short name
2261    might refer to different object identifiers each identifying a
2262    different kind of schema element.
2263
2264    Implementations MUST be prepared that the same short name might be
2265    used in a subschema to refer to the different kinds of schema
2266    elements.  That is, there might be an object class 'x-fubar' and an
2267    attribute type 'x-fubar' in a subschema.
2268
2269    Implementations MUST be prepared that the same short name might be
2270    used in the different subschemas to refer to the different schema
2271    elements.  That is, there might be two matching rules 'x-fubar', each
2272    in different subschemas.
2273
2274    Procedures for registering short names (descriptors) are detailed in
2275    BCP 64, RFC 4520 [RFC4520].
2276
2277 6.3.  Cache and Shadowing
2278
2279    Some servers may hold cache or shadow copies of entries, which can be
2280    used to answer search and comparison queries, but will return
2281    referrals or contact other servers if modification operations are
2282    requested.  Servers that perform shadowing or caching MUST ensure
2283    that they do not violate any access control constraints placed on the
2284    data by the originating server.
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298 Zeilenga                    Standards Track                    [Page 41]
2299 \f
2300 RFC 4512                      LDAP Models                      June 2006
2301
2302
2303 7.  Implementation Guidelines
2304
2305 7.1.  Server Guidelines
2306
2307    Servers MUST recognize all names of attribute types and object
2308    classes defined in this document but, unless stated otherwise, need
2309    not support the associated functionality.  Servers SHOULD recognize
2310    all the names of attribute types and object classes defined in
2311    Section 3 and 4, respectively, of [RFC4519].
2312
2313    Servers MUST ensure that entries conform to user and system schema
2314    rules or other data model constraints.
2315
2316    Servers MAY support DIT Content Rules.  Servers MAY support DIT
2317    Structure Rules and Name Forms.
2318
2319    Servers MAY support alias entries.
2320
2321    Servers MAY support the 'extensibleObject' object class.
2322
2323    Servers MAY support subentries.  If so, they MUST do so in accordance
2324    with [RFC3672].  Servers that do not support subentries SHOULD use
2325    object entries to mimic subentries as detailed in Section 3.2.
2326
2327    Servers MAY implement additional schema elements.  Servers SHOULD
2328    provide definitions of all schema elements they support in subschema
2329    (sub)entries.
2330
2331 7.2.  Client Guidelines
2332
2333    In the absence of prior agreements with servers, clients SHOULD NOT
2334    assume that servers support any particular schema elements beyond
2335    those referenced in Section 7.1.  The client can retrieve subschema
2336    information as described in Section 4.4.
2337
2338    Clients MUST NOT display or attempt to decode a value as ASN.1 if the
2339    value's syntax is not known.  Clients MUST NOT assume the LDAP-
2340    specific string encoding is restricted to a UTF-8 encoded string of
2341    Unicode characters or any particular subset of Unicode (such as a
2342    printable subset) unless such restriction is explicitly stated.
2343    Clients SHOULD NOT send attribute values in a request that are not
2344    valid according to the syntax defined for the attributes.
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354 Zeilenga                    Standards Track                    [Page 42]
2355 \f
2356 RFC 4512                      LDAP Models                      June 2006
2357
2358
2359 8.  Security Considerations
2360
2361    Attributes of directory entries are used to provide descriptive
2362    information about the real-world objects they represent, which can be
2363    people, organizations, or devices.  Most countries have privacy laws
2364    regarding the publication of information about people.
2365
2366    General security considerations for accessing directory information
2367    with LDAP are discussed in [RFC4511] and [RFC4513].
2368
2369 9.  IANA Considerations
2370
2371    The Internet Assigned Numbers Authority (IANA) has updated the LDAP
2372    descriptors registry as indicated in the following template:
2373
2374       Subject: Request for LDAP Descriptor Registration Update
2375       Descriptor (short name): see comment
2376       Object Identifier: see comment
2377       Person & email address to contact for further information:
2378           Kurt Zeilenga <kurt@OpenLDAP.org>
2379       Usage: see comment
2380       Specification: RFC 4512
2381       Author/Change Controller: IESG
2382       Comments:
2383
2384       The following descriptors (short names) has been added to
2385       the registry.
2386
2387         NAME                         Type OID
2388         ------------------------     ---- -----------------
2389         governingStructureRule          A 2.5.21.10
2390         structuralObjectClass           A 2.5.21.9
2391
2392       The following descriptors (short names) have been updated to
2393       refer to this RFC.
2394
2395         NAME                         Type OID
2396         ------------------------     ---- -----------------
2397         alias                           O 2.5.6.1
2398         aliasedObjectName               A 2.5.4.1
2399         altServer                       A 1.3.6.1.4.1.1466.101.120.6
2400         attributeTypes                  A 2.5.21.5
2401         createTimestamp                 A 2.5.18.1
2402         creatorsName                    A 2.5.18.3
2403         dITContentRules                 A 2.5.21.2
2404         dITStructureRules               A 2.5.21.1
2405         extensibleObject                O 1.3.6.1.4.1.1466.101.120.111
2406         ldapSyntaxes                    A 1.3.6.1.4.1.1466.101.120.16
2407
2408
2409
2410 Zeilenga                    Standards Track                    [Page 43]
2411 \f
2412 RFC 4512                      LDAP Models                      June 2006
2413
2414
2415         matchingRuleUse                 A 2.5.21.8
2416         matchingRules                   A 2.5.21.4
2417         modifiersName                   A 2.5.18.4
2418         modifyTimestamp                 A 2.5.18.2
2419         nameForms                       A 2.5.21.7
2420         namingContexts                  A 1.3.6.1.4.1.1466.101.120.5
2421         objectClass                     A 2.5.4.0
2422         objectClasses                   A 2.5.21.6
2423         subschema                       O 2.5.20.1
2424         subschemaSubentry               A 2.5.18.10
2425         supportedControl                A 1.3.6.1.4.1.1466.101.120.13
2426         supportedExtension              A 1.3.6.1.4.1.1466.101.120.7
2427         supportedFeatures               A 1.3.6.1.4.1.4203.1.3.5
2428         supportedLDAPVersion            A 1.3.6.1.4.1.1466.101.120.15
2429         supportedSASLMechanisms         A 1.3.6.1.4.1.1466.101.120.14
2430         top                             O 2.5.6.0
2431
2432 10.  Acknowledgements
2433
2434    This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
2435    S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
2436    RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
2437    Indexing of Directories (ASID) Working Group.  This document is also
2438    based in part on "The Directory: Models" [X.501], a product of the
2439    International Telephone Union (ITU).  Additional text was borrowed
2440    from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
2441
2442    This document is a product of the IETF LDAP Revision (LDAPBIS)
2443    Working Group.
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466 Zeilenga                    Standards Track                    [Page 44]
2467 \f
2468 RFC 4512                      LDAP Models                      June 2006
2469
2470
2471 11.  Normative References
2472
2473    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
2474                  Requirement Levels", BCP 14, RFC 2119, March 1997.
2475
2476    [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
2477                  10646", STD 63, RFC 3629, November 2003.
2478
2479    [RFC3671]     Zeilenga, K., "Collective Attributes in the Lightweight
2480                  Directory Access Protocol (LDAP)", RFC 3671, December
2481                  2003.
2482
2483    [RFC3672]     Zeilenga, K., "Subentries in the Lightweight Directory
2484                  Access Protocol (LDAP)", RFC 3672, December 2003.
2485
2486    [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
2487                  Specifications: ABNF", RFC 4234, October 2005.
2488
2489    [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
2490                  Authentication and Security Layer (SASL)", RFC 4422,
2491                  June 2006.
2492
2493    [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
2494                  Protocol (LDAP): Technical Specification Road Map", RFC
2495                  4510, June 2006.
2496
2497    [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
2498                  Protocol (LDAP): The Protocol", RFC 4511, June 2006.
2499
2500    [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
2501                  Protocol (LDAP): Authentication Methods and Security
2502                  Mechanisms", RFC 4513, June 2006.
2503
2504    [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
2505                  Protocol (LDAP): String Representation of Distinguished
2506                  Names", RFC 4514, June 2006.
2507
2508    [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
2509                  Access Protocol (LDAP): String Representation of Search
2510                  Filters", RFC 4515, June 2006.
2511
2512    [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
2513                  Access Protocol (LDAP): Uniform Resource Locator", RFC
2514                  4516, June 2006.
2515
2516    [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
2517                  (LDAP): Syntaxes and Matching Rules", RFC 4517, June
2518                  2006.
2519
2520
2521
2522 Zeilenga                    Standards Track                    [Page 45]
2523 \f
2524 RFC 4512                      LDAP Models                      June 2006
2525
2526
2527    [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
2528                  Protocol (LDAP): Schema for User Applications", RFC
2529                  4519, June 2006.
2530
2531    [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
2532                  (IANA) Considerations for the Lightweight Directory
2533                  Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
2534
2535    [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
2536                  3.2.0" is defined by "The Unicode Standard, Version
2537                  3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
2538                  61633-5), as amended by the "Unicode Standard Annex
2539                  #27: Unicode 3.1"
2540                  (http://www.unicode.org/reports/tr27/) and by the
2541                  "Unicode Standard Annex #28: Unicode 3.2"
2542                  (http://www.unicode.org/reports/tr28/).
2543
2544    [X.500]       International Telecommunication Union -
2545                  Telecommunication Standardization Sector, "The
2546                  Directory -- Overview of concepts, models and
2547                  services," X.500(1993) (also ISO/IEC 9594-1:1994).
2548
2549    [X.501]       International Telecommunication Union -
2550                  Telecommunication Standardization Sector, "The
2551                  Directory -- Models," X.501(1993) (also ISO/IEC 9594-
2552                  2:1994).
2553
2554    [X.680]       International Telecommunication Union -
2555                  Telecommunication Standardization Sector, "Abstract
2556                  Syntax Notation One (ASN.1) - Specification of Basic
2557                  Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578 Zeilenga                    Standards Track                    [Page 46]
2579 \f
2580 RFC 4512                      LDAP Models                      June 2006
2581
2582
2583 Appendix A.  Changes
2584
2585    This appendix is non-normative.
2586
2587    This document amounts to nearly a complete rewrite of portions of RFC
2588    2251, RFC 2252, and RFC 2256.  This rewrite was undertaken to improve
2589    overall clarity of technical specification.  This appendix provides a
2590    summary of substantive changes made to the portions of these
2591    documents incorporated into this document.  Readers should consult
2592    [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
2593    remaining portions of these documents.
2594
2595 A.1.  Changes to RFC 2251
2596
2597    This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
2598    portions of Sections 4 and 6 as summarized below.
2599
2600 A.1.1.  Section 3.2 of RFC 2251
2601
2602    Section 3.2 of RFC 2251 provided a brief introduction to the X.500
2603    data model, as used by LDAP.  The previous specification relied on
2604    [X.501] but lacked clarity in how X.500 models are adapted for use by
2605    LDAP.  This document describes the X.500 data models, as used by
2606    LDAP, in greater detail, especially in areas where adaptation is
2607    needed.
2608
2609    Section 3.2.1 of RFC 2251 described an attribute as "a type with one
2610    or more associated values".  In LDAP, an attribute is better
2611    described as an attribute description, a type with zero or more
2612    options, and one or more associated values.
2613
2614    Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
2615    objectClasses and attributeTypes attributes, yet X.500(93) treats
2616    these attributes as optional.  While generally all implementations
2617    that support X.500(93) subschema mechanisms will provide both of
2618    these attributes, it is not absolutely required for interoperability
2619    that all servers do.  The mandate was removed for consistency with
2620    X.500(93).   The subschema discovery mechanism was also clarified to
2621    indicate that subschema controlling an entry is obtained by reading
2622    the (sub)entry referred to by that entry's 'subschemaSubentry'
2623    attribute.
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634 Zeilenga                    Standards Track                    [Page 47]
2635 \f
2636 RFC 4512                      LDAP Models                      June 2006
2637
2638
2639 A.1.2.  Section 3.4 of RFC 2251
2640
2641    Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
2642    This material, with changes, was incorporated in Section 5.1 of this
2643    document.
2644
2645    Changes:
2646
2647    - Clarify that attributes of the root DSE are subject to "other
2648      restrictions" in addition to access controls.
2649
2650    - Clarify that only recognized extended requests need to be
2651      enumerated 'supportedExtension'.
2652
2653    - Clarify that only recognized request controls need to be enumerated
2654      'supportedControl'.
2655
2656    - Clarify that root DSE attributes are operational and, like other
2657      operational attributes, will not be returned in search requests
2658      unless requested by name.
2659
2660    - Clarify that not all root DSE attributes are user modifiable.
2661
2662    - Remove inconsistent text regarding handling of the
2663      'subschemaSubentry' attribute within the root DSE.  The previous
2664      specification stated that the 'subschemaSubentry' attribute held in
2665      the root DSE referred to "subschema entries (or subentries) known
2666      by this server".  This is inconsistent with the attribute's
2667      intended use as well as its formal definition as a single valued
2668      attribute [X.501].  It is also noted that a simple (possibly
2669      incomplete) list of subschema (sub)entries is not terribly useful.
2670      This document (in Section 5.1) specifies that the
2671      'subschemaSubentry' attribute of the root DSE refers to the
2672      subschema controlling the root DSE.  It is noted that the general
2673      subschema discovery mechanism remains available (see Section 4.4 of
2674      this document).
2675
2676 A.1.3.  Section 4 of RFC 2251
2677
2678    Portions of Section 4 of RFC 2251 detailing aspects of the
2679    information model used by LDAP were incorporated in this document,
2680    including:
2681
2682    - Restriction of distinguished values to attributes whose
2683      descriptions have no options (from Section 4.1.3);
2684
2685
2686
2687
2688
2689
2690 Zeilenga                    Standards Track                    [Page 48]
2691 \f
2692 RFC 4512                      LDAP Models                      June 2006
2693
2694
2695    - Data model aspects of Attribute Types (from Section 4.1.4),
2696      Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
2697      Matching Rule Identifier (from 4.1.9); and
2698
2699    - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
2700
2701    Clarifications to these portions include:
2702
2703    - Subtyping and AttributeDescriptions with options.
2704
2705 A.1.4.  Section 6 of RFC 2251
2706
2707    The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
2708    where incorporated into this document.
2709
2710 A.2.  Changes to RFC 2252
2711
2712    This document incorporates Sections 4, 5, and 7 from RFC 2252.
2713
2714 A.2.1.  Section 4 of RFC 2252
2715
2716    The specification was updated to use Augmented BNF [RFC4234].  The
2717    string representation of an OBJECT IDENTIFIER was tightened to
2718    disallow leading zeros as described in RFC 2252.
2719
2720    The <descr> syntax was changed to disallow semicolon (U+003B)
2721    characters in order to appear to be consistent its natural language
2722    specification "descr is the syntactic representation of an object
2723    descriptor, which consists of letters and digits, starting with a
2724    letter".  In a related change, the statement "an AttributeDescription
2725    can be used as the value in a NAME part of an
2726    AttributeTypeDescription" was deleted.  RFC 2252 provided no
2727    specification of the semantics of attribute options appearing in NAME
2728    fields.
2729
2730    RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
2731    over the <numericoid> form.  However, <descr> form can be ambiguous.
2732    To address this issue, the imperative was replaced with a statement
2733    (in Section 1.4) that while the <descr> form is generally preferred,
2734    <numericoid> should be used where an unambiguous <descr> is not
2735    available.  Additionally, an expanded discussion of descriptor issues
2736    is in Section 6.2 ("Short Names").
2737
2738    The ABNF for a quoted string (qdstring) was updated to reflect
2739    support for the escaping mechanism described in Section 4.3 of RFC
2740    2252.
2741
2742
2743
2744
2745
2746 Zeilenga                    Standards Track                    [Page 49]
2747 \f
2748 RFC 4512                      LDAP Models                      June 2006
2749
2750
2751 A.2.2.  Section 5 of RFC 2252
2752
2753    Definitions of operational attributes provided in Section 5 of RFC
2754    2252 where incorporated into this document.
2755
2756    The 'namingContexts' description was clarified.  A first-level DSA
2757    should publish, in addition to other values, "" indicating the root
2758    of the DIT.
2759
2760    The 'altServer' description was clarified.  It may hold any URI.
2761
2762    The 'supportedExtension' description was clarified.  A server need
2763    only list the OBJECT IDENTIFIERs associated with the extended
2764    requests of the extended operations it recognizes.
2765
2766    The 'supportedControl' description was clarified.  A server need only
2767    list the OBJECT IDENTIFIERs associated with the request controls it
2768    recognizes.
2769
2770    Descriptions for the 'structuralObjectClass' and
2771    'governingStructureRule' operational attribute types were added.
2772
2773    The attribute definition of 'subschemaSubentry' was corrected to list
2774    the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
2775
2776 A.2.3.  Section 7 of RFC 2252
2777
2778    Section 7 of RFC 2252 provides definitions of the 'subschema' and
2779    'extensibleObject' object classes.  These definitions where
2780    integrated into Section 4.2 and Section 4.3 of this document,
2781    respectively.  Section 7 of RFC 2252 also contained the object class
2782    implementation requirement.  This was incorporated into Section 7 of
2783    this document.
2784
2785    The specification of 'extensibleObject' was clarified regarding how
2786    it interacts with precluded attributes.
2787
2788 A.3.  Changes to RFC 2256
2789
2790    This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2791    2256.
2792
2793    Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
2794    attribute type.  This was integrated into Section 2.4.1 of this
2795    document.  The statement "One of the values is either 'top' or
2796    'alias'" was replaced with statement that one of the values is 'top'
2797    as entries belonging to 'alias' also belong to 'top'.
2798
2799
2800
2801
2802 Zeilenga                    Standards Track                    [Page 50]
2803 \f
2804 RFC 4512                      LDAP Models                      June 2006
2805
2806
2807    Section 5.2 of RFC 2256 provided the definition of the
2808    'aliasedObjectName' attribute type.  This was integrated into Section
2809    2.6.2 of this document.
2810
2811    Section 7.1 of RFC 2256 provided the definition of the 'top' object
2812    class.  This was integrated into Section 2.4.1 of this document.
2813
2814    Section 7.2 of RFC 2256 provided the definition of the 'alias' object
2815    class.  This was integrated into Section 2.6.1 of this document.
2816
2817 A.4.  Changes to RFC 3674
2818
2819    This document made no substantive change to the 'supportedFeatures'
2820    technical specification provided in RFC 3674.
2821
2822 Editor's Address
2823
2824    Kurt D.  Zeilenga
2825    OpenLDAP Foundation
2826
2827    EMail: Kurt@OpenLDAP.org
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858 Zeilenga                    Standards Track                    [Page 51]
2859 \f
2860 RFC 4512                      LDAP Models                      June 2006
2861
2862
2863 Full Copyright Statement
2864
2865    Copyright (C) The Internet Society (2006).
2866
2867    This document is subject to the rights, licenses and restrictions
2868    contained in BCP 78, and except as set forth therein, the authors
2869    retain all their rights.
2870
2871    This document and the information contained herein are provided on an
2872    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2873    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2874    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2875    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2876    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2877    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2878
2879 Intellectual Property
2880
2881    The IETF takes no position regarding the validity or scope of any
2882    Intellectual Property Rights or other rights that might be claimed to
2883    pertain to the implementation or use of the technology described in
2884    this document or the extent to which any license under such rights
2885    might or might not be available; nor does it represent that it has
2886    made any independent effort to identify any such rights.  Information
2887    on the procedures with respect to rights in RFC documents can be
2888    found in BCP 78 and BCP 79.
2889
2890    Copies of IPR disclosures made to the IETF Secretariat and any
2891    assurances of licenses to be made available, or the result of an
2892    attempt made to obtain a general license or permission for the use of
2893    such proprietary rights by implementers or users of this
2894    specification can be obtained from the IETF on-line IPR repository at
2895    http://www.ietf.org/ipr.
2896
2897    The IETF invites any interested party to bring to its attention any
2898    copyrights, patents or patent applications, or other proprietary
2899    rights that may cover technology that may be required to implement
2900    this standard.  Please address the information to the IETF at
2901    ietf-ipr@ietf.org.
2902
2903 Acknowledgement
2904
2905    Funding for the RFC Editor function is provided by the IETF
2906    Administrative Support Activity (IASA).
2907
2908
2909
2910
2911
2912
2913
2914 Zeilenga                    Standards Track                    [Page 52]
2915 \f