rfc2252.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Wahl, et. al.               Standards Track                     [Page 8]

RFC 2252                   LADPv3 Attributes               December 1997


   Presentation Address            Y  1.3.6.1.4.1.1466.115.121.1.43
   Printable String                Y  1.3.6.1.4.1.1466.115.121.1.44
   Substring Assertion             Y  1.3.6.1.4.1.1466.115.121.1.58
   Subtree Specification           Y  1.3.6.1.4.1.1466.115.121.1.45
   Supplier Information            Y  1.3.6.1.4.1.1466.115.121.1.46
   Supplier Or Consumer            Y  1.3.6.1.4.1.1466.115.121.1.47
   Supplier And Consumer           Y  1.3.6.1.4.1.1466.115.121.1.48
   Supported Algorithm             N  1.3.6.1.4.1.1466.115.121.1.49
   Telephone Number                Y  1.3.6.1.4.1.1466.115.121.1.50
   Teletex Terminal Identifier     Y  1.3.6.1.4.1.1466.115.121.1.51
   Telex Number                    Y  1.3.6.1.4.1.1466.115.121.1.52
   UTC Time                        Y  1.3.6.1.4.1.1466.115.121.1.53

   A suggested minimum upper bound on the number of characters in value
   with a string-based syntax, or the number of bytes in a value for all
   other syntaxes, may be indicated by appending this bound count inside
   of curly braces following the syntax name's OBJECT IDENTIFIER in an
   Attribute Type Description.  This bound is not part of the syntax
   name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests that
   server implementations should allow a string to be 64 characters
   long, although they may allow longer strings.  Note that a single
   character of the Directory String syntax may be encoded in more than
   one byte since UTF-8 is a variable-length encoding.

4.3.3. Syntax Description

   The following BNF may be used to associate a short description with a
   syntax OBJECT IDENTIFIER. Implementors should note that future
   versions of this document may expand this definition to include
   additional terms.  Terms whose identifier begins with "X-" are
   reserved for private experiments, and MUST be followed by a
   <qdstrings>.

      SyntaxDescription = "(" whsp
          numericoid whsp
          [ "DESC" qdstring ]
          whsp ")"

4.4. Object Classes

   The format for representation of object classes is defined in X.501
   [3]. In general every entry will contain an abstract class ("top" or
   "alias"), at least one structural object class, and zero or more
   auxiliary object classes.  Whether an object class is abstract,
   structural or auxiliary is defined when the object class identifier
   is assigned.  An object class definition should not be changed
   without having a new identifier assigned to it.




Wahl, et. al.               Standards Track                     [Page 9]

RFC 2252                   LADPv3 Attributes               December 1997


   Object class descriptions are written according to the following BNF.
   Implementors should note that future versions of this document may
   expand this definition to include additional terms.  Terms whose
   identifier begins with "X-" are reserved for private experiments, and
   MUST be followed by a <qdstrings> encoding.

      ObjectClassDescription = "(" whsp
          numericoid whsp      ; ObjectClass identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          [ "SUP" oids ]       ; Superior ObjectClasses
          [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                               ; default structural
          [ "MUST" oids ]      ; AttributeTypes
          [ "MAY" oids ]       ; AttributeTypes
      whsp ")"

   These are described as sample values for the subschema
   "objectClasses" attribute for a server which implements the LDAP
   schema. While lines have been folded for readability, the values
   transferred in protocol would not contain newlines.

   Servers SHOULD implement all the object classes referenced in section
   7, except for extensibleObject, which is optional. Servers MAY
   implement additional object classes not listed in this document, and
   if they do so, MUST publish the definitions of the classes in the
   objectClasses attribute of their subschema entries.

   Schema developers MUST NOT create object class definitions whose
   names conflict with attributes defined for use with LDAP in existing
   standards-track RFCs.

4.5. Matching Rules

   Matching rules are used by servers to compare attribute values
   against assertion values when performing Search and Compare
   operations.  They are also used to identify the value to be added or
   deleted when modifying entries, and are used when comparing a
   purported distinguished name with the name of an entry.

   Most of the attributes given in this document will have an equality
   matching rule defined.

   Matching rule descriptions are written according to the following
   BNF.  Implementors should note that future versions of this document
   may have expanded this BNF to include additional terms.  Terms whose
   identifier begins with "X-" are reserved for private experiments, and



Wahl, et. al.               Standards Track                    [Page 10]

RFC 2252                   LADPv3 Attributes               December 1997


   MUST be followed by a <qdstrings> encoding.

      MatchingRuleDescription = "(" whsp
          numericoid whsp  ; MatchingRule identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          "SYNTAX" numericoid
      whsp ")"

   Values of the matchingRuleUse list the attributes which are suitable
   for use with an extensible matching rule.

      MatchingRuleUseDescription = "(" whsp
          numericoid whsp  ; MatchingRule identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" ]
         "APPLIES" oids    ; AttributeType identifiers
      whsp ")"

   Servers which support matching rules and the extensibleMatch SHOULD
   implement all the matching rules in section 8.

   Servers MAY implement additional matching rules not listed in this
   document, and if they do so, MUST publish the definitions of the
   matching rules in the matchingRules attribute of their subschema
   entries. If the server supports the extensibleMatch, then the server
   MUST publish the relationship between the matching rules and
   attributes in the matchingRuleUse attribute.

   For example, a server which implements a privately-defined matching
   rule for performing sound-alike matches on Directory String-valued
   attributes would include the following in the subschema entry
   (1.2.3.4.5 is an example, the OID of an actual matching rule would be
   different):

   matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   If this matching rule could be used with the attributes 2.5.4.41 and
   2.5.4.15, the following would also be present:

   matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )







