rfc2251.txt

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

   the system and user schema determine the permitted attributes of an
   entry.  Values of this attribute may be modified by clients, but the
   objectClass attribute cannot be removed.  Servers may restrict the
   modifications of this attribute to prevent the basic structural class
   of the entry from being changed (e.g. one cannot change a person into
   a country).  When creating an entry or adding an objectClass value to
   an entry, all superclasses of the named classes are implicitly added
   as well if not already present, and the client must supply values for
   any mandatory attributes of new superclasses.

   Some attributes, termed operational attributes, are used by servers
   for administering the directory system itself.  They are not returned
   in search results unless explicitly requested by name.  Attributes
   which are not operational, such as "mail", will have their schema and
   syntax constraints enforced by servers, but servers will generally
   not make use of their values.

   Servers MUST NOT permit clients to add attributes to an entry unless
   those attributes are permitted by the object class definitions, the
   schema controlling that entry (specified in the subschema - see
   below), or are operational attributes known to that server and used
   for administrative purposes.  Note that there is a particular
   objectClass 'extensibleObject' defined in [5] which permits all user
   attributes to be present in an entry.

   Entries MAY contain, among others, the following operational
   attributes, defined in [5]. These attributes are maintained
   automatically by the server and are not modifiable by clients:




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


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

   - modifyTimestamp: the time this entry was last modified.

   - subschemaSubentry:  the Distinguished Name of the subschema entry
     (or subentry) which controls the schema for this entry.

3.2.2. Subschema Entries and Subentries

   Subschema entries are used for administering information about the
   directory schema, in particular the object classes and attribute
   types supported by directory servers.  A single subschema entry
   contains all schema definitions used by entries in a particular part
   of the directory tree.

   Servers which follow X.500(93) models SHOULD implement subschema
   using the X.500 subschema mechanisms, and so these subschemas are not
   ordinary entries.  LDAP clients SHOULD NOT assume that servers
   implement any of the other aspects of X.500 subschema.  A server
   which masters entries and permits clients to modify these entries
   MUST implement and provide access to these subschema entries, so that
   its clients may discover the attributes and object classes which are
   permitted to be present. It is strongly recommended that all other
   servers implement this as well.

   The following four attributes MUST be present in all subschema
   entries:

   - cn: this attribute MUST be used to form the RDN of the subschema
     entry.

   - objectClass: the attribute MUST have at least the values "top" and
     "subschema".

   - objectClasses: each value of this attribute specifies an object
     class known to the server.

   - attributeTypes: each value of this attribute specifies an attribute
     type known to the server.

   These are defined in [5]. Other attributes MAY be present in
   subschema entries, to reflect additional supported capabilities.



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


   These include matchingRules, matchingRuleUse, dITStructureRules,
   dITContentRules, nameForms and ldapSyntaxes.

   Servers SHOULD provide the attributes createTimestamp and
   modifyTimestamp in subschema entries, in order to allow clients to
   maintain their caches of schema information.

   Clients MUST only retrieve attributes from a subschema entry by
   requesting a base object search of the entry, where the search filter
   is "(objectClass=subschema)". (This will allow LDAPv3 servers which
   gateway to X.500(93) to detect that subentry information is being
   requested.)

3.3. Relationship to X.500

   This document defines LDAP in terms of X.500 as an X.500 access
   mechanism.  An LDAP server MUST act in accordance with the
   X.500(1993) series of ITU recommendations when providing the service.
   However, it is not required that an LDAP server make use of any X.500
   protocols in providing this service, e.g. LDAP can be mapped onto any
   other directory system so long as the X.500 data and service model as
   used in LDAP is not violated in the LDAP interface.

3.4. Server-specific Data Requirements

   An LDAP server MUST provide information about itself and other
   information that is specific to each server.  This is represented as
   a group of attributes located in the root DSE (DSA-Specific Entry),
   which is named with the zero-length LDAPDN.  These attributes are
   retrievable if a client performs a base object search of the root
   with filter "(objectClass=*)", however they are subject to access
   control restrictions.  The root DSE MUST NOT be included if the
   client performs a subtree search starting from the root.

   Servers may allow clients to modify these attributes.

   The following attributes of the root DSE are defined in section 5 of
   [5].  Additional attributes may be defined in other documents.

   - namingContexts: naming contexts held in the server. Naming contexts
     are defined in section 17 of X.501 [6].

   - subschemaSubentry: subschema entries (or subentries) known by this
     server.

   - altServer: alternative servers in case this one is later
     unavailable.




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


   - supportedExtension: list of supported extended operations.

   - supportedControl: list of supported controls.

   - supportedSASLMechanisms: list of supported SASL security features.

   - supportedLDAPVersion: LDAP versions implemented by the server.

   If the server does not master entries and does not know the locations
   of schema information, the subschemaSubentry attribute is not present
   in the root DSE.  If the server masters directory entries under one
   or more schema rules, there may be any number of values of the
   subschemaSubentry attribute in the root DSE.

