tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4512

 Errata 
Proposed STD
Pages: 52
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: LDAPBIS

Lightweight Directory Access Protocol (LDAP): Directory Information Models

Part 1 of 3, p. 1 to 17
None       Next RFC Part

Obsoletes:    2251    2252    2256    3674


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
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.

Top      ToC       Page 4 
   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 " "

Top      ToC       Page 5 
      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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
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.

Top      ToC       Page 10 
      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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
   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").

Top      ToC       Page 16 
   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

Top      ToC       Page 17 
      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].



(page 17 continued on part 2)

Next RFC Part