Wahl, et. al.               Standards Track                    [Page 11]

RFC 2252                   LADPv3 Attributes               December 1997


   A client could then make use of this matching rule by sending a
   search operation in which the filter is of the extensibleMatch
   choice, the matchingRule field is "soundAlikeMatch", and the type
   field is "2.5.4.41" or "2.5.4.15".

5. Attribute Types

   All LDAP server implementations MUST recognize the attribute types
   defined in this section.

   Servers SHOULD also recognize all the attributes from section 5 of
   [12].

5.1. Standard Operational Attributes

   Servers MUST maintain values of these attributes in accordance with
   the definitions in X.501(93).

5.1.1. createTimestamp

   This attribute SHOULD appear in entries which were created using the
   Add operation.

    ( 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 )

5.1.2. modifyTimestamp

   This attribute SHOULD appear in entries which have been modified
   using the Modify operation.

    ( 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 )

5.1.3. creatorsName

   This attribute SHOULD appear in entries which were created using the
   Add operation.

    ( 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 )





Wahl, et. al.               Standards Track                    [Page 12]

RFC 2252                   LADPv3 Attributes               December 1997


5.1.4. modifiersName

   This attribute SHOULD appear in entries which have been modified
   using the Modify operation.

    ( 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 )

5.1.5. subschemaSubentry

   The value of this attribute is the name of a subschema entry (or
   subentry if the server is based on X.500(93)) in which the server
   makes available attributes specifying the schema.

    ( 2.5.18.10 NAME 'subschemaSubentry'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
      SINGLE-VALUE USAGE directoryOperation )

5.1.6. attributeTypes

   This attribute is typically located in the subschema entry.

    ( 2.5.21.5 NAME 'attributeTypes'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )

5.1.7. objectClasses

   This attribute is typically located in the subschema entry.

    ( 2.5.21.6 NAME 'objectClasses'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )

5.1.8. matchingRules

   This attribute is typically located in the subschema entry.

    ( 2.5.21.4 NAME 'matchingRules'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )








Wahl, et. al.               Standards Track                    [Page 13]

RFC 2252                   LADPv3 Attributes               December 1997


5.1.9. matchingRuleUse

   This attribute is typically located in the subschema entry.

    ( 2.5.21.8 NAME 'matchingRuleUse'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )

5.2. LDAP Operational Attributes

   These attributes are only present in the root DSE (see [1] and [3]).

   Servers MUST recognize these attribute names, but it is not required
   that a server provide values for these attributes, when the attribute
   corresponds to a feature which the server does not implement.

5.2.1. namingContexts

   The values of this attribute correspond to naming contexts which this
   server masters or shadows.  If the server does not master any
   information (e.g. it is an LDAP gateway to a public X.500 directory)
   this attribute will be absent.  If the server believes it contains
   the entire directory, the attribute will have a single value, and
   that value will be the empty string (indicating the null DN of the
   root). This attribute will allow a client to choose suitable base
   objects for searching when it has contacted a server.

    ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )

5.2.2. altServer

   The values of this attribute are URLs of other servers which may be
   contacted when this server becomes unavailable.  If the server does
   not know of any other servers which could be used this attribute will
   be absent. Clients may cache this information in case their preferred
   LDAP server later becomes unavailable.

    ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )

5.2.3. supportedExtension

   The values of this attribute are OBJECT IDENTIFIERs identifying the
   supported extended operations which the server supports.

   If the server does not support any extensions this attribute will be
   absent.



Wahl, et. al.               Standards Track                    [Page 14]

RFC 2252                   LADPv3 Attributes               December 1997


    ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )

5.2.4. supportedControl

   The values of this attribute are the OBJECT IDENTIFIERs identifying
   controls which the server supports.  If the server does not support
   any controls, this attribute will be absent.

    ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )

5.2.5. supportedSASLMechanisms

   The values of this attribute are the names of supported SASL
   mechanisms which the server supports.  If the server does not support
   any mechanisms this attribute will be absent.

    ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )

5.2.6. supportedLDAPVersion

   The values of this attribute are the versions of the LDAP protocol
   which the server implements.

    ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )

5.3. LDAP Subschema Attribute

   This attribute is typically located in the subschema entry.

5.3.1. ldapSyntaxes

   Servers MAY use this attribute to list the syntaxes which are
   implemented.  Each value corresponds to one syntax.

    ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )

5.4. X.500 Subschema attributes

   These attributes are located in the subschema entry.  All servers
   SHOULD recognize their name, although typically only X.500 servers
   will implement their functionality.




Wahl, et. al.               Standards Track                    [Page 15]

RFC 2252                   LADPv3 Attributes               December 1997


5.4.1. dITStructureRules

 ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )

5.4.2. nameForms

    ( 2.5.21.7 NAME 'nameForms'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )

5.4.3. ditContentRules

    ( 2.5.21.2 NAME 'dITContentRules'
      EQUALITY objectIdentifierFirstComponentMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )

6. Syntaxes

   Servers SHOULD recognize all the syntaxes described in this section.

6.1. Attribute Type Description

   ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

   Values in this syntax are encoded according to the BNF given at the
   start of section 4.2. For example,

        ( 2.5.4.0 NAME 'objectClass'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

6.2. Binary

   ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )

   Values in this syntax are encoded as described in section 4.3.1.

6.3. Bit String

   ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

   Values in this syntax are encoded according to the following BNF:

      bitstring = "'" *binary-digit "'B"

      binary-digit = "0" / "1"





Wahl, et. al.               Standards Track                    [Page 16]