4.  Elements of Protocol

   The LDAP protocol is described using Abstract Syntax Notation 1
   (ASN.1) [3], and is typically transferred using a subset of ASN.1
   Basic Encoding Rules [11]. In order to support future extensions to
   this protocol, clients and servers MUST ignore elements of SEQUENCE
   encodings whose tags they do not recognize.

   Note that unlike X.500, each change to the LDAP protocol other than
   through the extension mechanisms will have a different version
   number.  A client will indicate the version it supports as part of
   the bind request, described in section 4.2.  If a client has not sent
   a bind, the server MUST assume that version 3 is supported in the
   client (since version 2 required that the client bind first).

   Clients may determine the protocol version a server supports by
   reading the supportedLDAPVersion attribute from the root DSE. Servers
   which implement version 3 or later versions MUST provide this
   attribute.  Servers which only implement version 2 may not provide
   this attribute.

4.1. Common Elements

   This section describes the LDAPMessage envelope PDU (Protocol Data
   Unit) format, as well as data type definitions which are used in the
   protocol operations.

4.1.1. Message Envelope

   For the purposes of protocol exchanges, all protocol operations are
   encapsulated in a common envelope, the LDAPMessage, which is defined
   as follows:

        LDAPMessage ::= SEQUENCE {



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


                messageID       MessageID,
                protocolOp      CHOICE {
                        bindRequest     BindRequest,
                        bindResponse    BindResponse,
                        unbindRequest   UnbindRequest,
                        searchRequest   SearchRequest,
                        searchResEntry  SearchResultEntry,
                        searchResDone   SearchResultDone,
                        searchResRef    SearchResultReference,
                        modifyRequest   ModifyRequest,
                        modifyResponse  ModifyResponse,
                        addRequest      AddRequest,
                        addResponse     AddResponse,
                        delRequest      DelRequest,
                        delResponse     DelResponse,
                        modDNRequest    ModifyDNRequest,
                        modDNResponse   ModifyDNResponse,
                        compareRequest  CompareRequest,
                        compareResponse CompareResponse,
                        abandonRequest  AbandonRequest,
                        extendedReq     ExtendedRequest,
                        extendedResp    ExtendedResponse },
                 controls       [0] Controls OPTIONAL }

        MessageID ::= INTEGER (0 .. maxInt)

        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

   The function of the LDAPMessage is to provide an envelope containing
   common fields required in all protocol exchanges. At this time the
   only common fields are the message ID and the controls.

   If the server receives a PDU from the client in which the LDAPMessage
   SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
   the tag of the protocolOp is not recognized as a request, or the
   encoding structures or lengths of data fields are found to be
   incorrect, then the server MUST return the notice of disconnection
   described in section 4.4.1, with resultCode protocolError, and
   immediately close the connection. In other cases that the server
   cannot parse the request received by the client, the server MUST
   return an appropriate response to the request, with the resultCode
   set to protocolError.

   If the client receives a PDU from the server which cannot be parsed,
   the client may discard the PDU, or may abruptly close the connection.

   The ASN.1 type Controls is defined in section 4.1.12.




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


4.1.1.1. Message ID

   All LDAPMessage envelopes encapsulating responses contain the
   messageID value of the corresponding request LDAPMessage.

   The message ID of a request MUST have a value different from the
   values of any other requests outstanding in the LDAP session of which
   this message is a part.

   A client MUST NOT send a second request with the same message ID as
   an earlier request on the same connection if the client has not
   received the final response from the earlier request.  Otherwise the
   behavior is undefined.  Typical clients increment a counter for each
   request.

   A client MUST NOT reuse the message id of an abandonRequest or of the
   abandoned operation until it has received a response from the server
   for another request invoked subsequent to the abandonRequest, as the
   abandonRequest itself does not have a response.

4.1.2. String Types

   The LDAPString is a notational convenience to indicate that, although
   strings of LDAPString type encode as OCTET STRING types, the ISO
   10646 [13] character set (a superset of Unicode) is used, encoded
   following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm
   characters which are the same as ASCII (0x0000 through 0x007F) are
   represented as that same ASCII character in a single byte.  The other
   byte values are used to form a variable-length encoding of an
   arbitrary character.

        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