From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc4512.txt | 2915 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2915 insertions(+)
 create mode 100644 doc/rfc/rfc4512.txt

(limited to 'doc/rfc/rfc4512.txt')

diff --git a/doc/rfc/rfc4512.txt b/doc/rfc/rfc4512.txt
new file mode 100644
index 0000000..f45a3f3
--- /dev/null
+++ b/doc/rfc/rfc4512.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4512                           OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2256, 3674                              June 2006
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                      Directory Information Models
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) is an Internet
+   protocol for accessing distributed directory services that act in
+   accordance with X.500 data and service models.  This document
+   describes the X.500 Directory Information Models, as used in LDAP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship to Other LDAP Specifications ..................3
+      1.2. Relationship to X.501 ......................................4
+      1.3. Conventions ................................................4
+      1.4. Common ABNF Productions ....................................4
+   2. Model of Directory User Information .............................6
+      2.1. The Directory Information Tree .............................7
+      2.2. Structure of an Entry ......................................7
+      2.3. Naming of Entries ..........................................8
+      2.4. Object Classes .............................................9
+      2.5. Attribute Descriptions ....................................12
+      2.6. Alias Entries .............................................16
+   3. Directory Administrative and Operational Information ...........17
+      3.1. Subtrees ..................................................17
+      3.2. Subentries ................................................18
+      3.3. The 'objectClass' attribute ...............................18
+      3.4. Operational Attributes ....................................19
+   4. Directory Schema ...............................................22
+      4.1. Schema Definitions ........................................23
+      4.2. Subschema Subentries ......................................32
+      4.3. 'extensibleObject' object class ...........................35
+      4.4. Subschema Discovery .......................................35
+   5. DSA (Server) Informational Model ...............................36
+      5.1. Server-Specific Data Requirements .........................36
+   6. Other Considerations ...........................................40
+      6.1. Preservation of User Information ..........................40
+      6.2. Short Names ...............................................41
+      6.3. Cache and Shadowing .......................................41
+   7. Implementation Guidelines ......................................42
+      7.1. Server Guidelines .........................................42
+      7.2. Client Guidelines .........................................42
+   8. Security Considerations ........................................43
+   9. IANA Considerations ............................................43
+   10. Acknowledgements ..............................................44
+   11. Normative References ..........................................45
+   Appendix A. Changes ...............................................47
+      A.1. Changes to RFC 2251 .......................................47
+      A.2. Changes to RFC 2252 .......................................49
+      A.3. Changes to RFC 2256 .......................................50
+      A.4. Changes to RFC 3674 .......................................51
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+1.  Introduction
+
+   This document discusses the X.500 Directory Information Models
+   [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+   [RFC4510].
+
+   The Directory is "a collection of open systems cooperating to provide
+   directory services" [X.500].  The information held in the Directory
+   is collectively known as the Directory Information Base (DIB).  A
+   Directory user, which may be a human or other entity, accesses the
+   Directory through a client (or Directory User Agent (DUA)).  The
+   client, on behalf of the directory user, interacts with one or more
+   servers (or Directory System Agents (DSA)).  A server holds a
+   fragment of the DIB.
+
+   The DIB contains two classes of information:
+
+      1) user information (e.g., information provided and administrated
+         by users).  Section 2 describes the Model of User Information.
+
+      2) administrative and operational information (e.g., information
+         used to administer and/or operate the directory).  Section 3
+         describes the model of Directory Administrative and Operational
+         Information.
+
+   These two models, referred to as the generic Directory Information
+   Models, describe how information is represented in the Directory.
+   These generic models provide a framework for other information
+   models.  Section 4 discusses the subschema information model and
+   subschema discovery.  Section 5 discusses the DSA (Server)
+   Informational Model.
+
+   Other X.500 information models (such as access control distribution
+   knowledge and replication knowledge information models) may be
+   adapted for use in LDAP.  Specification of how these models apply to
+   LDAP is left to future documents.
+
+1.1.  Relationship to Other LDAP Specifications
+
+   This document is a integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
+   portions of Sections 4 and 6.  Appendix A.1 summarizes changes to
+   these sections.  The remainder of RFC 2251 is obsoleted by the
+   [RFC4511], [RFC4513], and [RFC4510] documents.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   This document obsoletes RFC 2252, Sections 4, 5, and 7.  Appendix A.2
+   summarizes changes to these sections.  The remainder of RFC 2252 is
+   obsoleted by [RFC4517].
+
+   This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
+   Appendix A.3 summarizes changes to these sections.  The remainder of
+   RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
+
+   This document obsoletes RFC 3674 in its entirety.  Appendix A.4
+   summarizes changes since RFC 3674.
+
+1.2.  Relationship to X.501
+
+   This document includes material, with and without adaptation, from
+   [X.501] as necessary to describe this protocol.  These adaptations
+   (and any other differences herein) apply to this protocol, and only
+   this protocol.
+
+1.3.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Schema definitions are provided using LDAP description formats (as
+   defined in Section 4.1).  Definitions provided here are formatted
+   (line wrapped) for readability.  Matching rules and LDAP syntaxes
+   referenced in these definitions are specified in [RFC4517].
+
+1.4.  Common ABNF Productions
+
+   A number of syntaxes in this document are described using Augmented
+   Backus-Naur Form (ABNF) [RFC4234].  These syntaxes (as well as a
+   number of syntaxes defined in other documents) rely on the following
+   common productions:
+
+      keystring = leadkeychar *keychar
+      leadkeychar = ALPHA
+      keychar = ALPHA / DIGIT / HYPHEN
+      number  = DIGIT / ( LDIGIT 1*DIGIT )
+
+      ALPHA   = %x41-5A / %x61-7A   ; "A"-"Z" / "a"-"z"
+      DIGIT   = %x30 / LDIGIT       ; "0"-"9"
+      LDIGIT  = %x31-39             ; "1"-"9"
+      HEX     = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
+
+      SP      = 1*SPACE  ; one or more " "
+      WSP     = 0*SPACE  ; zero or more " "
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      NULL    = %x00 ; null (0)
+      SPACE   = %x20 ; space (" ")
+      DQUOTE  = %x22 ; quote (""")
+      SHARP   = %x23 ; octothorpe (or sharp sign) ("#")
+      DOLLAR  = %x24 ; dollar sign ("$")
+      SQUOTE  = %x27 ; single quote ("'")
+      LPAREN  = %x28 ; left paren ("(")
+      RPAREN  = %x29 ; right paren (")")
+      PLUS    = %x2B ; plus sign ("+")
+      COMMA   = %x2C ; comma (",")
+      HYPHEN  = %x2D ; hyphen ("-")
+      DOT     = %x2E ; period (".")
+      SEMI    = %x3B ; semicolon (";")
+      LANGLE  = %x3C ; left angle bracket ("<")
+      EQUALS  = %x3D ; equals sign ("=")
+      RANGLE  = %x3E ; right angle bracket (">")
+      ESC     = %x5C ; backslash ("\")
+      USCORE  = %x5F ; underscore ("_")
+      LCURLY  = %x7B ; left curly brace "{"
+      RCURLY  = %x7D ; right curly brace "}"
+
+      ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
+      UTF8    = UTF1 / UTFMB
+      UTFMB   = UTF2 / UTF3 / UTF4
+      UTF0    = %x80-BF
+      UTF1    = %x00-7F
+      UTF2    = %xC2-DF UTF0
+      UTF3    = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+                %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+      UTF4    = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+                %xF4 %x80-8F 2(UTF0)
+
+      OCTET   = %x00-FF ; Any octet (8-bit data unit)
+
+   Object identifiers (OIDs) [X.680] are represented in LDAP using a
+   dot-decimal format conforming to the ABNF:
+
+      numericoid = number 1*( DOT number )
+
+   Short names, also known as descriptors, are used as more readable
+   aliases for object identifiers.  Short names are case insensitive and
+   conform to the ABNF:
+
+      descr = keystring
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Where either an object identifier or a short name may be specified,
+   the following production is used:
+
+      oid = descr / numericoid
+
+   While the <descr> form is generally preferred when the usage is
+   restricted to short names referring to object identifiers that
+   identify like kinds of objects (e.g., attribute type descriptions,
+   matching rule descriptions, object class descriptions), the
+   <numericoid> form should be used when the object identifiers may
+   identify multiple kinds of objects or when an unambiguous short name
+   (descriptor) is not available.
+
+   Implementations SHOULD treat short names (descriptors) used in an
+   ambiguous manner (as discussed above) as unrecognized.
+
+   Short Names (descriptors) are discussed further in Section 6.2.
+
+2.  Model of Directory User Information
+
+   As [X.501] states:
+
+      The purpose of the Directory is to hold, and provide access to,
+      information about objects of interest (objects) in some 'world'.
+      An object can be anything which is identifiable (can be named).
+
+      An object class is an identified family of objects, or conceivable
+      objects, which share certain characteristics.  Every object
+      belongs to at least one class.  An object class may be a subclass
+      of other object classes, in which case the members of the former
+      class, the subclass, are also considered to be members of the
+      latter classes, the superclasses.  There may be subclasses of
+      subclasses, etc., to an arbitrary depth.
+
+   A directory entry, a named collection of information, is the basic
+   unit of information held in the Directory.  There are multiple kinds
+   of directory entries.
+
+   An object entry represents a particular object.  An alias entry
+   provides alternative naming.  A subentry holds administrative and/or
+   operational information.
+
+   The set of entries representing the DIB are organized hierarchically
+   in a tree structure known as the Directory Information Tree (DIT).
+
+   Section 2.1 describes the Directory Information Tree.
+   Section 2.2 discusses the structure of entries.
+   Section 2.3 discusses naming of entries.
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Section 2.4 discusses object classes.
+   Section 2.5 discusses attribute descriptions.
+   Section 2.6 discusses alias entries.
+
+2.1.  The Directory Information Tree
+
+   As noted above, the DIB is composed of a set of entries organized
+   hierarchically in a tree structure known as the Directory Information
+   Tree (DIT); specifically, a tree where vertices are the entries.
+
+   The arcs between vertices define relations between entries.  If an
+   arc exists from X to Y, then the entry at X is the immediate superior
+   of Y, and Y is the immediate subordinate of X.  An entry's superiors
+   are the entry's immediate superior and its superiors.  An entry's
+   subordinates are all of its immediate subordinates and their
+   subordinates.
+
+   Similarly, the superior/subordinate relationship between object
+   entries can be used to derive a relation between the objects they
+   represent.  DIT structure rules can be used to govern relationships
+   between objects.
+
+   Note: An entry's immediate superior is also known as the entry's
+         parent, and an entry's immediate subordinate is also known as
+         the entry's child.  Entries that have the same parent are known
+         as siblings.
+
+2.2.  Structure of an Entry
+
+   An entry consists of a set of attributes that hold information about
+   the object that the entry represents.  Some attributes represent user
+   information and are called user attributes.  Other attributes
+   represent operational and/or administrative information and are
+   called operational attributes.
+
+   An attribute is an attribute description (a type and zero or more
+   options) with one or more associated values.  An attribute is often
+   referred to by its attribute description.  For example, the
+   'givenName' attribute is the attribute that consists of the attribute
+   description 'givenName' (the 'givenName' attribute type [RFC4519] and
+   zero options) and one or more associated values.
+
+   The attribute type governs whether the attribute can have multiple
+   values, the syntax and matching rules used to construct and compare
+   values of that attribute, and other functions.  Options indicate
+   subtypes and other functions.
+
+   Attribute values conform to the defined syntax of the attribute type.
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   No two values of an attribute may be equivalent.  Two values are
+   considered equivalent if and only if they would match according to
+   the equality matching rule of the attribute type.  Or, if the
+   attribute type is defined with no equality matching rule, two values
+   are equivalent if and only if they are identical.  (See 2.5.1 for
+   other restrictions.)
+
+   For example, a 'givenName' attribute can have more than one value,
+   they must be Directory Strings, and they are case insensitive.  A
+   'givenName' attribute cannot hold both "John" and "JOHN", as these
+   are equivalent values per the equality matching rule of the attribute
+   type.
+
+   Additionally, no attribute is to have a value that is not equivalent
+   to itself.  For example, the 'givenName' attribute cannot have as a
+   value a directory string that includes the REPLACEMENT CHARACTER
+   (U+FFFD) code point, as matching involving that directory string is
+   Undefined per this attribute's equality matching rule.
+
+   When an attribute is used for naming of the entry, one and only one
+   value of the attribute is used in forming the Relative Distinguished
+   Name.  This value is known as a distinguished value.
+
+2.3.  Naming of Entries
+
+2.3.1.  Relative Distinguished Names
+
+   Each entry is named relative to its immediate superior.  This
+   relative name, known as its Relative Distinguished Name (RDN)
+   [X.501], is composed of an unordered set of one or more attribute
+   value assertions (AVA) consisting of an attribute description with
+   zero options and an attribute value.  These AVAs are chosen to match
+   attribute values (each a distinguished value) of the entry.
+
+   An entry's relative distinguished name must be unique among all
+   immediate subordinates of the entry's immediate superior (i.e., all
+   siblings).
+
+   The following are examples of string representations of RDNs
+   [RFC4514]:
+
+      UID=12345
+      OU=Engineering
+      CN=Kurt Zeilenga+L=Redwood Shores
+
+   The last is an example of a multi-valued RDN; that is, an RDN
+   composed of multiple AVAs.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+2.3.2.  Distinguished Names
+
+   An entry's fully qualified name, known as its Distinguished Name (DN)
+   [X.501], is the concatenation of its RDN and its immediate superior's
+   DN.  A Distinguished Name unambiguously refers to an entry in the
+   tree.  The following are examples of string representations of DNs
+   [RFC4514]:
+
+      UID=nobody@example.com,DC=example,DC=com
+      CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+2.3.3.  Alias Names
+
+   An alias, or alias name, is "an name for an object, provided by the
+   use of alias entries" [X.501].  Alias entries are described in
+   Section 2.6.
+
+2.4.  Object Classes
+
+   An object class is "an identified family of objects (or conceivable
+   objects) that share certain characteristics" [X.501].
+
+   As defined in [X.501]:
+
+      Object classes are used in the Directory for a number of purposes:
+
+        - describing and categorizing objects and the entries that
+          correspond to these objects;
+
+        - where appropriate, controlling the operation of the Directory;
+
+        - regulating, in conjunction with DIT structure rule
+          specifications, the position of entries in the DIT;
+
+        - regulating, in conjunction with DIT content rule
+          specifications, the attributes that are contained in entries;
+
+        - identifying classes of entry that are to be associated with a
+          particular policy by the appropriate administrative authority.
+
+      An object class (a subclass) may be derived from an object class
+      (its direct superclass) which is itself derived from an even more
+      generic object class.  For structural object classes, this process
+      stops at the most generic object class, 'top' (defined in Section
+      2.4.1).  An ordered set of superclasses up to the most superior
+      object class of an object class is its superclass chain.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      An object class may be derived from two or more direct
+      superclasses (superclasses not part of the same superclass chain).
+      This feature of subclassing is termed multiple inheritance.
+
+   Each object class identifies the set of attributes required to be
+   present in entries belonging to the class and the set of attributes
+   allowed to be present in entries belonging to the class.  As an entry
+   of a class must meet the requirements of each class it belongs to, it
+   can be said that an object class inherits the sets of allowed and
+   required attributes from its superclasses.  A subclass can identify
+   an attribute allowed by its superclass as being required.  If an
+   attribute is a member of both sets, it is required to be present.
+
+   Each object class is defined to be one of three kinds of object
+   classes: Abstract, Structural, or Auxiliary.
+
+   Each object class is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+2.4.1.  Abstract Object Classes
+
+   An abstract object class, as the name implies, provides a base of
+   characteristics from which other object classes can be defined to
+   inherit from.  An entry cannot belong to an abstract object class
+   unless it belongs to a structural or auxiliary class that inherits
+   from that abstract class.
+
+   Abstract object classes cannot derive from structural or auxiliary
+   object classes.
+
+   All structural object classes derive (directly or indirectly) from
+   the 'top' abstract object class.  Auxiliary object classes do not
+   necessarily derive from 'top'.
+
+   The following is the object class definition (see Section 4.1.1) for
+   the 'top' object class:
+
+      ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+   All entries belong to the 'top' abstract object class.
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+2.4.2.  Structural Object Classes
+
+   As stated in [X.501]:
+
+      An object class defined for use in the structural specification of
+      the DIT is termed a structural object class.  Structural object
+      classes are used in the definition of the structure of the names
+      of the objects for compliant entries.
+
+      An object or alias entry is characterized by precisely one
+      structural object class superclass chain which has a single
+      structural object class as the most subordinate object class.
+      This structural object class is referred to as the structural
+      object class of the entry.
+
+      Structural object classes are related to associated entries:
+
+        - an entry conforming to a structural object class shall
+          represent the real-world object constrained by the object
+          class;
+
+        - DIT structure rules only refer to structural object classes;
+          the structural object class of an entry is used to specify the
+          position of the entry in the DIT;
+
+        - the structural object class of an entry is used, along with an
+          associated DIT content rule, to control the content of an
+          entry.
+
+      The structural object class of an entry shall not be changed.
+
+   Each structural object class is a (direct or indirect) subclass of
+   the 'top' abstract object class.
+
+   Structural object classes cannot subclass auxiliary object classes.
+
+   Each entry is said to belong to its structural object class as well
+   as all classes in its structural object class's superclass chain.
+
+2.4.3.  Auxiliary Object Classes
+
+   Auxiliary object classes are used to augment the characteristics of
+   entries.  They are commonly used to augment the sets of attributes
+   required and allowed to be present in an entry.  They can be used to
+   describe entries or classes of entries.
+
+   Auxiliary object classes cannot subclass structural object classes.
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   An entry can belong to any subset of the set of auxiliary object
+   classes allowed by the DIT content rule associated with the
+   structural object class of the entry.  If no DIT content rule is
+   associated with the structural object class of the entry, the entry
+   cannot belong to any auxiliary object class.
+
+   The set of auxiliary object classes that an entry belongs to can
+   change over time.
+
+2.5.  Attribute Descriptions
+
+   An attribute description is composed of an attribute type (see
+   Section 2.5.1) and a set of zero or more attribute options (see
+   Section 2.5.2).
+
+   An attribute description is represented by the ABNF:
+
+      attributedescription = attributetype options
+      attributetype = oid
+      options = *( SEMI option )
+      option = 1*keychar
+
+   where <attributetype> identifies the attribute type and each <option>
+   identifies an attribute option.  Both <attributetype> and <option>
+   productions are case insensitive.  The order in which <option>s
+   appear is irrelevant.  That is, any two <attributedescription>s that
+   consist of the same <attributetype> and same set of <option>s are
+   equivalent.
+
+   Examples of valid attribute descriptions:
+
+      2.5.4.0
+      cn;lang-de;lang-en
+      owner
+
+   An attribute description with an unrecognized attribute type is to be
+   treated as unrecognized.  Servers SHALL treat an attribute
+   description with an unrecognized attribute option as unrecognized.
+   Clients MAY treat an unrecognized attribute option as a tagging
+   option (see Section 2.5.2.1).
+
+   All attributes of an entry must have distinct attribute descriptions.
+
+2.5.1.  Attribute Types
+
+   An attribute type governs whether the attribute can have multiple
+   values, the syntax and matching rules used to construct and compare
+   values of that attribute, and other functions.
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   If no equality matching is specified for the attribute type:
+
+      - the attribute (of the type) cannot be used for naming;
+      - when adding the attribute (or replacing all values), no two
+        values may be equivalent (see 2.2);
+      - individual values of a multi-valued attribute are not to be
+        independently added or deleted;
+      - attribute value assertions (such as matching in search filters
+        and comparisons) using values of such a type cannot be
+        performed.
+
+   Otherwise, the specified equality matching rule is to be used to
+   evaluate attribute value assertions concerning the attribute type.
+   The specified equality rule is to be transitive and commutative.
+
+   The attribute type indicates whether the attribute is a user
+   attribute or an operational attribute.  If operational, the attribute
+   type indicates the operational usage and whether or not the attribute
+   is modifiable by users.  Operational attributes are discussed in
+   Section 3.4.
+
+   An attribute type (a subtype) may derive from a more generic
+   attribute type (a direct supertype).  The following restrictions
+   apply to subtyping:
+
+      - a subtype must have the same usage as its direct supertype,
+      - a subtype's syntax must be the same, or a refinement of, its
+        supertype's syntax, and
+      - a subtype must be collective [RFC3671] if its supertype is
+        collective.
+
+   An attribute description consisting of a subtype and no options is
+   said to be the direct description subtype of the attribute
+   description consisting of the subtype's direct supertype and no
+   options.
+
+   Each attribute type is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+2.5.2.  Attribute Options
+
+   There are multiple kinds of attribute description options.  The LDAP
+   technical specification details one kind: tagging options.
+
+   Not all options can be associated with attributes held in the
+   directory.  Tagging options can be.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Not all options can be used in conjunction with all attribute types.
+   In such cases, the attribute description is to be treated as
+   unrecognized.
+
+   An attribute description that contains mutually exclusive options
+   shall be treated as unrecognized.  That is, "cn;x-bar;x-foo", where
+   "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+   unrecognized.
+
+   Other kinds of options may be specified in future documents.  These
+   documents must detail how new kinds of options they define relate to
+   tagging options.  In particular, these documents must detail whether
+   or not new kinds of options can be associated with attributes held in
+   the directory, how new kinds of options affect transfer of attribute
+   values, and how new kinds of options are treated in attribute
+   description hierarchies.
+
+   Options are represented as short, case-insensitive textual strings
+   conforming to the <option> production defined in Section 2.5 of this
+   document.
+
+   Procedures for registering options are detailed in BCP 64, RFC 4520
+   [RFC4520].
+
+2.5.2.1.  Tagging Options
+
+   Attributes held in the directory can have attribute descriptions with
+   any number of tagging options.  Tagging options are never mutually
+   exclusive.
+
+   An attribute description with N tagging options is a direct
+   (description) subtype of all attribute descriptions of the same
+   attribute type and all but one of the N options.  If the attribute
+   type has a supertype, then the attribute description is also a direct
+   (description) subtype of the attribute description of the supertype
+   and the N tagging options.  That is, 'cn;lang-de;lang-en' is a direct
+   (description) subtype of 'cn;lang-de', 'cn;lang-en', and
+   'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
+   in [RFC4519]).
+
+2.5.3.  Attribute Description Hierarchies
+
+   An attribute description can be the direct subtype of zero or more
+   other attribute descriptions as indicated by attribute type subtyping
+   (as described in Section 2.5.1) or attribute tagging option subtyping
+   (as described in Section 2.5.2.1).  These subtyping relationships are
+   used to form hierarchies of attribute descriptions and attributes.
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   As adapted from [X.501]:
+
+      Attribute hierarchies allow access to the DIB with varying degrees
+      of granularity.  This is achieved by allowing the value components
+      of attributes to be accessed by using either their specific
+      attribute description (a direct reference to the attribute) or a
+      more generic attribute description (an indirect reference).
+
+      Semantically related attributes may be placed in a hierarchical
+      relationship, the more specialized being placed subordinate to the
+      more generalized.  Searching for or retrieving attributes and
+      their values is made easier by quoting the more generalized
+      attribute description; a filter item so specified is evaluated for
+      the more specialized descriptions as well as for the quoted
+      description.
+
+      Where subordinate specialized descriptions are selected to be
+      returned as part of a search result these descriptions shall be
+      returned if available.  Where the more general descriptions are
+      selected to be returned as part of a search result both the
+      general and the specialized descriptions shall be returned, if
+      available.  An attribute value shall always be returned as a value
+      of its own attribute description.
+
+      All of the attribute descriptions in an attribute hierarchy are
+      treated as distinct and unrelated descriptions for user
+      modification of entry content.
+
+      An attribute value stored in an object or alias entry is of
+      precisely one attribute description.  The description is indicated
+      when the value is originally added to the entry.
+
+   For the purpose of subschema administration of the entry, a
+   specification that an attribute is required is fulfilled if the entry
+   contains a value of an attribute description belonging to an
+   attribute hierarchy where the attribute type of that description is
+   the same as the required attribute's type.  That is, a "MUST name"
+   specification is fulfilled by 'name' or 'name;x-tag-option', but is
+   not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
+   subtype of 'name').  Likewise, an entry may contain a value of an
+   attribute description belonging to an attribute hierarchy where the
+   attribute type of that description is either explicitly included in
+   the definition of an object class to which the entry belongs or
+   allowed by the DIT content rule applicable to that entry.  That is,
+   'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
+   name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
+   (or by "MUST name").
+
+
+
+
+Zeilenga                    Standards Track                    [Page 15]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   For the purposes of other policy administration, unless stated
+   otherwise in the specification of the particular administrative
+   model, all of the attribute descriptions in an attribute hierarchy
+   are treated as distinct and unrelated descriptions.
+
+2.6.  Alias Entries
+
+   As adapted from [X.501]:
+
+      An alias, or an alias name, for an object is an alternative name
+      for an object or object entry which is provided by the use of
+      alias entries.
+
+      Each alias entry contains, within the 'aliasedObjectName'
+      attribute (known as the 'aliasedEntryName' attribute in X.500), a
+      name of some object.  The distinguished name of the alias entry is
+      thus also a name for this object.
+
+          NOTE - The name within the 'aliasedObjectName' is said to be
+                 pointed to by the alias.  It does not have to be the
+                 distinguished name of any entry.
+
+      The conversion of an alias name to an object name is termed
+      (alias) dereferencing and comprises the systematic replacement of
+      alias names, where found within a purported name, by the value of
+      the corresponding 'aliasedObjectName' attribute.  The process may
+      require the examination of more than one alias entry.
+
+      Any particular entry in the DIT may have zero or more alias names.
+      It therefore follows that several alias entries may point to the
+      same entry.  An alias entry may point to an entry that is not a
+      leaf entry and may point to another alias entry.
+
+      An alias entry shall have no subordinates, so that an alias entry
+      is always a leaf entry.
+
+      Every alias entry shall belong to the 'alias' object class.
+
+   An entry with the 'alias' object class must also belong to an object
+   class (or classes), or be governed by a DIT content rule, which
+   allows suitable naming attributes to be present.
+
+   Example:
+
+      dn: cn=bar,dc=example,dc=com
+      objectClass: top
+      objectClass: alias
+      objectClass: extensibleObject
+
+
+
+Zeilenga                    Standards Track                    [Page 16]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      cn: bar
+      aliasedObjectName: cn=foo,dc=example,dc=com
+
+2.6.1.  'alias' Object Class
+
+   Alias entries belong to the 'alias' object class.
+
+      ( 2.5.6.1 NAME 'alias'
+        SUP top STRUCTURAL
+        MUST aliasedObjectName )
+
+2.6.2.  'aliasedObjectName' Attribute Type
+
+   The 'aliasedObjectName' attribute holds the name of the entry an
+   alias points to.  The 'aliasedObjectName' attribute is known as the
+   'aliasedEntryName' attribute in X.500.
+
+      ( 2.5.4.1 NAME 'aliasedObjectName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE )
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.  Directory Administrative and Operational Information
+
+   This section discusses select aspects of the X.500 Directory
+   Administrative and Operational Information model [X.501].  LDAP
+   implementations MAY support other aspects of this model.
+
+3.1.  Subtrees
+
+   As defined in [X.501]:
+
+      A subtree is a collection of object and alias entries situated at
+      the vertices of a tree.  Subtrees do not contain subentries.  The
+      prefix sub, in subtree, emphasizes that the base (or root) vertex
+      of this tree is usually subordinate to the root of the DIT.
+
+      A subtree begins at some vertex and extends to some identifiable
+      lower boundary, possibly extending to leaves.  A subtree is always
+      defined within a context which implicitly bounds the subtree.  For
+      example, the vertex and lower boundaries of a subtree defining a
+      replicated area are bounded by a naming context.
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 17]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+3.2.  Subentries
+
+   A subentry is a "special sort of entry, known by the Directory, used
+   to hold information associated with a subtree or subtree refinement"
+   [X.501].  Subentries are used in Directory to hold for administrative
+   and operational purposes as defined in [X.501].  Their use in LDAP is
+   detailed in [RFC3672].
+
+   The term "(sub)entry" in this specification indicates that servers
+   implementing X.500(93) models are, in accordance with X.500(93) as
+   described in [RFC3672], to use a subentry and that other servers are
+   to use an object entry belonging to the appropriate auxiliary class
+   normally used with the subentry (e.g., 'subschema' for subschema
+   subentries) to mimic the subentry.  This object entry's RDN SHALL be
+   formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
+   all subentries are named with 'cn').
+
+3.3.  The 'objectClass' attribute
+
+   Each entry in the DIT has an 'objectClass' attribute.
+
+      ( 2.5.4.0 NAME 'objectClass'
+        EQUALITY objectIdentifierMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+   The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
+   (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
+
+   The 'objectClass' attribute specifies the object classes of an entry,
+   which (among other things) are used in conjunction with the
+   controlling schema to determine the permitted attributes of an entry.
+   Values of this attribute can be modified by clients, but the
+   'objectClass' attribute cannot be removed.
+
+   Servers that follow X.500(93) models SHALL restrict modifications of
+   this attribute to prevent the basic structural class of the entry
+   from being changed.  That is, one cannot change a 'person' into a
+   'country'.
+
+   When creating an entry or adding an 'objectClass' value to an entry,
+   all superclasses of the named classes SHALL be implicitly added as
+   well if not already present.  That is, if the auxiliary class 'x-a'
+   is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
+   causes 'x-b' to be implicitly added (if is not already present).
+
+   Servers SHALL restrict modifications of this attribute to prevent
+   superclasses of remaining 'objectClass' values from being deleted.
+   That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+
+
+
+Zeilenga                    Standards Track                    [Page 18]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+   an attempt to delete only 'x-b' from the 'objectClass' attribute is
+   an error.
+
+3.4.  Operational Attributes
+
+   Some attributes, termed operational attributes, are used or
+   maintained by servers for administrative and operational purposes.
+   As stated in [X.501]: "There are three varieties of operational
+   attributes:  Directory operational attributes, DSA-shared operational
+   attributes, and DSA-specific operational attributes".
+
+   A directory operational attribute is used to represent operational
+   and/or administrative information in the Directory Information Model.
+   This includes operational attributes maintained by the server (e.g.,
+   'createTimestamp') as well as operational attributes that hold values
+   administrated by the user (e.g., 'ditContentRules').
+
+   A DSA-shared operational attribute is used to represent information
+   of the DSA Information Model that is shared between DSAs.
+
+   A DSA-specific operational attribute is used to represent information
+   of the DSA Information Model that is specific to the DSA (though, in
+   some cases, may be derived from information shared between DSAs;
+   e.g., 'namingContexts').
+
+   The DSA Information Model operational attributes are detailed in
+   [X.501].
+
+   Operational attributes are not normally visible.  They are not
+   returned in search results unless explicitly requested by name.
+
+   Not all operational attributes are user modifiable.
+
+   Entries may contain, among others, the following operational
+   attributes:
+
+      - creatorsName: the Distinguished Name of the user who added this
+          entry to the directory,
+
+      - createTimestamp: the time this entry was added to the directory,
+
+      - modifiersName: the Distinguished Name of the user who last
+          modified this entry, and
+
+      - modifyTimestamp: the time this entry was last modified.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 19]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+   'modifiersName', and 'modifyTimestamp' attributes for all entries of
+   the DIT.
+
+3.4.1.  'creatorsName'
+
+   This attribute appears in entries that were added using the protocol
+   (e.g., using the Add operation).  The value is the distinguished name
+   of the creator.
+
+      ( 2.5.18.3 NAME 'creatorsName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.2.  'createTimestamp'
+
+   This attribute appears in entries that were added using the protocol
+   (e.g., using the Add operation).  The value is the time the entry was
+   added.
+
+      ( 2.5.18.1 NAME 'createTimestamp'
+        EQUALITY generalizedTimeMatch
+        ORDERING generalizedTimeOrderingMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+   matching rules and the GeneralizedTime
+   (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.3.  'modifiersName'
+
+   This attribute appears in entries that have been modified using the
+   protocol (e.g., using the Modify operation).  The value is the
+   distinguished name of the last modifier.
+
+      ( 2.5.18.4 NAME 'modifiersName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+
+
+
+Zeilenga                    Standards Track                    [Page 20]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.4.  'modifyTimestamp'
+
+   This attribute appears in entries that have been modified using the
+   protocol (e.g., using the Modify operation).  The value is the time
+   the entry was last modified.
+
+      ( 2.5.18.2 NAME 'modifyTimestamp'
+        EQUALITY generalizedTimeMatch
+        ORDERING generalizedTimeOrderingMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+   matching rules and the GeneralizedTime
+   (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.5.  'structuralObjectClass'
+
+   This attribute indicates the structural object class of the entry.
+
+      ( 2.5.21.9 NAME 'structuralObjectClass'
+        EQUALITY objectIdentifierMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+   (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
+
+3.4.6.  'governingStructureRule'
+
+   This attribute indicates the structure rule governing the entry.
+
+      ( 2.5.21.10 NAME 'governingStructureRule'
+        EQUALITY integerMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'integerMatch' matching rule and INTEGER
+   (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 21]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.  Directory Schema
+
+   As defined in [X.501]:
+
+      The Directory Schema is a set of definitions and constraints
+      concerning the structure of the DIT, the possible ways entries are
+      named, the information that can be held in an entry, the
+      attributes used to represent that information and their
+      organization into hierarchies to facilitate search and retrieval
+      of the information and the ways in which values of attributes may
+      be matched in attribute value and matching rule assertions.
+
+      NOTE 1 - The schema enables the Directory system to, for example:
+
+      - prevent the creation of subordinate entries of the wrong
+        object-class (e.g., a country as a subordinate of a person);
+
+      - prevent the addition of attribute-types to an entry
+        inappropriate to the object-class (e.g., a serial number to a
+        person's entry);
+
+      - prevent the addition of an attribute value of a syntax not
+        matching that defined for the attribute-type (e.g., a printable
+        string to a bit string).
+
+      Formally, the Directory Schema comprises a set of:
+
+      a) Name Form definitions that define primitive naming relations
+         for structural object classes;
+
+      b) DIT Structure Rule definitions that define the names that
+         entries may have and the ways in which the entries may be
+         related to one another in the DIT;
+
+      c) DIT Content Rule definitions that extend the specification of
+         allowable attributes for entries beyond those indicated by the
+         structural object classes of the entries;
+
+      d) Object Class definitions that define the basic set of mandatory
+         and optional attributes that shall be present, and may be
+         present, respectively, in an entry of a given class, and which
+         indicate the kind of object class that is being defined;
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 22]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      e) Attribute Type definitions that identify the object identifier
+         by which an attribute is known, its syntax, associated matching
+         rules, whether it is an operational attribute and if so its
+         type, whether it is a collective attribute, whether it is
+         permitted to have multiple values and whether or not it is
+         derived from another attribute type;
+
+      f) Matching Rule definitions that define matching rules.
+
+      And in LDAP:
+
+      g) LDAP Syntax definitions that define encodings used in LDAP.
+
+4.1.  Schema Definitions
+
+   Schema definitions in this section are described using ABNF and rely
+   on the common productions specified in Section 1.2 as well as these:
+
+      noidlen = numericoid [ LCURLY len RCURLY ]
+      len = number
+
+      oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+      oidlist = oid *( WSP DOLLAR WSP oid )
+
+      extensions = *( SP xstring SP qdstrings )
+      xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+      qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+      qdescrlist = [ qdescr *( SP qdescr ) ]
+      qdescr = SQUOTE descr SQUOTE
+
+      qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+      qdstringlist = [ qdstring *( SP qdstring ) ]
+      qdstring = SQUOTE dstring SQUOTE
+      dstring = 1*( QS / QQ / QUTF8 )   ; escaped UTF-8 string
+
+      QQ =  ESC %x32 %x37 ; "\27"
+      QS =  ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+      ; Any UTF-8 encoded Unicode character
+      ; except %x27 ("\'") and %x5C ("\")
+      QUTF8    = QUTF1 / UTFMB
+
+      ; Any ASCII character except %x27 ("\'") and %x5C ("\")
+      QUTF1    = %x00-26 / %x28-5B / %x5D-7F
+
+   Schema definitions in this section also share a number of common
+   terms.
+
+
+
+Zeilenga                    Standards Track                    [Page 23]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   The NAME field provides a set of short names (descriptors) that are
+   to be used as aliases for the OID.
+
+   The DESC field optionally allows a descriptive string to be provided
+   by the directory administrator and/or implementor.  While
+   specifications may suggest a descriptive string, there is no
+   requirement that the suggested (or any) descriptive string be used.
+
+   The OBSOLETE field, if present, indicates the element is not active.
+
+   Implementors should note that future versions of this document may
+   expand these definitions to include additional terms.  Terms whose
+   identifier begins with "X-" are reserved for private experiments and
+   are followed by <SP> and <qdstrings> tokens.
+
+4.1.1.  Object Class Definitions
+
+   Object Class definitions are written according to the ABNF:
+
+     ObjectClassDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         [ SP "SUP" SP oids ]       ; superior object classes
+         [ SP kind ]                ; kind of class
+         [ SP "MUST" SP oids ]      ; attribute types
+         [ SP "MAY" SP oids ]       ; attribute types
+         extensions WSP RPAREN
+
+     kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+   where:
+     <numericoid> is object identifier assigned to this object class;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         object class;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this object class is not active;
+     SUP <oids> specifies the direct superclasses of this object class;
+     the kind of object class is indicated by one of ABSTRACT,
+         STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
+     MUST and MAY specify the sets of required and allowed attribute
+         types, respectively; and
+     <extensions> describe extensions.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 24]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.1.2.  Attribute Types
+
+   Attribute Type definitions are written according to the ABNF:
+
+     AttributeTypeDescription = LPAREN WSP
+         numericoid                    ; object identifier
+         [ SP "NAME" SP qdescrs ]      ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]     ; description
+         [ SP "OBSOLETE" ]             ; not active
+         [ SP "SUP" SP oid ]           ; supertype
+         [ SP "EQUALITY" SP oid ]      ; equality matching rule
+         [ SP "ORDERING" SP oid ]      ; ordering matching rule
+         [ SP "SUBSTR" SP oid ]        ; substrings matching rule
+         [ SP "SYNTAX" SP noidlen ]    ; value syntax
+         [ SP "SINGLE-VALUE" ]         ; single-value
+         [ SP "COLLECTIVE" ]           ; collective
+         [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+         [ SP "USAGE" SP usage ]       ; usage
+         extensions WSP RPAREN         ; extensions
+
+     usage = "userApplications"     /  ; user
+             "directoryOperation"   /  ; directory operational
+             "distributedOperation" /  ; DSA-shared operational
+             "dSAOperation"            ; DSA-specific operational
+
+   where:
+     <numericoid> is object identifier assigned to this attribute type;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         attribute type;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this attribute type is not active;
+     SUP oid specifies the direct supertype of this type;
+     EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
+         ordering, and substrings matching rules, respectively;
+     SYNTAX identifies value syntax by object identifier and may suggest
+         a minimum upper bound;
+     SINGLE-VALUE indicates attributes of this type are restricted to a
+         single value;
+     COLLECTIVE indicates this attribute type is collective
+         [X.501][RFC3671];
+     NO-USER-MODIFICATION indicates this attribute type is not user
+         modifiable;
+     USAGE indicates the application of this attribute type; and
+     <extensions> describe extensions.
+
+   Each attribute type description must contain at least one of the SUP
+   or SYNTAX fields.  If no SYNTAX field is provided, the attribute type
+   description takes its value from the supertype.
+
+
+
+Zeilenga                    Standards Track                    [Page 25]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
+   fields, if not specified, take their value from the supertype.
+
+   Usage of userApplications, the default, indicates that attributes of
+   this type represent user information.  That is, they are user
+   attributes.
+
+   A usage of directoryOperation, distributedOperation, or dSAOperation
+   indicates that attributes of this type represent operational and/or
+   administrative information.  That is, they are operational
+   attributes.
+
+   directoryOperation usage indicates that the attribute of this type is
+   a directory operational attribute.  distributedOperation usage
+   indicates that the attribute of this type is a DSA-shared usage
+   operational attribute.  dSAOperation usage indicates that the
+   attribute of this type is a DSA-specific operational attribute.
+
+   COLLECTIVE requires usage userApplications.  Use of collective
+   attribute types in LDAP is discussed in [RFC3671].
+
+   NO-USER-MODIFICATION requires an operational usage.
+
+   Note that the <AttributeTypeDescription> does not list the matching
+   rules that can be used with that attribute type in an extensibleMatch
+   search filter [RFC4511].  This is done using the 'matchingRuleUse'
+   attribute described in Section 4.1.4.
+
+   This document refines the schema description of X.501 by requiring
+   that the SYNTAX field in an <AttributeTypeDescription> be a string
+   representation of an object identifier for the LDAP string syntax
+   definition, with an optional indication of the suggested minimum
+   bound of a value of this attribute.
+
+   A suggested minimum upper bound on the number of characters in a
+   value with a string-based syntax, or the number of bytes in a value
+   for all other syntaxes, may be indicated by appending this bound
+   count inside of curly braces following the syntax's OBJECT IDENTIFIER
+   in an Attribute Type Description.  This bound is not part of the
+   syntax name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests
+   that server implementations should allow a string to be 64 characters
+   long, although they may allow longer strings.  Note that a single
+   character of the Directory String syntax may be encoded in more than
+   one octet since UTF-8 [RFC3629] is a variable-length encoding.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 26]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.1.3.  Matching Rules
+
+   Matching rules are used in performance of attribute value assertions,
+   such as in performance of a Compare operation.  They are also used in
+   evaluating search filters, determining which individual values are to
+   be added or deleted during performance of a Modify operation, and in
+   comparing distinguished names.
+
+   Each matching rule is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+   Matching rule definitions are written according to the ABNF:
+
+     MatchingRuleDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "SYNTAX" SP numericoid  ; assertion syntax
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is object identifier assigned to this matching rule;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         matching rule;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this matching rule is not active;
+     SYNTAX identifies the assertion syntax (the syntax of the assertion
+         value) by object identifier; and
+     <extensions> describe extensions.
+
+4.1.4.  Matching Rule Uses
+
+   A matching rule use lists the attribute types that are suitable for
+   use with an extensibleMatch search filter.
+
+   Matching rule use descriptions are written according to the following
+   ABNF:
+
+     MatchingRuleUseDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "APPLIES" SP oids       ; attribute types
+         extensions WSP RPAREN      ; extensions
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 27]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   where:
+     <numericoid> is the object identifier of the matching rule
+         associated with this matching rule use description;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         matching rule use;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this matching rule use is not active;
+     APPLIES provides a list of attribute types the matching rule
+         applies to; and
+     <extensions> describe extensions.
+
+4.1.5.  LDAP Syntaxes
+
+   LDAP Syntaxes of (attribute and assertion) values are described in
+   terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+   known as the LDAP-specific encoding.  Commonly, the LDAP-specific
+   encoding is constrained to a string of Unicode [Unicode] characters
+   in UTF-8 [RFC3629] form.
+
+   Each LDAP syntax is identified by an object identifier (OID).
+
+   LDAP syntax definitions are written according to the ABNF:
+
+     SyntaxDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "DESC" SP qdstring ]  ; description
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is the object identifier assigned to this LDAP syntax;
+     DESC <qdstring> is a short descriptive string; and
+     <extensions> describe extensions.
+
+4.1.6.  DIT Content Rules
+
+   A DIT content rule is a "rule governing the content of entries of a
+   particular structural object class" [X.501].
+
+   For DIT entries of a particular structural object class, a DIT
+   content rule specifies which auxiliary object classes the entries are
+   allowed to belong to and which additional attributes (by type) are
+   required, allowed, or not allowed to appear in the entries.
+
+   The list of precluded attributes cannot include any attribute listed
+   as mandatory in the rule, the structural object class, or any of the
+   allowed auxiliary object classes.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 28]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Each content rule is identified by the object identifier, as well as
+   any short names (descriptors), of the structural object class it
+   applies to.
+
+   An entry may only belong to auxiliary object classes listed in the
+   governing content rule.
+
+   An entry must contain all attributes required by the object classes
+   the entry belongs to as well as all attributes required by the
+   governing content rule.
+
+   An entry may contain any non-precluded attributes allowed by the
+   object classes the entry belongs to as well as all attributes allowed
+   by the governing content rule.
+
+   An entry cannot include any attribute precluded by the governing
+   content rule.
+
+   An entry is governed by (if present and active in the subschema) the
+   DIT content rule that applies to the structural object class of the
+   entry (see Section 2.4.2).  If no active rule is present for the
+   entry's structural object class, the entry's content is governed by
+   the structural object class (and possibly other aspects of user and
+   system schema).  DIT content rules for superclasses of the structural
+   object class of an entry are not applicable to that entry.
+
+   DIT content rule descriptions are written according to the ABNF:
+
+     DITContentRuleDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         [ SP "AUX" SP oids ]       ; auxiliary object classes
+         [ SP "MUST" SP oids ]      ; attribute types
+         [ SP "MAY" SP oids ]       ; attribute types
+         [ SP "NOT" SP oids ]       ; attribute types
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is the object identifier of the structural object
+         class associated with this DIT content rule;
+     NAME <qdescrs> are short names (descriptors) identifying this DIT
+         content rule;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this DIT content rule use is not active;
+     AUX specifies a list of auxiliary object classes that entries
+         subject to this DIT content rule may belong to;
+
+
+
+Zeilenga                    Standards Track                    [Page 29]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+     MUST, MAY, and NOT specify lists of attribute types that are
+         required, allowed, or precluded, respectively, from appearing
+         in entries subject to this DIT content rule; and
+     <extensions> describe extensions.
+
+4.1.7.  DIT Structure Rules and Name Forms
+
+   It is sometimes desirable to regulate where object and alias entries
+   can be placed in the DIT and how they can be named based upon their
+   structural object class.
+
+4.1.7.1.  DIT Structure Rules
+
+   A DIT structure rule is a "rule governing the structure of the DIT by
+   specifying a permitted superior to subordinate entry relationship.  A
+   structure rule relates a name form, and therefore a structural object
+   class, to superior structure rules.  This permits entries of the
+   structural object class identified by the name form to exist in the
+   DIT as subordinates to entries governed by the indicated superior
+   structure rules" [X.501].
+
+   DIT structure rule descriptions are written according to the ABNF:
+
+     DITStructureRuleDescription = LPAREN WSP
+         ruleid                     ; rule identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "FORM" SP oid           ; NameForm
+         [ SP "SUP" ruleids ]       ; superior rules
+         extensions WSP RPAREN      ; extensions
+
+     ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+     ruleidlist = ruleid *( SP ruleid )
+     ruleid = number
+
+   where:
+     <ruleid> is the rule identifier of this DIT structure rule;
+     NAME <qdescrs> are short names (descriptors) identifying this DIT
+         structure rule;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this DIT structure rule use is not active;
+     FORM is specifies the name form associated with this DIT structure
+         rule;
+     SUP identifies superior rules (by rule id); and
+     <extensions> describe extensions.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 30]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   If no superior rules are identified, the DIT structure rule applies
+   to an autonomous administrative point (e.g., the root vertex of the
+   subtree controlled by the subschema) [X.501].
+
+4.1.7.2.  Name Forms
+
+   A name form "specifies a permissible RDN for entries of a particular
+   structural object class.  A name form identifies a named object class
+   and one or more attribute types to be used for naming (i.e., for the
+   RDN).  Name forms are primitive pieces of specification used in the
+   definition of DIT structure rules" [X.501].
+
+   Each name form indicates the structural object class to be named, a
+   set of required attribute types, and a set of allowed attribute
+   types.  A particular attribute type cannot be in both sets.
+
+   Entries governed by the form must be named using a value from each
+   required attribute type and zero or more values from the allowed
+   attribute types.
+
+   Each name form is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+   Name form descriptions are written according to the ABNF:
+
+     NameFormDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "OC" SP oid             ; structural object class
+         SP "MUST" SP oids          ; attribute types
+         [ SP "MAY" SP oids ]       ; attribute types
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is object identifier that identifies this name form;
+     NAME <qdescrs> are short names (descriptors) identifying this name
+         form;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this name form is not active;
+     OC identifies the structural object class this rule applies to,
+     MUST and MAY specify the sets of required and allowed,
+         respectively, naming attributes for this name form; and
+     <extensions> describe extensions.
+
+   All attribute types in the required ("MUST") and allowed ("MAY")
+   lists shall be different.
+
+
+
+Zeilenga                    Standards Track                    [Page 31]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.2.  Subschema Subentries
+
+   Subschema (sub)entries are used for administering information about
+   the directory schema.  A single subschema (sub)entry contains all
+   schema definitions (see Section 4.1) used by entries in a particular
+   part of the directory tree.
+
+   Servers that follow X.500(93) models SHOULD implement subschema using
+   the X.500 subschema mechanisms (as detailed in Section 12 of
+   [X.501]), so these are not ordinary object entries but subentries
+   (see Section 3.2).  LDAP clients SHOULD NOT assume that servers
+   implement any of the other aspects of X.500 subschema.
+
+   Servers MAY allow subschema modification.  Procedures for subschema
+   modification are discussed in Section 14.5 of [X.501].
+
+   A server that masters entries and permits clients to modify these
+   entries SHALL implement and provide access to these subschema
+   (sub)entries including providing a 'subschemaSubentry' attribute in
+   each modifiable entry.  This is so clients may discover the
+   attributes and object classes that are permitted to be present.  It
+   is strongly RECOMMENDED that all other servers implement this as
+   well.
+
+   The value of the 'subschemaSubentry' attribute is the name of the
+   subschema (sub)entry holding the subschema controlling the entry.
+
+      ( 2.5.18.10 NAME 'subschemaSubentry'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+   Subschema is held in (sub)entries belonging to the subschema
+   auxiliary object class.
+
+      ( 2.5.20.1 NAME 'subschema' AUXILIARY
+        MAY ( dITStructureRules $ nameForms $ ditContentRules $
+          objectClasses $ attributeTypes $ matchingRules $
+          matchingRuleUse ) )
+
+   The 'ldapSyntaxes' operational attribute may also be present in
+   subschema entries.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 32]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Servers MAY provide additional attributes (described in other
+   documents) in subschema (sub)entries.
+
+   Servers SHOULD provide the attributes 'createTimestamp' and
+   'modifyTimestamp' in subschema (sub)entries, in order to allow
+   clients to maintain their caches of schema information.
+
+   The following subsections provide attribute type definitions for each
+   of schema definition attribute types.
+
+4.2.1.  'objectClasses'
+
+   This attribute holds definitions of object classes.
+
+      ( 2.5.21.6 NAME 'objectClasses'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+   defined in [RFC4517].
+
+4.2.2.  'attributeTypes'
+
+   This attribute holds definitions of attribute types.
+
+      ( 2.5.21.5 NAME 'attributeTypes'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+   defined in [RFC4517].
+
+4.2.3.  'matchingRules'
+
+   This attribute holds definitions of matching rules.
+
+      ( 2.5.21.4 NAME 'matchingRules'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+   defined in [RFC4517].
+
+
+
+Zeilenga                    Standards Track                    [Page 33]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.2.4 'matchingRuleUse'
+
+   This attribute holds definitions of matching rule uses.
+
+      ( 2.5.21.8 NAME 'matchingRuleUse'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+   defined in [RFC4517].
+
+4.2.5.  'ldapSyntaxes'
+
+   This attribute holds definitions of LDAP syntaxes.
+
+      ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+   in [RFC4517].
+
+4.2.6.  'dITContentRules'
+
+   This attribute lists DIT Content Rules that are present in the
+   subschema.
+
+      ( 2.5.21.2 NAME 'dITContentRules'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+   defined in [RFC4517].
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 34]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.2.7.  'dITStructureRules'
+
+   This attribute lists DIT Structure Rules that are present in the
+   subschema.
+
+      ( 2.5.21.1 NAME 'dITStructureRules'
+        EQUALITY integerFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+        USAGE directoryOperation )
+
+   The 'integerFirstComponentMatch' matching rule and the
+   DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
+   are defined in [RFC4517].
+
+4.2.8 'nameForms'
+
+   This attribute lists Name Forms that are in force.
+
+      ( 2.5.21.7 NAME 'nameForms'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
+   defined in [RFC4517].
+
+4.3.  'extensibleObject' object class
+
+   The 'extensibleObject' auxiliary object class allows entries that
+   belong to it to hold any user attribute.  The set of allowed
+   attribute types of this object class is implicitly the set of all
+   attribute types of userApplications usage.
+
+      ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+        SUP top AUXILIARY )
+
+   The mandatory attributes of the other object classes of this entry
+   are still required to be present, and any precluded attributes are
+   still not allowed to be present.
+
+4.4.  Subschema Discovery
+
+   To discover the DN of the subschema (sub)entry holding the subschema
+   controlling a particular entry, a client reads that entry's
+   'subschemaSubentry' operational attribute.  To read schema attributes
+   from the subschema (sub)entry, clients MUST issue a Search operation
+   [RFC4511] where baseObject is the DN of the subschema (sub)entry,
+
+
+
+Zeilenga                    Standards Track                    [Page 35]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
+   and the attributes field lists the names of the desired schema
+   attributes (as they are operational).  Note: the
+   "(objectClass=subschema)" filter allows LDAP servers that gateway to
+   X.500 to detect that subentry information is being requested.
+
+   Clients SHOULD NOT assume that a published subschema is complete,
+   that the server supports all of the schema elements it publishes, or
+   that the server does not support an unpublished element.
+
+5.  DSA (Server) Informational Model
+
+   The LDAP protocol assumes there are one or more servers that jointly
+   provide access to a Directory Information Tree (DIT).  The server
+   holding the original information is called the "master" (for that
+   information).  Servers that hold copies of the original information
+   are referred to as "shadowing" or "caching" servers.
+
+
+   As defined in [X.501]:
+
+      context prefix: The sequence of RDNs leading from the Root of the
+          DIT to the initial vertex of a naming context; corresponds to
+          the distinguished name of that vertex.
+
+      naming context: A subtree of entries held in a single master DSA.
+
+   That is, a naming context is the largest collection of entries,
+   starting at an entry that is mastered by a particular server, and
+   including all its subordinates and their subordinates, down to the
+   entries that are mastered by different servers.  The context prefix
+   is the name of the initial entry.
+
+   The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+   naming context (or any subtree); each server has different attribute
+   values in the root DSE.
+
+5.1.  Server-Specific Data Requirements
+
+   An LDAP server SHALL provide information about itself and other
+   information that is specific to each server.  This is represented as
+   a group of attributes located in the root DSE, which is named with
+   the DN with zero RDNs (whose [RFC4514] representation is as the
+   zero-length string).
+
+   These attributes are retrievable, subject to access control and other
+   restrictions, if a client performs a Search operation [RFC4511] with
+   an empty baseObject, scope of baseObject, the filter
+
+
+
+Zeilenga                    Standards Track                    [Page 36]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   "(objectClass=*)" [RFC4515], and the attributes field listing the
+   names of the desired attributes.  It is noted that root DSE
+   attributes are operational and, like other operational attributes,
+   are not returned in search requests unless requested by name.
+
+   The root DSE SHALL NOT be included if the client performs a subtree
+   search starting from the root.
+
+   Servers may allow clients to modify attributes of the root DSE, where
+   appropriate.
+
+   The following attributes of the root DSE are defined below.
+   Additional attributes may be defined in other documents.
+
+      - altServer: alternative servers;
+
+      - namingContexts: naming contexts;
+
+      - supportedControl: recognized LDAP controls;
+
+      - supportedExtension: recognized LDAP extended operations;
+
+      - supportedFeatures: recognized LDAP features;
+
+      - supportedLDAPVersion: LDAP versions supported; and
+
+      - supportedSASLMechanisms: recognized Simple Authentication and
+        Security Layers (SASL) [RFC4422] mechanisms.
+
+   The values provided for these attributes may depend on session-
+   specific and other factors.  For example, a server supporting the
+   SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
+   identity has been established by a lower level.  See [RFC4513].
+
+   The root DSE may also include a 'subschemaSubentry' attribute.  If it
+   does, the attribute refers to the subschema (sub)entry holding the
+   schema controlling the root DSE.  Clients SHOULD NOT assume that this
+   subschema (sub)entry controls other entries held by the server.
+   General subschema discovery procedures are provided in Section 4.4.
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 37]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+5.1.1.  'altServer'
+
+   The 'altServer' attribute lists URIs referring to alternative servers
+   that may be contacted when this server becomes unavailable.  URIs for
+   servers implementing the LDAP are written according to [RFC4516].
+   Other kinds of URIs may be provided.  If the server does not know of
+   any other servers that could be used, this attribute will be absent.
+   Clients may cache this information in case their preferred server
+   later becomes unavailable.
+
+      ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+        USAGE dSAOperation )
+
+   The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+   [RFC4517].
+
+5.1.2.  'namingContexts'
+
+   The 'namingContexts' attribute lists the context prefixes of the
+   naming contexts the server masters or shadows (in part or in whole).
+   If the server is a first-level DSA [X.501], it should list (in
+   addition) an empty string (indicating the root of the DIT).  If the
+   server does not master or shadow any information (e.g., it is an LDAP
+   gateway to a public X.500 directory) this attribute will be absent.
+   If the server believes it masters or shadows the entire directory,
+   the attribute will have a single value, and that value will be the
+   empty string (indicating the root of the DIT).
+
+   This attribute may be used, for example, to select a suitable entry
+   name for subsequent operations with this server.
+
+      ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        USAGE dSAOperation )
+
+   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+   defined in [RFC4517].
+
+5.1.3.  'supportedControl'
+
+   The 'supportedControl' attribute lists object identifiers identifying
+   the request controls [RFC4511] the server supports.  If the server
+   does not support any request controls, this attribute will be absent.
+   Object identifiers identifying response controls need not be listed.
+
+   Procedures for registering object identifiers used to discovery of
+   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+
+
+Zeilenga                    Standards Track                    [Page 38]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        USAGE dSAOperation )
+
+   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+   defined in [RFC4517].
+
+5.1.4.  'supportedExtension'
+
+   The 'supportedExtension' attribute lists object identifiers
+   identifying the extended operations [RFC4511] that the server
+   supports.  If the server does not support any extended operations,
+   this attribute will be absent.
+
+   An extended operation generally consists of an extended request and
+   an extended response but may also include other protocol data units
+   (such as intermediate responses).  The object identifier assigned to
+   the extended request is used to identify the extended operation.
+   Other object identifiers used in the extended operation need not be
+   listed as values of this attribute.
+
+   Procedures for registering object identifiers used to discovery of
+   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+      ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        USAGE dSAOperation )
+
+   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+   defined in [RFC4517].
+
+5.1.5.  'supportedFeatures'
+
+   The 'supportedFeatures' attribute lists object identifiers
+   identifying elective features that the server supports.  If the
+   server does not support any discoverable elective features, this
+   attribute will be absent.
+
+      ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+          EQUALITY objectIdentifierMatch
+          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+          USAGE dSAOperation )
+
+   Procedures for registering object identifiers used to discovery of
+   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+   objectIdentifierMatch matching rule are defined in [RFC4517].
+
+
+
+Zeilenga                    Standards Track                    [Page 39]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+5.1.6.  'supportedLDAPVersion'
+
+   The 'supportedLDAPVersion' attribute lists the versions of LDAP that
+   the server supports.
+
+      ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+        USAGE dSAOperation )
+
+   The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
+   [RFC4517].
+
+5.1.7.  'supportedSASLMechanisms'
+
+   The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+   [RFC4422] that the server recognizes and/or supports [RFC4513].  The
+   contents of this attribute may depend on the current session state.
+   If the server does not support any SASL mechanisms, this attribute
+   will not be present.
+
+      ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        USAGE dSAOperation )
+
+   The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   defined in [RFC4517].
+
+6.  Other Considerations
+
+6.1.  Preservation of User Information
+
+   Syntaxes may be defined that have specific value and/or value form
+   (representation) preservation requirements.  For example, a syntax
+   containing digitally signed data can mandate that the server preserve
+   both the value and form of value presented to ensure that the
+   signature is not invalidated.
+
+   Where such requirements have not been explicitly stated, servers
+   SHOULD preserve the value of user information but MAY return the
+   value in a different form.  And where a server is unable (or
+   unwilling) to preserve the value of user information, the server
+   SHALL ensure that an equivalent value (per Section 2.3) is returned.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 40]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+6.2.  Short Names
+
+   Short names, also known as descriptors, are used as more readable
+   aliases for object identifiers and are used to identify various
+   schema elements.  However, it is not expected that LDAP
+   implementations with human user interface would display these short
+   names (or the object identifiers they refer to) to the user.
+   Instead, they would most likely be performing translations (such as
+   expressing the short name in one of the local national languages).
+   For example, the short name "st" (stateOrProvinceName) might be
+   displayed to a German-speaking user as "Land".
+
+   The same short name might have different meaning in different
+   subschemas, and, within a particular subschema, the same short name
+   might refer to different object identifiers each identifying a
+   different kind of schema element.
+
+   Implementations MUST be prepared that the same short name might be
+   used in a subschema to refer to the different kinds of schema
+   elements.  That is, there might be an object class 'x-fubar' and an
+   attribute type 'x-fubar' in a subschema.
+
+   Implementations MUST be prepared that the same short name might be
+   used in the different subschemas to refer to the different schema
+   elements.  That is, there might be two matching rules 'x-fubar', each
+   in different subschemas.
+
+   Procedures for registering short names (descriptors) are detailed in
+   BCP 64, RFC 4520 [RFC4520].
+
+6.3.  Cache and Shadowing
+
+   Some servers may hold cache or shadow copies of entries, which can be
+   used to answer search and comparison queries, but will return
+   referrals or contact other servers if modification operations are
+   requested.  Servers that perform shadowing or caching MUST ensure
+   that they do not violate any access control constraints placed on the
+   data by the originating server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 41]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+7.  Implementation Guidelines
+
+7.1.  Server Guidelines
+
+   Servers MUST recognize all names of attribute types and object
+   classes defined in this document but, unless stated otherwise, need
+   not support the associated functionality.  Servers SHOULD recognize
+   all the names of attribute types and object classes defined in
+   Section 3 and 4, respectively, of [RFC4519].
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.
+
+   Servers MAY support DIT Content Rules.  Servers MAY support DIT
+   Structure Rules and Name Forms.
+
+   Servers MAY support alias entries.
+
+   Servers MAY support the 'extensibleObject' object class.
+
+   Servers MAY support subentries.  If so, they MUST do so in accordance
+   with [RFC3672].  Servers that do not support subentries SHOULD use
+   object entries to mimic subentries as detailed in Section 3.2.
+
+   Servers MAY implement additional schema elements.  Servers SHOULD
+   provide definitions of all schema elements they support in subschema
+   (sub)entries.
+
+7.2.  Client Guidelines
+
+   In the absence of prior agreements with servers, clients SHOULD NOT
+   assume that servers support any particular schema elements beyond
+   those referenced in Section 7.1.  The client can retrieve subschema
+   information as described in Section 4.4.
+
+   Clients MUST NOT display or attempt to decode a value as ASN.1 if the
+   value's syntax is not known.  Clients MUST NOT assume the LDAP-
+   specific string encoding is restricted to a UTF-8 encoded string of
+   Unicode characters or any particular subset of Unicode (such as a
+   printable subset) unless such restriction is explicitly stated.
+   Clients SHOULD NOT send attribute values in a request that are not
+   valid according to the syntax defined for the attributes.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 42]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+8.  Security Considerations
+
+   Attributes of directory entries are used to provide descriptive
+   information about the real-world objects they represent, which can be
+   people, organizations, or devices.  Most countries have privacy laws
+   regarding the publication of information about people.
+
+   General security considerations for accessing directory information
+   with LDAP are discussed in [RFC4511] and [RFC4513].
+
+9.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry as indicated in the following template:
+
+      Subject: Request for LDAP Descriptor Registration Update
+      Descriptor (short name): see comment
+      Object Identifier: see comment
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Usage: see comment
+      Specification: RFC 4512
+      Author/Change Controller: IESG
+      Comments:
+
+      The following descriptors (short names) has been added to
+      the registry.
+
+        NAME                         Type OID
+        ------------------------     ---- -----------------
+        governingStructureRule          A 2.5.21.10
+        structuralObjectClass           A 2.5.21.9
+
+      The following descriptors (short names) have been updated to
+      refer to this RFC.
+
+        NAME                         Type OID
+        ------------------------     ---- -----------------
+        alias                           O 2.5.6.1
+        aliasedObjectName               A 2.5.4.1
+        altServer                       A 1.3.6.1.4.1.1466.101.120.6
+        attributeTypes                  A 2.5.21.5
+        createTimestamp                 A 2.5.18.1
+        creatorsName                    A 2.5.18.3
+        dITContentRules                 A 2.5.21.2
+        dITStructureRules               A 2.5.21.1
+        extensibleObject                O 1.3.6.1.4.1.1466.101.120.111
+        ldapSyntaxes                    A 1.3.6.1.4.1.1466.101.120.16
+
+
+
+Zeilenga                    Standards Track                    [Page 43]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+        matchingRuleUse                 A 2.5.21.8
+        matchingRules                   A 2.5.21.4
+        modifiersName                   A 2.5.18.4
+        modifyTimestamp                 A 2.5.18.2
+        nameForms                       A 2.5.21.7
+        namingContexts                  A 1.3.6.1.4.1.1466.101.120.5
+        objectClass                     A 2.5.4.0
+        objectClasses                   A 2.5.21.6
+        subschema                       O 2.5.20.1
+        subschemaSubentry               A 2.5.18.10
+        supportedControl                A 1.3.6.1.4.1.1466.101.120.13
+        supportedExtension              A 1.3.6.1.4.1.1466.101.120.7
+        supportedFeatures               A 1.3.6.1.4.1.4203.1.3.5
+        supportedLDAPVersion            A 1.3.6.1.4.1.1466.101.120.15
+        supportedSASLMechanisms         A 1.3.6.1.4.1.1466.101.120.14
+        top                             O 2.5.6.0
+
+10.  Acknowledgements
+
+   This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+   S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+   RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+   Indexing of Directories (ASID) Working Group.  This document is also
+   based in part on "The Directory: Models" [X.501], a product of the
+   International Telephone Union (ITU).  Additional text was borrowed
+   from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
+
+   This document is a product of the IETF LDAP Revision (LDAPBIS)
+   Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 44]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+11.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3671]     Zeilenga, K., "Collective Attributes in the Lightweight
+                 Directory Access Protocol (LDAP)", RFC 3671, December
+                 2003.
+
+   [RFC3672]     Zeilenga, K., "Subentries in the Lightweight Directory
+                 Access Protocol (LDAP)", RFC 3672, December 2003.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+                 Authentication and Security Layer (SASL)", RFC 4422,
+                 June 2006.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): Uniform Resource Locator", RFC
+                 4516, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+
+
+Zeilenga                    Standards Track                    [Page 45]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 46]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+Appendix A.  Changes
+
+   This appendix is non-normative.
+
+   This document amounts to nearly a complete rewrite of portions of RFC
+   2251, RFC 2252, and RFC 2256.  This rewrite was undertaken to improve
+   overall clarity of technical specification.  This appendix provides a
+   summary of substantive changes made to the portions of these
+   documents incorporated into this document.  Readers should consult
+   [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
+   remaining portions of these documents.
+
+A.1.  Changes to RFC 2251
+
+   This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
+   portions of Sections 4 and 6 as summarized below.
+
+A.1.1.  Section 3.2 of RFC 2251
+
+   Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+   data model, as used by LDAP.  The previous specification relied on
+   [X.501] but lacked clarity in how X.500 models are adapted for use by
+   LDAP.  This document describes the X.500 data models, as used by
+   LDAP, in greater detail, especially in areas where adaptation is
+   needed.
+
+   Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+   or more associated values".  In LDAP, an attribute is better
+   described as an attribute description, a type with zero or more
+   options, and one or more associated values.
+
+   Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+   objectClasses and attributeTypes attributes, yet X.500(93) treats
+   these attributes as optional.  While generally all implementations
+   that support X.500(93) subschema mechanisms will provide both of
+   these attributes, it is not absolutely required for interoperability
+   that all servers do.  The mandate was removed for consistency with
+   X.500(93).   The subschema discovery mechanism was also clarified to
+   indicate that subschema controlling an entry is obtained by reading
+   the (sub)entry referred to by that entry's 'subschemaSubentry'
+   attribute.
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 47]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+A.1.2.  Section 3.4 of RFC 2251
+
+   Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+   This material, with changes, was incorporated in Section 5.1 of this
+   document.
+
+   Changes:
+
+   - Clarify that attributes of the root DSE are subject to "other
+     restrictions" in addition to access controls.
+
+   - Clarify that only recognized extended requests need to be
+     enumerated 'supportedExtension'.
+
+   - Clarify that only recognized request controls need to be enumerated
+     'supportedControl'.
+
+   - Clarify that root DSE attributes are operational and, like other
+     operational attributes, will not be returned in search requests
+     unless requested by name.
+
+   - Clarify that not all root DSE attributes are user modifiable.
+
+   - Remove inconsistent text regarding handling of the
+     'subschemaSubentry' attribute within the root DSE.  The previous
+     specification stated that the 'subschemaSubentry' attribute held in
+     the root DSE referred to "subschema entries (or subentries) known
+     by this server".  This is inconsistent with the attribute's
+     intended use as well as its formal definition as a single valued
+     attribute [X.501].  It is also noted that a simple (possibly
+     incomplete) list of subschema (sub)entries is not terribly useful.
+     This document (in Section 5.1) specifies that the
+     'subschemaSubentry' attribute of the root DSE refers to the
+     subschema controlling the root DSE.  It is noted that the general
+     subschema discovery mechanism remains available (see Section 4.4 of
+     this document).
+
+A.1.3.  Section 4 of RFC 2251
+
+   Portions of Section 4 of RFC 2251 detailing aspects of the
+   information model used by LDAP were incorporated in this document,
+   including:
+
+   - Restriction of distinguished values to attributes whose
+     descriptions have no options (from Section 4.1.3);
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 48]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   - Data model aspects of Attribute Types (from Section 4.1.4),
+     Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+     Matching Rule Identifier (from 4.1.9); and
+
+   - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
+
+   Clarifications to these portions include:
+
+   - Subtyping and AttributeDescriptions with options.
+
+A.1.4.  Section 6 of RFC 2251
+
+   The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+   where incorporated into this document.
+
+A.2.  Changes to RFC 2252
+
+   This document incorporates Sections 4, 5, and 7 from RFC 2252.
+
+A.2.1.  Section 4 of RFC 2252
+
+   The specification was updated to use Augmented BNF [RFC4234].  The
+   string representation of an OBJECT IDENTIFIER was tightened to
+   disallow leading zeros as described in RFC 2252.
+
+   The <descr> syntax was changed to disallow semicolon (U+003B)
+   characters in order to appear to be consistent its natural language
+   specification "descr is the syntactic representation of an object
+   descriptor, which consists of letters and digits, starting with a
+   letter".  In a related change, the statement "an AttributeDescription
+   can be used as the value in a NAME part of an
+   AttributeTypeDescription" was deleted.  RFC 2252 provided no
+   specification of the semantics of attribute options appearing in NAME
+   fields.
+
+   RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+   over the <numericoid> form.  However, <descr> form can be ambiguous.
+   To address this issue, the imperative was replaced with a statement
+   (in Section 1.4) that while the <descr> form is generally preferred,
+   <numericoid> should be used where an unambiguous <descr> is not
+   available.  Additionally, an expanded discussion of descriptor issues
+   is in Section 6.2 ("Short Names").
+
+   The ABNF for a quoted string (qdstring) was updated to reflect
+   support for the escaping mechanism described in Section 4.3 of RFC
+   2252.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 49]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+A.2.2.  Section 5 of RFC 2252
+
+   Definitions of operational attributes provided in Section 5 of RFC
+   2252 where incorporated into this document.
+
+   The 'namingContexts' description was clarified.  A first-level DSA
+   should publish, in addition to other values, "" indicating the root
+   of the DIT.
+
+   The 'altServer' description was clarified.  It may hold any URI.
+
+   The 'supportedExtension' description was clarified.  A server need
+   only list the OBJECT IDENTIFIERs associated with the extended
+   requests of the extended operations it recognizes.
+
+   The 'supportedControl' description was clarified.  A server need only
+   list the OBJECT IDENTIFIERs associated with the request controls it
+   recognizes.
+
+   Descriptions for the 'structuralObjectClass' and
+   'governingStructureRule' operational attribute types were added.
+
+   The attribute definition of 'subschemaSubentry' was corrected to list
+   the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
+
+A.2.3.  Section 7 of RFC 2252
+
+   Section 7 of RFC 2252 provides definitions of the 'subschema' and
+   'extensibleObject' object classes.  These definitions where
+   integrated into Section 4.2 and Section 4.3 of this document,
+   respectively.  Section 7 of RFC 2252 also contained the object class
+   implementation requirement.  This was incorporated into Section 7 of
+   this document.
+
+   The specification of 'extensibleObject' was clarified regarding how
+   it interacts with precluded attributes.
+
+A.3.  Changes to RFC 2256
+
+   This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+   2256.
+
+   Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+   attribute type.  This was integrated into Section 2.4.1 of this
+   document.  The statement "One of the values is either 'top' or
+   'alias'" was replaced with statement that one of the values is 'top'
+   as entries belonging to 'alias' also belong to 'top'.
+
+
+
+
+Zeilenga                    Standards Track                    [Page 50]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Section 5.2 of RFC 2256 provided the definition of the
+   'aliasedObjectName' attribute type.  This was integrated into Section
+   2.6.2 of this document.
+
+   Section 7.1 of RFC 2256 provided the definition of the 'top' object
+   class.  This was integrated into Section 2.4.1 of this document.
+
+   Section 7.2 of RFC 2256 provided the definition of the 'alias' object
+   class.  This was integrated into Section 2.6.1 of this document.
+
+A.4.  Changes to RFC 3674
+
+   This document made no substantive change to the 'supportedFeatures'
+   technical specification provided in RFC 3674.
+
+Editor's Address
+
+   Kurt D.  Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 51]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 52]
+
-- 
cgit v1.2.3