rfc4512.txt

samba最新软件

Network Working Group                                        K. Zeilenga
Request for Comments: 4512                           OpenLDAP Foundation
Obsoletes: 2251, 2252, 2256, 3674                              June 2006
Category: Standards Track


             Lightweight Directory Access Protocol (LDAP):
                      Directory Information Models

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Lightweight Directory Access Protocol (LDAP) is an Internet
   protocol for accessing distributed directory services that act in
   accordance with X.500 data and service models.  This document
   describes the X.500 Directory Information Models, as used in LDAP.
























Zeilenga                    Standards Track                     [Page 1]

RFC 4512                      LDAP Models                      June 2006


Table of Contents

   1. Introduction ....................................................3
      1.1. Relationship to Other LDAP Specifications ..................3
      1.2. Relationship to X.501 ......................................4
      1.3. Conventions ................................................4
      1.4. Common ABNF Productions ....................................4
   2. Model of Directory User Information .............................6
      2.1. The Directory Information Tree .............................7
      2.2. Structure of an Entry ......................................7
      2.3. Naming of Entries ..........................................8
      2.4. Object Classes .............................................9
      2.5. Attribute Descriptions ....................................12
      2.6. Alias Entries .............................................16
   3. Directory Administrative and Operational Information ...........17
      3.1. Subtrees ..................................................17
      3.2. Subentries ................................................18
      3.3. The 'objectClass' attribute ...............................18
      3.4. Operational Attributes ....................................19
   4. Directory Schema ...............................................22
      4.1. Schema Definitions ........................................23
      4.2. Subschema Subentries ......................................32
      4.3. 'extensibleObject' object class ...........................35
      4.4. Subschema Discovery .......................................35
   5. DSA (Server) Informational Model ...............................36
      5.1. Server-Specific Data Requirements .........................36
   6. Other Considerations ...........................................40
      6.1. Preservation of User Information ..........................40
      6.2. Short Names ...............................................41
      6.3. Cache and Shadowing .......................................41
   7. Implementation Guidelines ......................................42
      7.1. Server Guidelines .........................................42
      7.2. Client Guidelines .........................................42
   8. Security Considerations ........................................43
   9. IANA Considerations ............................................43
   10. Acknowledgements ..............................................44
   11. Normative References ..........................................45
   Appendix A. Changes ...............................................47
      A.1. Changes to RFC 2251 .......................................47
      A.2. Changes to RFC 2252 .......................................49
      A.3. Changes to RFC 2256 .......................................50
      A.4. Changes to RFC 3674 .......................................51









Zeilenga                    Standards Track                     [Page 2]

RFC 4512                      LDAP Models                      June 2006


1.  Introduction

   This document discusses the X.500 Directory Information Models
   [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
   [RFC4510].

   The Directory is "a collection of open systems cooperating to provide
   directory services" [X.500].  The information held in the Directory
   is collectively known as the Directory Information Base (DIB).  A
   Directory user, which may be a human or other entity, accesses the
   Directory through a client (or Directory User Agent (DUA)).  The
   client, on behalf of the directory user, interacts with one or more
   servers (or Directory System Agents (DSA)).  A server holds a
   fragment of the DIB.

   The DIB contains two classes of information:

      1) user information (e.g., information provided and administrated
         by users).  Section 2 describes the Model of User Information.

      2) administrative and operational information (e.g., information
         used to administer and/or operate the directory).  Section 3
         describes the model of Directory Administrative and Operational
         Information.

   These two models, referred to as the generic Directory Information
   Models, describe how information is represented in the Directory.
   These generic models provide a framework for other information
   models.  Section 4 discusses the subschema information model and
   subschema discovery.  Section 5 discusses the DSA (Server)
   Informational Model.

   Other X.500 information models (such as access control distribution
   knowledge and replication knowledge information models) may be
   adapted for use in LDAP.  Specification of how these models apply to
   LDAP is left to future documents.

1.1.  Relationship to Other LDAP Specifications

   This document is a integral part of the LDAP technical specification
   [RFC4510], which obsoletes the previously defined LDAP technical
   specification, RFC 3377, in its entirety.

   This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
   portions of Sections 4 and 6.  Appendix A.1 summarizes changes to
   these sections.  The remainder of RFC 2251 is obsoleted by the
   [RFC4511], [RFC4513], and [RFC4510] documents.




Zeilenga                    Standards Track                     [Page 3]

RFC 4512                      LDAP Models                      June 2006


   This document obsoletes RFC 2252, Sections 4, 5, and 7.  Appendix A.2
   summarizes changes to these sections.  The remainder of RFC 2252 is
   obsoleted by [RFC4517].

   This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
   Appendix A.3 summarizes changes to these sections.  The remainder of
   RFC 2256 is obsoleted by [RFC4519] and [RFC4517].

   This document obsoletes RFC 3674 in its entirety.  Appendix A.4
   summarizes changes since RFC 3674.

1.2.  Relationship to X.501

   This document includes material, with and without adaptation, from
   [X.501] as necessary to describe this protocol.  These adaptations
   (and any other differences herein) apply to this protocol, and only
   this protocol.

