rfc2251.txt

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

        LDAPString ::= OCTET STRING

   The LDAPOID is a notational convenience to indicate that the
   permitted value of this string is a (UTF-8 encoded) dotted-decimal
   representation of an OBJECT IDENTIFIER.

        LDAPOID ::= OCTET STRING

   For example,

        1.3.6.1.4.1.1466.1.2.3

4.1.3. Distinguished Name and Relative Distinguished Name

   An LDAPDN and a RelativeLDAPDN are respectively defined to be the
   representation of a Distinguished Name and a Relative Distinguished
   Name after encoding according to the specification in [4], such that



Wahl, et. al.               Standards Track                    [Page 11]

RFC 2251                         LDAPv3                    December 1997


        <distinguished-name> ::= <name>

        <relative-distinguished-name> ::= <name-component>

   where <name> and <name-component> are as defined in [4].

        LDAPDN ::= LDAPString

        RelativeLDAPDN ::= LDAPString

   Only Attribute Types can be present in a relative distinguished name
   component; the options of Attribute Descriptions (next section) MUST
   NOT be used in specifying distinguished names.

4.1.4. Attribute Type

   An AttributeType takes on as its value the textual string associated
   with that AttributeType in its specification.

        AttributeType ::= LDAPString

   Each attribute type has a unique OBJECT IDENTIFIER which has been
   assigned to it.  This identifier may be written as decimal digits
   with components separated by periods, e.g. "2.5.4.10".

   A specification may also assign one or more textual names for an
   attribute type.  These names MUST begin with a letter, and only
   contain ASCII letters, digit characters and hyphens.  They are case
   insensitive.  (These ASCII characters are identical to ISO 10646
   characters whose UTF-8 encoding is a single byte between 0x00 and
   0x7F.)

   If the server has a textual name for an attribute type, it MUST use a
   textual name for attributes returned in search results.  The dotted-
   decimal OBJECT IDENTIFIER is only used if there is no textual name
   for an attribute type.

   Attribute type textual names are non-unique, as two different
   specifications (neither in standards track RFCs) may choose the same
   name.

   A server which masters or shadows entries SHOULD list all the
   attribute types it supports in the subschema entries, using the
   attributeTypes attribute.  Servers which support an open-ended set of
   attributes SHOULD include at least the attributeTypes value for the
   'objectClass' attribute. Clients MAY retrieve the attributeTypes
   value from subschema entries in order to obtain the OBJECT IDENTIFIER
   and other information associated with attribute types.



Wahl, et. al.               Standards Track                    [Page 12]

RFC 2251                         LDAPv3                    December 1997


   Some attribute type names which are used in this version of LDAP are
   described in [5].  Servers may implement additional attribute types.

4.1.5. Attribute Description

   An AttributeDescription is a superset of the definition of the
   AttributeType.  It has the same ASN.1 definition, but allows
   additional options to be specified.  They are also case insensitive.

        AttributeDescription ::= LDAPString

   A value of AttributeDescription is based on the following BNF:

        <AttributeDescription> ::= <AttributeType> [ ";" <options> ]

        <options>  ::= <option> | <option> ";" <options>

        <option>   ::= <opt-char> <opt-char>*

        <opt-char> ::=  ASCII-equivalent letters, numbers and hyphen

   Examples of valid AttributeDescription:

        cn
        userCertificate;binary

   One option, "binary", is defined in this document.  Additional
   options may be defined in IETF standards-track and experimental RFCs.
   Options beginning with "x-" are reserved for private experiments.
   Any option could be associated with any AttributeType, although not
   all combinations may be supported by a server.

   An AttributeDescription with one or more options is treated as a
   subtype of the attribute type without any options.  Options present
   in an AttributeDescription are never mutually exclusive.
   Implementations MUST generate the <options> list sorted in ascending
   order, and servers MUST treat any two AttributeDescription with the
   same AttributeType and options as equivalent.  A server will treat an
   AttributeDescription with any options it does not implement as an
   unrecognized attribute type.

   The data type "AttributeDescriptionList" describes a list of 0 or
   more attribute types.  (A list of zero elements has special
   significance in the Search request.)

        AttributeDescriptionList ::= SEQUENCE OF
                AttributeDescription




Wahl, et. al.               Standards Track                    [Page 13]

RFC 2251                         LDAPv3                    December 1997


4.1.5.1. Binary Option

   If the "binary" option is present in an AttributeDescription, it
   overrides any string-based encoding representation defined for that
   attribute in [5]. Instead the attribute is to be transferred as a
   binary value encoded using the Basic Encoding Rules [11].  The syntax
   of the binary value is an ASN.1 data type definition which is
   referenced by the "SYNTAX" part of the attribute type definition.

   The presence or absence of the "binary" option only affects the
   transfer of attribute values in protocol; servers store any
   particular attribute in a single format.  If a client requests that a
   server return an attribute in the binary format, but the server
   cannot generate that format, the server MUST treat this attribute
   type as an unrecognized attribute type.  Similarly, clients MUST NOT
   expect servers to return an attribute in binary format if the client
   requested that attribute by name without the binary option.

   This option is intended to be used with attributes whose syntax is a
   complex ASN.1 data type, and the structure of values of that type is
   needed by clients.  Examples of this kind of syntax are "Certificate"
   and "CertificateList".

4.1.6. Attribute Value

   A field of type AttributeValue takes on as its value either a string
   encoding of a AttributeValue data type, or an OCTET STRING containing
   an encoded binary value, depending on whether the "binary" option is
   present in the companion AttributeDescription to this AttributeValue.

   The definition of string encodings for different syntaxes and types
   may be found in other documents, and in particular [5].

        AttributeValue ::= OCTET STRING

   Note that there is no defined limit on the size of this encoding;
   thus protocol values may include multi-megabyte attributes (e.g.
   photographs).

   Attributes may be defined which have arbitrary and non-printable
   syntax.  Implementations MUST NEITHER simply display nor attempt to
   decode as ASN.1 a value if its syntax is not known.  The
   implementation may attempt to discover the subschema of the source
   entry, and retrieve the values of attributeTypes from it.

   Clients MUST NOT send attribute values in a request which are not
   valid according to the syntax defined for the attributes.




Wahl, et. al.               Standards Track                    [Page 14]

RFC 2251                         LDAPv3                    December 1997


4.1.7. Attribute Value Assertion

   The AttributeValueAssertion type definition is similar to the one in
   the X.500 directory standards.  It contains an attribute description
   and a matching rule assertion value suitable for that type.

        AttributeValueAssertion ::= SEQUENCE {
                attributeDesc   AttributeDescription,
                assertionValue  AssertionValue }

        AssertionValue ::= OCTET STRING

   If the "binary" option is present in attributeDesc, this signals to
   the server that the assertionValue is a binary encoding of the
   assertion value.

   For all the string-valued user attributes described in [5], the
   assertion value syntax is the same as the value syntax.  Clients may
   use attribute values as assertion values in compare requests and
   search filters.

   Note however that the assertion syntax may be different from the
   value syntax for other attributes or for non-equality matching rules.
   These may have an assertion syntax which contains only part of the
   value.  See section 20.2.1.8 of X.501 [6] for examples.

4.1.8. Attribute

   An attribute consists of a type and one or more values of that type.
   (Though attributes MUST have at least one value when stored, due to
   access control restrictions the set may be empty when transferred in
   protocol.  This is described in section 4.5.2, concerning the
   PartialAttributeList type.)

        Attribute ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

   Each attribute value is distinct in the set (no duplicates).  The
   order of attribute values within the vals set is undefined and
   implementation-dependent, and MUST NOT be relied upon.

4.1.9. Matching Rule Identifier

   A matching rule is a means of expressing how a server should compare
   an AssertionValue received in a search filter with an abstract data
   value.  The matching rule defines the syntax of the assertion value
   and the process to be performed in the server.



Wahl, et. al.               Standards Track                    [Page 15]

RFC 2251                         LDAPv3                    December 1997


   An X.501(1993) Matching Rule is identified in the LDAP protocol by
   the printable representation of its OBJECT IDENTIFIER, either as one
   of the strings given in [5], or as decimal digits with components
   separated by periods, e.g. "caseIgnoreIA5Match" or
   "1.3.6.1.4.1.453.33.33".

        MatchingRuleId ::= LDAPString

   Servers which support matching rules for use in the extensibleMatch
   search filter MUST list the matching rules they implement in
   subschema entries, using the matchingRules attributes.  The server
   SHOULD also list there, using the matchingRuleUse attribute, the
   attribute types with which each matching rule can be used.  More
   information is given in section 4.4 of [5].

4.1.10. Result Message

   The LDAPResult is the construct used in this protocol to return
   success or failure indications from servers to clients. In response
   to various requests servers will return responses containing fields
   of type LDAPResult to indicate the final status of a protocol
   operation request.

        LDAPResult ::= SEQUENCE {
                resultCode      ENUMERATED {
                             success                      (0),
                             operationsError              (1),
                             protocolError                (2),
                             timeLimitExceeded            (3),
                             sizeLimitExceeded            (4),
                             compareFalse                 (5),
                             compareTrue                  (6),

                             authMethodNotSupported       (7),
                             strongAuthRequired           (8),
                                        -- 9 reserved --
                             referral                     (10),  -- new
                             adminLimitExceeded           (11),  -- new
                             unavailableCriticalExtension (12),  -- new
                             confidentialityRequired      (13),  -- new
                             saslBindInProgress           (14),  -- new
                             noSuchAttribute              (16),
                             undefinedAttributeType       (17),
                             inappropriateMatching        (18),
                             constraintViolation          (19),
                             attributeOrValueExists       (20),
                             invalidAttributeSyntax       (21),
                                        -- 22-31 unused --