rfc4512.txt

samba最新软件

   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.





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


   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 )




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


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






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


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;









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


      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.



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


   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.







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


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