rfc4512.txt

samba最新软件

      - 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