rfc2252.txt

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

Network Working Group                                            M. Wahl
Request for Comments: 2252                           Critical Angle Inc.
Category: Standards Track                                    A. Coulbeck
                                                              Isode Inc.
                                                                T. Howes
                                           Netscape Communications Corp.
                                                                S. Kille
                                                           Isode Limited
                                                           December 1997


              Lightweight Directory Access Protocol (v3):
                      Attribute Syntax Definitions

1. 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 (1997).  All Rights Reserved.

IESG Note

   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.

   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and

   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and






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


   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.

   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.

   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.

2. Abstract

   The Lightweight Directory Access Protocol (LDAP) [1] requires that
   the contents of AttributeValue fields in protocol elements be octet
   strings.  This document defines a set of syntaxes for LDAPv3, and the
   rules by which attribute values of these syntaxes are represented as
   octet strings for transmission in the LDAP protocol.  The syntaxes
   defined in this document are referenced by this and other documents
   that define attribute types.  This document also defines the set of
   attribute types which LDAP servers should support.

3. Overview

   This document defines the framework for developing schemas for
   directories accessible via the Lightweight Directory Access Protocol.

   Schema is the collection of attribute type definitions, object class
   definitions and other information which a server uses to determine
   how to match a filter or attribute value assertion (in a compare
   operation) against the attributes of an entry, and whether to permit
   add and modify operations.

   Section 4 states the general requirements and notations for attribute
   types, object classes, syntax and matching rule definitions.

   Section 5 lists attributes, section 6 syntaxes and section 7 object
   classes.

   Additional documents define schemas for representing real-world
   objects as directory entries.






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


4. General Issues

   This document describes encodings used in an Internet protocol.

   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 RFC 2119 [4].

   Attribute Type and Object Class definitions are written in a string
   representation of the AttributeTypeDescription and
   ObjectClassDescription data types defined in X.501(93) [3].
   Implementors are strongly advised to first read the description of
   how schema is represented in X.500 before reading the rest of this
   document.

4.1. Common Encoding Aspects

   For the purposes of defining the encoding rules for attribute
   syntaxes, the following BNF definitions will be used.  They are based
   on the BNF styles of RFC 822 [13].

    a     = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
            "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
            "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
            "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
            "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
            "T" / "U" / "V" / "W" / "X" / "Y" / "Z"

    d               = "0" / "1" / "2" / "3" / "4" /
                      "5" / "6" / "7" / "8" / "9"

    hex-digit       =  d / "a" / "b" / "c" / "d" / "e" / "f" /
                           "A" / "B" / "C" / "D" / "E" / "F"

    k               = a / d / "-" / ";"

    p               = a / d / """ / "(" / ")" / "+" / "," /
                      "-" / "." / "/" / ":" / "?" / " "

    letterstring    = 1*a

    numericstring   = 1*d

    anhstring       = 1*k

    keystring       = a [ anhstring ]

    printablestring = 1*p



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


    space           = 1*" "

    whsp            = [ space ]

    utf8            = <any sequence of octets formed from the UTF-8 [9]
                       transformation of a character from ISO10646 [10]>

    dstring         = 1*utf8

    qdstring        = whsp "'" dstring "'" whsp

    qdstringlist    = [ qdstring *( qdstring ) ]

    qdstrings       = qdstring / ( whsp "(" qdstringlist ")" whsp )

   In the following BNF for the string representation of OBJECT
   IDENTIFIERs, descr is the syntactic representation of an object
   descriptor, which consists of letters and digits, starting with a
   letter.  An OBJECT IDENTIFIER in the numericoid format should not
   have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
   not be generated).

   When encoding 'oid' elements in a value, the descr encoding option
   SHOULD be used in preference to the numericoid. An object descriptor
   is a more readable alias for a number OBJECT IDENTIFIER, and these
   (where assigned and known by the implementation) SHOULD be used in
   preference to numeric oids to the greatest extent possible.  Examples
   of object descriptors in LDAP are attribute type, object class and
   matching rule names.

     oid             = descr / numericoid

     descr           = keystring

     numericoid      = numericstring *( "." numericstring )

     woid            = whsp oid whsp

     ; set of oids of either form
     oids            = woid / ( "(" oidlist ")" )

     oidlist         = woid *( "$" woid )

     ; object descriptors used as schema element names
     qdescrs         = qdescr / ( whsp "(" qdescrlist ")" whsp )

     qdescrlist      = [ qdescr *( qdescr ) ]




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


     qdescr          = whsp "'" descr "'" whsp

4.2. Attribute Types

   The attribute types are described by sample values for the subschema
   "attributeTypes" attribute, which is written in the
   AttributeTypeDescription syntax.  While lines have been folded for
   readability, the values transferred in protocol would not contain
   newlines.

   The AttributeTypeDescription is encoded according to the following
   BNF, and the productions for oid, qdescrs and qdstring are given in
   section 4.1.  Implementors should note that future versions of this
   document may have expanded this BNF to include additional terms.
   Terms which begin with the characters "X-" are reserved for private
   experiments, and MUST be followed by a <qdstrings>.

      AttributeTypeDescription = "(" whsp
            numericoid whsp              ; AttributeType identifier
          [ "NAME" qdescrs ]             ; name used in AttributeType
          [ "DESC" qdstring ]            ; description
          [ "OBSOLETE" whsp ]
          [ "SUP" woid ]                 ; derived from this other
                                         ; AttributeType
          [ "EQUALITY" woid              ; Matching Rule name
          [ "ORDERING" woid              ; Matching Rule name
          [ "SUBSTR" woid ]              ; Matching Rule name
          [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
          [ "SINGLE-VALUE" whsp ]        ; default multi-valued
          [ "COLLECTIVE" whsp ]          ; default not collective
          [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
          [ "USAGE" whsp AttributeUsage ]; default userApplications
          whsp ")"

      AttributeUsage =
          "userApplications"     /
          "directoryOperation"   /
          "distributedOperation" / ; DSA-shared
          "dSAOperation"          ; DSA-specific, value depends on server

   Servers are not required to provide the same or any text in the
   description part of the subschema values they maintain.  Servers
   SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
   AttributeTypeDescription.

   Servers MUST implement all the attribute types referenced in sections
   5.1, 5.2 and 5.3.




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


   Servers MAY recognize additional names and attributes not listed in
   this document, and if they do so, MUST publish the definitions of the
   types in the attributeTypes attribute of their subschema entries.

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

   An AttributeDescription can be used as the value in a NAME part of an
   AttributeTypeDescription.  Note that these are case insensitive.

   Note that the AttributeTypeDescription does not list the matching
   rules which can can be used with that attribute type in an
   extensibleMatch search filter.  This is done using the
   matchingRuleUse attribute described in section 4.5.

   This document refines the schema description of X.501 by requiring
   that the syntax field in an AttributeTypeDescription be a string
   representation of an OBJECT IDENTIFIER for the LDAP string syntax
   definition, and an optional indication of the maximum length of a
   value of this attribute (defined in section 4.3.2).

4.3. Syntaxes

   This section defines general requirements for LDAP attribute value
   syntax encodings. All documents defining attribute syntax encodings
   for use with LDAP are expected to conform to these requirements.

   The encoding rules defined for a given attribute syntax must produce
   octet strings.  To the greatest extent possible, encoded octet
   strings should be usable in their native encoded form for display
   purposes. In particular, encoding rules for attribute syntaxes
   defining non-binary values should produce strings that can be
   displayed with little or no translation by clients implementing LDAP.
   There are a few cases (e.g. audio) however, when it is not sensible
   to produce a printable representation, and clients MUST NOT assume
   that an unrecognized syntax is a string representation.

   In encodings where an arbitrary string, not a Distinguished Name, is
   used as part of a larger production, and other than as part of a
   Distinguished Name, a backslash quoting mechanism is used to escape
   the following separator symbol character (such as "'", "$" or "#") if
   it should occur in that string.  The backslash is followed by a pair
   of hexadecimal digits representing the next character.  A backslash
   itself in the string which forms part of a larger syntax is always
   transmitted as '\5C' or '\5c'. An example is given in section 6.27.





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


   Syntaxes are also defined for matching rules whose assertion value
   syntax is different from the attribute value syntax.

4.3.1  Binary Transfer of Values

   This encoding format is used if the binary encoding is requested by
   the client for an attribute, or if the attribute syntax name is
   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
   AttributeValue or AssertionValue field is a BER-encoded instance of
   the attribute value or a matching rule assertion value ASN.1 data
   type as defined for use with X.500. (The first byte inside the OCTET
   STRING wrapper is a tag octet.  However, the OCTET STRING is still
   encoded in primitive form.)

   All servers MUST implement this form for both generating attribute
   values in search responses, and parsing attribute values in add,
   compare and modify requests, if the attribute type is recognized and
   the attribute syntax name is that of Binary.  Clients which request