rfc4511.txt

samba最新软件

                  compareResponse       CompareResponse,
                  abandonRequest        AbandonRequest,
                  extendedReq           ExtendedRequest,
                  extendedResp          ExtendedResponse,
                  ...,
                  intermediateResponse  IntermediateResponse },
             controls       [0] Controls OPTIONAL }

        MessageID ::= INTEGER (0 ..  maxInt)

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

   The ASN.1 type Controls is defined in Section 4.1.11.

   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 messageID and the controls.

   If the server receives an LDAPMessage 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 SHOULD return the Notice of Disconnection



Sermersheim                 Standards Track                     [Page 6]

RFC 4511                         LDAPv3                        June 2006


   described in Section 4.4.1, with the resultCode set to protocolError,
   and MUST immediately terminate the LDAP session as described in
   Section 5.3.

   In other cases where the client or server cannot parse an LDAP PDU,
   it SHOULD abruptly terminate the LDAP session (Section 5.3) where
   further communication (including providing notice) would be
   pernicious.  Otherwise, server implementations MUST return an
   appropriate response to the request, with the resultCode set to
   protocolError.

4.1.1.1.  MessageID

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

   The messageID of a request MUST have a non-zero value different from
   the messageID of any other request in progress in the same LDAP
   session.  The zero value is reserved for the unsolicited notification
   message.

   Typical clients increment a counter for each request.

   A client MUST NOT send a request with the same messageID as an
   earlier request in the same LDAP session unless it can be determined
   that the server is no longer servicing the earlier request (e.g.,
   after the final response is received, or a subsequent Bind
   completes).  Otherwise, the behavior is undefined.  For this purpose,
   note that Abandon and successfully abandoned operations do not send
   responses.

4.1.2.  String Types

   The LDAPString is a notational convenience to indicate that, although
   strings of LDAPString type encode as ASN.1 OCTET STRING types, the
   [ISO10646] character set (a superset of [Unicode]) is used, encoded
   following the UTF-8 [RFC3629] algorithm.  Note that Unicode
   characters U+0000 through U+007F are the same as ASCII 0 through 127,
   respectively, and have the same single octet UTF-8 encoding.  Other
   Unicode characters have a multiple octet UTF-8 encoding.

        LDAPString ::= OCTET STRING -- UTF-8 encoded,
                                    -- [ISO10646] characters

   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.  Although an LDAPOID is




Sermersheim                 Standards Track                     [Page 7]

RFC 4511                         LDAPv3                        June 2006


   encoded as an OCTET STRING, values are limited to the definition of
   <numericoid> given in Section 1.4 of [RFC4512].

        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
                                 -- [RFC4512]

   For example,

        1.3.6.1.4.1.1466.1.2.3

4.1.3.  Distinguished Name and Relative Distinguished Name

   An LDAPDN is defined to be the representation of a Distinguished Name
   (DN) after encoding according to the specification in [RFC4514].

        LDAPDN ::= LDAPString
                   -- Constrained to <distinguishedName> [RFC4514]

   A RelativeLDAPDN is defined to be the representation of a Relative
   Distinguished Name (RDN) after encoding according to the
   specification in [RFC4514].

        RelativeLDAPDN ::= LDAPString
                           -- Constrained to <name-component> [RFC4514]

4.1.4.  Attribute Descriptions

   The definition and encoding rules for attribute descriptions are
   defined in Section 2.5 of [RFC4512].  Briefly, an attribute
   description is an attribute type and zero or more options.

        AttributeDescription ::= LDAPString
                                -- Constrained to <attributedescription>
                                -- [RFC4512]

4.1.5.  Attribute Value

   A field of type AttributeValue is an OCTET STRING containing an
   encoded attribute value.  The attribute value is encoded according to
   the LDAP-specific encoding definition of its corresponding syntax.
   The LDAP-specific encoding definitions for different syntaxes and
   attribute types may be found in other documents and in particular
   [RFC4517].

        AttributeValue ::= OCTET STRING






Sermersheim                 Standards Track                     [Page 8]

RFC 4511                         LDAPv3                        June 2006


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

   Attribute values may be defined that have arbitrary and non-printable
   syntax.  Implementations MUST NOT display or attempt to decode an
   attribute value if its syntax is not known.  The implementation may
   attempt to discover the subschema of the source entry and to retrieve
   the descriptions of 'attributeTypes' from it [RFC4512].

   Clients MUST only send attribute values in a request that are valid
   according to the syntax defined for the attributes.

