rfc2252.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,796 行 · 第 1/5 页

   that all attributes be returned from entries MUST be prepared to
   receive values in binary (e.g. userCertificate;binary), and SHOULD
   NOT simply display binary or unrecognized values to users.

4.3.2. Syntax Object Identifiers

   Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
   dotted-decimal strings.  These are not intended to be displayed to
   users.

   noidlen = numericoid [ "{" len "}" ]

   len     = numericstring

   The following table lists some of the syntaxes that have been defined
   for LDAP thus far.  The H-R column suggests whether a value in that
   syntax would likely be a human readable string.  Clients and servers
   need not implement all the syntaxes listed here, and MAY implement
   other syntaxes.

   Other documents may define additional syntaxes.  However, the
   definition of additional arbitrary syntaxes is strongly deprecated
   since it will hinder interoperability: today's client and server
   implementations generally do not have the ability to dynamically
   recognize new syntaxes.  In most cases attributes will be defined
   with the syntax for directory strings.







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


   Value being represented        H-R OBJECT IDENTIFIER
   =================================================================
   ACI Item                        N  1.3.6.1.4.1.1466.115.121.1.1
   Access Point                    Y  1.3.6.1.4.1.1466.115.121.1.2
   Attribute Type Description      Y  1.3.6.1.4.1.1466.115.121.1.3
   Audio                           N  1.3.6.1.4.1.1466.115.121.1.4
   Binary                          N  1.3.6.1.4.1.1466.115.121.1.5
   Bit String                      Y  1.3.6.1.4.1.1466.115.121.1.6
   Boolean                         Y  1.3.6.1.4.1.1466.115.121.1.7
   Certificate                     N  1.3.6.1.4.1.1466.115.121.1.8
   Certificate List                N  1.3.6.1.4.1.1466.115.121.1.9
   Certificate Pair                N  1.3.6.1.4.1.1466.115.121.1.10
   Country String                  Y  1.3.6.1.4.1.1466.115.121.1.11
   DN                              Y  1.3.6.1.4.1.1466.115.121.1.12
   Data Quality Syntax             Y  1.3.6.1.4.1.1466.115.121.1.13
   Delivery Method                 Y  1.3.6.1.4.1.1466.115.121.1.14
   Directory String                Y  1.3.6.1.4.1.1466.115.121.1.15
   DIT Content Rule Description    Y  1.3.6.1.4.1.1466.115.121.1.16
   DIT Structure Rule Description  Y  1.3.6.1.4.1.1466.115.121.1.17
   DL Submit Permission            Y  1.3.6.1.4.1.1466.115.121.1.18
   DSA Quality Syntax              Y  1.3.6.1.4.1.1466.115.121.1.19
   DSE Type                        Y  1.3.6.1.4.1.1466.115.121.1.20
   Enhanced Guide                  Y  1.3.6.1.4.1.1466.115.121.1.21
   Facsimile Telephone Number      Y  1.3.6.1.4.1.1466.115.121.1.22
   Fax                             N  1.3.6.1.4.1.1466.115.121.1.23
   Generalized Time                Y  1.3.6.1.4.1.1466.115.121.1.24
   Guide                           Y  1.3.6.1.4.1.1466.115.121.1.25
   IA5 String                      Y  1.3.6.1.4.1.1466.115.121.1.26
   INTEGER                         Y  1.3.6.1.4.1.1466.115.121.1.27
   JPEG                            N  1.3.6.1.4.1.1466.115.121.1.28
   LDAP Syntax Description         Y  1.3.6.1.4.1.1466.115.121.1.54
   LDAP Schema Definition          Y  1.3.6.1.4.1.1466.115.121.1.56
   LDAP Schema Description         Y  1.3.6.1.4.1.1466.115.121.1.57
   Master And Shadow Access Points Y  1.3.6.1.4.1.1466.115.121.1.29
   Matching Rule Description       Y  1.3.6.1.4.1.1466.115.121.1.30
   Matching Rule Use Description   Y  1.3.6.1.4.1.1466.115.121.1.31
   Mail Preference                 Y  1.3.6.1.4.1.1466.115.121.1.32
   MHS OR Address                  Y  1.3.6.1.4.1.1466.115.121.1.33
   Modify Rights                   Y  1.3.6.1.4.1.1466.115.121.1.55
   Name And Optional UID           Y  1.3.6.1.4.1.1466.115.121.1.34
   Name Form Description           Y  1.3.6.1.4.1.1466.115.121.1.35
   Numeric String                  Y  1.3.6.1.4.1.1466.115.121.1.36
   Object Class Description        Y  1.3.6.1.4.1.1466.115.121.1.37
   Octet String                    Y  1.3.6.1.4.1.1466.115.121.1.40
   OID                             Y  1.3.6.1.4.1.1466.115.121.1.38
   Other Mailbox                   Y  1.3.6.1.4.1.1466.115.121.1.39
   Postal Address                  Y  1.3.6.1.4.1.1466.115.121.1.41
   Protocol Information            Y  1.3.6.1.4.1.1466.115.121.1.42



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