rfc4512.txt

samba最新软件

   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=[e-mail],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: