rfc2251.txt

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

   If any SASL-based integrity or confidentiality services are enabled,
   they take effect following the transmission by the server and
   reception by the client of the final BindResponse with resultCode
   success.

   The client can request that the server use authentication information
   from a lower layer protocol by using the SASL EXTERNAL mechanism.





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


4.2.3. Bind Response

   The Bind Response is defined as follows.

        BindResponse ::= [APPLICATION 1] SEQUENCE {
             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

    BindResponse consists simply of an indication from the server of he
   status of the client's request for authentication.

   f the bind was successful, the resultCode will be success, therwise
   it will be one of:

   - operationsError: server encountered an internal error,

   - protocolError: unrecognized version number or incorrect PDU
     structure,

   - authMethodNotSupported: unrecognized SASL mechanism name,

   - strongAuthRequired: the server requires authentication be
     performed with a SASL mechanism,

   - referral: this server cannot accept this bind and the client
     should try another,

   - saslBindInProgress: the server requires the client to send a
     new bind request, with the same sasl mechanism, to continue the
     authentication process,

   - inappropriateAuthentication: the server requires the client
     which had attempted to bind anonymously or without supplying
     credentials to provide some form of credentials,

   - invalidCredentials: the wrong password was supplied or the SASL
     credentials could not be processed,

   - unavailable: the server is shutting down.

   If the server does not support the client's requested protocol
   version, it MUST set the resultCode to protocolError.

   If the client receives a BindResponse response where the resultCode
   was protocolError, it MUST close the connection as the server will be
   unwilling to accept further operations.  (This is for compatibility
   with earlier versions of LDAP, in which the bind was always the first
   operation, and there was no negotiation.)



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


   The serverSaslCreds are used as part of a SASL-defined bind mechanism
   to allow the client to authenticate the server to which it is
   communicating, or to perform "challenge-response" authentication. If
   the client bound with the password choice, or the SASL mechanism does
   not require the server to return information to the client, then this
   field is not to be included in the result.

4.3. Unbind Operation

   The function of the Unbind Operation is to terminate a protocol
   session.  The Unbind Operation is defined as follows:

        UnbindRequest ::= [APPLICATION 2] NULL

   The Unbind Operation has no response defined. Upon transmission of an
   UnbindRequest, a protocol client may assume that the protocol session
   is terminated. Upon receipt of an UnbindRequest, a protocol server
   may assume that the requesting client has terminated the session and
   that all outstanding requests may be discarded, and may close the
   connection.

4.4. Unsolicited Notification

   An unsolicited notification is an LDAPMessage sent from the server to
   the client which is not in response to any LDAPMessage received by
   the server. It is used to signal an extraordinary condition in the
   server or in the connection between the client and the server.  The
   notification is of an advisory nature, and the server will not expect
   any response to be returned from the client.

   The unsolicited notification is structured as an LDAPMessage in which
   the messageID is 0 and protocolOp is of the extendedResp form.  The
   responseName field of the ExtendedResponse is present. The LDAPOID
   value MUST be unique for this notification, and not be used in any
   other situation.

   One unsolicited notification is defined in this document.

4.4.1. Notice of Disconnection

   This notification may be used by the server to advise the client that
   the server is about to close the connection due to an error
   condition.  Note that this notification is NOT a response to an
   unbind requested by the client: the server MUST follow the procedures
   of section 4.3. This notification is intended to assist clients in
   distinguishing between an error condition and a transient network





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


   failure.  As with a connection close due to network failure, the
   client MUST NOT assume that any outstanding requests which modified
   the directory have succeeded or failed.

   The responseName is 1.3.6.1.4.1.1466.20036, the response field is
   absent, and the resultCode is used to indicate the reason for the
   disconnection.

   The following resultCode values are to be used in this notification:

   - protocolError: The server has received data from the client in
   which
     the LDAPMessage structure could not be parsed.

   - strongAuthRequired: The server has detected that an established
     underlying security association protecting communication between
     the client and server has unexpectedly failed or been compromised.

   - unavailable: This server will stop accepting new connections and
     operations on all existing connections, and be unavailable for an
     extended period of time.  The client may make use of an alternative
     server.

   After sending this notice, the server MUST close the connection.
   After receiving this notice, the client MUST NOT transmit any further
   on the connection, and may abruptly close the connection.

4.5. Search Operation

   The Search Operation allows a client to request that a search be
   performed on its behalf by a server.  This can be used to read
   attributes from a single entry, from entries immediately below a
   particular entry, or a whole subtree of entries.

4.5.1. Search Request

   The Search Request is defined as follows:

        SearchRequest ::= [APPLICATION 3] SEQUENCE {
                baseObject      LDAPDN,
                scope           ENUMERATED {
                        baseObject              (0),
                        singleLevel             (1),
                        wholeSubtree            (2) },
                derefAliases    ENUMERATED {
                        neverDerefAliases       (0),
                        derefInSearching        (1),
                        derefFindingBaseObj     (2),



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


                        derefAlways             (3) },
                sizeLimit       INTEGER (0 .. maxInt),
                timeLimit       INTEGER (0 .. maxInt),
                typesOnly       BOOLEAN,
                filter          Filter,
                attributes      AttributeDescriptionList }

        Filter ::= CHOICE {
                and             [0] SET OF Filter,
                or              [1] SET OF Filter,
                not             [2] Filter,
                equalityMatch   [3] AttributeValueAssertion,
                substrings      [4] SubstringFilter,
                greaterOrEqual  [5] AttributeValueAssertion,
                lessOrEqual     [6] AttributeValueAssertion,
                present         [7] AttributeDescription,
                approxMatch     [8] AttributeValueAssertion,
                extensibleMatch [9] MatchingRuleAssertion }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- at least one must be present
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type            [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

   Parameters of the Search Request are:

   - baseObject: An LDAPDN that is the base object entry relative to
     which the search is to be performed.

   - scope: An indicator of the scope of the search to be performed. The
     semantics of the possible values of this field are identical to the
     semantics of the scope field in the X.511 Search Operation.

   - derefAliases: An indicator as to how alias objects (as defined in
     X.501) are to be handled in searching.  The semantics of the
     possible values of this field are:

             neverDerefAliases: do not dereference aliases in searching
             or in locating the base object of the search;



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


             derefInSearching: dereference aliases in subordinates of
             the base object in searching, but not in locating the
             base object of the search;

             derefFindingBaseObj: dereference aliases in locating
             the base object of the search, but not when searching
             subordinates of the base object;

             derefAlways: dereference aliases both in searching and in
             locating the base object of the search.

   - sizelimit: A sizelimit that restricts the maximum number of entries
     to be returned as a result of the search. A value of 0 in this
     field indicates that no client-requested sizelimit restrictions are
     in effect for the search.  Servers may enforce a maximum number of
     entries to return.

   - timelimit: A timelimit that restricts the maximum time (in seconds)
     allowed for a search. A value of 0 in this field indicates that no
     client-requested timelimit restrictions are in effect for the
     search.

   - typesOnly: An indicator as to whether search results will contain
     both attribute types and values, or just attribute types.  Setting
     this field to TRUE causes only attribute types (no values) to be
     returned.  Setting this field to FALSE causes both attribute types
     and values to be returned.

   - filter: A filter that defines the conditions that must be fulfilled
     in order for the search to match a given entry.

     The 'and', 'or' and 'not' choices can be used to form combinations of
     filters. At least one filter element MUST be present in an 'and' or
     'or' choice.  The others match against individual attribute values of
     entries in the scope of the search.  (Implementor's note: the 'not'
     filter is an example of a tagged choice in an implicitly-tagged
     module.  In BER this is treated as if the tag was explicit.)

     A server MUST evaluate filters according to the three-valued logic
     of X.511(93) section 7.8.1.  In summary, a filter is evaluated to
     either "TRUE", "FALSE" or "Undefined".  If the filter evaluates
     to TRUE for a particular entry, then the attributes of that entry
     are returned as part of the search result (subject to any applicable
     access control restrictions). If the filter evaluates to FALSE or
     Undefined, then the entry is ignored for the search.






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


     A filter of the "and" choice is TRUE if all the filters in the SET
     OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
     otherwise Undefined.  A fil