1.3.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].

   Schema definitions are provided using LDAP description formats (as
   defined in Section 4.1).  Definitions provided here are formatted
   (line wrapped) for readability.  Matching rules and LDAP syntaxes
   referenced in these definitions are specified in [RFC4517].

1.4.  Common ABNF Productions

   A number of syntaxes in this document are described using Augmented
   Backus-Naur Form (ABNF) [RFC4234].  These syntaxes (as well as a
   number of syntaxes defined in other documents) rely on the following
   common productions:

      keystring = leadkeychar *keychar
      leadkeychar = ALPHA
      keychar = ALPHA / DIGIT / HYPHEN
      number  = DIGIT / ( LDIGIT 1*DIGIT )

      ALPHA   = %x41-5A / %x61-7A   ; "A"-"Z" / "a"-"z"
      DIGIT   = %x30 / LDIGIT       ; "0"-"9"
      LDIGIT  = %x31-39             ; "1"-"9"
      HEX     = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"

      SP      = 1*SPACE  ; one or more " "
      WSP     = 0*SPACE  ; zero or more " "



Zeilenga                    Standards Track                     [Page 4]

RFC 4512                      LDAP Models                      June 2006


      NULL    = %x00 ; null (0)
      SPACE   = %x20 ; space (" ")
      DQUOTE  = %x22 ; quote (""")
      SHARP   = %x23 ; octothorpe (or sharp sign) ("#")
      DOLLAR  = %x24 ; dollar sign ("$")
      SQUOTE  = %x27 ; single quote ("'")
      LPAREN  = %x28 ; left paren ("(")
      RPAREN  = %x29 ; right paren (")")
      PLUS    = %x2B ; plus sign ("+")
      COMMA   = %x2C ; comma (",")
      HYPHEN  = %x2D ; hyphen ("-")
      DOT     = %x2E ; period (".")
      SEMI    = %x3B ; semicolon (";")
      LANGLE  = %x3C ; left angle bracket ("<")
      EQUALS  = %x3D ; equals sign ("=")
      RANGLE  = %x3E ; right angle bracket (">")
      ESC     = %x5C ; backslash ("\")
      USCORE  = %x5F ; underscore ("_")
      LCURLY  = %x7B ; left curly brace "{"
      RCURLY  = %x7D ; right curly brace "}"

      ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
      UTF8    = UTF1 / UTFMB
      UTFMB   = UTF2 / UTF3 / UTF4
      UTF0    = %x80-BF
      UTF1    = %x00-7F
      UTF2    = %xC2-DF UTF0
      UTF3    = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
                %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
      UTF4    = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
                %xF4 %x80-8F 2(UTF0)

      OCTET   = %x00-FF ; Any octet (8-bit data unit)

   Object identifiers (OIDs) [X.680] are represented in LDAP using a
   dot-decimal format conforming to the ABNF:

      numericoid = number 1*( DOT number )

   Short names, also known as descriptors, are used as more readable
   aliases for object identifiers.  Short names are case insensitive and
   conform to the ABNF:

      descr = keystring







Zeilenga                    Standards Track                     [Page 5]

RFC 4512                      LDAP Models                      June 2006


   Where either an object identifier or a short name may be specified,
   the following production is used:

      oid = descr / numericoid

   While the <descr> form is generally preferred when the usage is
   restricted to short names referring to object identifiers that
   identify like kinds of objects (e.g., attribute type descriptions,
   matching rule descriptions, object class descriptions), the
   <numericoid> form should be used when the object identifiers may
   identify multiple kinds of objects or when an unambiguous short name
   (descriptor) is not available.

   Implementations SHOULD treat short names (descriptors) used in an
   ambiguous manner (as discussed above) as unrecognized.

   Short Names (descriptors) are discussed further in Section 6.2.

2.  Model of Directory User Information

   As [X.501] states:

      The purpose of the Directory is to hold, and provide access to,
      information about objects of interest (objects) in some 'world'.
      An object can be anything which is identifiable (can be named).

      An object class is an identified family of objects, or conceivable
      objects, which share certain characteristics.  Every object
      belongs to at least one class.  An object class may be a subclass
      of other object classes, in which case the members of the former
      class, the subclass, are also considered to be members of the
      latter classes, the superclasses.  There may be subclasses of
      subclasses, etc., to an arbitrary depth.

   A directory entry, a named collection of information, is the basic
   unit of information held in the Directory.  There are multiple kinds
   of directory entries.

   An object entry represents a particular object.  An alias entry
   provides alternative naming.  A subentry holds administrative and/or
   operational information.

   The set of entries representing the DIB are organized hierarchically
   in a tree structure known as the Directory Information Tree (DIT).

   Section 2.1 describes the Directory Information Tree.
   Section 2.2 discusses the structure of entries.
   Section 2.3 discusses naming of entries.



Zeilenga                    Standards Track                     [Page 6]

RFC 4512                      LDAP Models                      June 2006