4.1.6.  Attribute Value Assertion

   The AttributeValueAssertion (AVA) type definition is similar to the
   one in the X.500 Directory standards.  It contains an attribute
   description and a matching rule ([RFC4512], Section 4.1.3) assertion
   value suitable for that type.  Elements of this type are typically
   used to assert that the value in assertionValue matches a value of an
   attribute.

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

        AssertionValue ::= OCTET STRING

   The syntax of the AssertionValue depends on the context of the LDAP
   operation being performed.  For example, the syntax of the EQUALITY
   matching rule for an attribute is used when performing a Compare
   operation.  Often this is the same syntax used for values of the
   attribute type, but in some cases the assertion syntax differs from
   the value syntax.  See objectIdentiferFirstComponentMatch in
   [RFC4517] for an example.

4.1.7.  Attribute and PartialAttribute

   Attributes and partial attributes consist of an attribute description
   and attribute values.  A PartialAttribute allows zero values, while
   Attribute requires at least one value.

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






Sermersheim                 Standards Track                     [Page 9]

RFC 4511                         LDAPv3                        June 2006


        Attribute ::= PartialAttribute(WITH COMPONENTS {
             ...,
             vals (SIZE(1..MAX))})

   No two of the attribute values may be equivalent as described by
   Section 2.2 of [RFC4512].  The set of attribute values is unordered.
   Implementations MUST NOT rely upon the ordering being repeatable.

4.1.8.  Matching Rule Identifier

   Matching rules are defined in Section 4.1.3 of [RFC4512].  A matching
   rule is identified in the protocol by the printable representation of
   either its <numericoid> or one of its short name descriptors
   [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.

        MatchingRuleId ::= LDAPString

4.1.9.  Result Message

   The LDAPResult is the construct used in this protocol to return
   success or failure indications from servers to clients.  To various
   requests, servers will return responses containing the elements found
   in LDAPResult to indicate the final status of the protocol operation
   request.

        LDAPResult ::= SEQUENCE {
             resultCode         ENUMERATED {
                  success                      (0),
                  operationsError              (1),
                  protocolError                (2),
                  timeLimitExceeded            (3),
                  sizeLimitExceeded            (4),
                  compareFalse                 (5),
                  compareTrue                  (6),
                  authMethodNotSupported       (7),
                  strongerAuthRequired         (8),
                       -- 9 reserved --
                  referral                     (10),
                  adminLimitExceeded           (11),
                  unavailableCriticalExtension (12),
                  confidentialityRequired      (13),
                  saslBindInProgress           (14),
                  noSuchAttribute              (16),
                  undefinedAttributeType       (17),
                  inappropriateMatching        (18),
                  constraintViolation          (19),
                  attributeOrValueExists       (20),
                  invalidAttributeSyntax       (21),



Sermersheim                 Standards Track                    [Page 10]

RFC 4511                         LDAPv3                        June 2006


                       -- 22-31 unused --
                  noSuchObject                 (32),
                  aliasProblem                 (33),
                  invalidDNSyntax              (34),
                       -- 35 reserved for undefined isLeaf --
                  aliasDereferencingProblem    (36),
                       -- 37-47 unused --
                  inappropriateAuthentication  (48),
                  invalidCredentials           (49),
                  insufficientAccessRights     (50),
                  busy                         (51),
                  unavailable                  (52),
                  unwillingToPerform           (53),
                  loopDetect                   (54),
                       -- 55-63 unused --
                  namingViolation              (64),
                  objectClassViolation         (65),
                  notAllowedOnNonLeaf          (66),
                  notAllowedOnRDN              (67),
                  entryAlreadyExists           (68),
                  objectClassModsProhibited    (69),
                       -- 70 reserved for CLDAP --
                  affectsMultipleDSAs          (71),
                       -- 72-79 unused --
                  other                        (80),
                  ...  },
             matchedDN          LDAPDN,
             diagnosticMessage  LDAPString,
             referral           [3] Referral OPTIONAL }

   The resultCode enumeration is extensible as defined in Section 3.8 of
   [RFC4520].  The meanings of the listed result codes are given in
   Appendix A.  If a server detects multiple errors for an operation,
   only one result code is returned.  The server should return the
   result code that best indicates the nature of the error encountered.
   Servers may return substituted result codes to prevent unauthorized
   disclosures.

   The diagnosticMessage field of this construct may, at the server's
   option, be used to return a string containing a textual, human-
   readable diagnostic message (terminal control and page formatting
   characters should be avoided).  As this diagnostic message is not
   standardized, implementations MUST NOT rely on the values returned.
   Diagnostic messages typically supplement the resultCode with
   additional information.  If the server chooses not to return a
   textual diagnostic, the diagnosticMessage field MUST be empty.





Sermersheim                 Standards Track                    [Page 11]

RFC 4511                         LDAPv3                        June 2006