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.

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

   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.

   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 )

   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].

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;

      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.

   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.

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.

   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.

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

   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.

   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;

     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.

   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.

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.

   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].

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].

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,

   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

   "(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.

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].

      ( 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].

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].