diff --git a/examples/rfc4511.txt b/examples/rfc4511.txt
new file mode 100644
index 0000000..8041f30
--- /dev/null
+++ b/examples/rfc4511.txt
@@ -0,0 +1,3811 @@
+
+
+
+
+
+
+Network Working Group                                J. Sermersheim, Ed.
+Request for Comments: 4511                                  Novell, Inc.
+Obsoletes: 2251, 2830, 3771                                    June 2006
+Category: Standards Track
+
+
+      Lightweight Directory Access Protocol (LDAP): The Protocol
+
+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 (2006).
+
+Abstract
+
+   This document describes the protocol elements, along with their
+   semantics and encodings, of the Lightweight Directory Access Protocol
+   (LDAP).  LDAP provides access to distributed directory services that
+   act in accordance with X.500 data and service models.  These protocol
+   elements are based on those described in the X.500 Directory Access
+   Protocol (DAP).
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship to Other LDAP Specifications ..................3
+   2. Conventions .....................................................3
+   3. Protocol Model ..................................................4
+      3.1. Operation and LDAP Message Layer Relationship ..............5
+   4. Elements of Protocol ............................................5
+      4.1. Common Elements ............................................5
+           4.1.1. Message Envelope ....................................6
+           4.1.2. String Types ........................................7
+           4.1.3. Distinguished Name and Relative Distinguished Name ..8
+           4.1.4. Attribute Descriptions ..............................8
+           4.1.5. Attribute Value .....................................8
+           4.1.6. Attribute Value Assertion ...........................9
+           4.1.7. Attribute and PartialAttribute ......................9
+           4.1.8. Matching Rule Identifier ...........................10
+           4.1.9. Result Message .....................................10
+           4.1.10. Referral ..........................................12
+
+
+
+Sermersheim                 Standards Track                     [Page 1]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+           4.1.11. Controls ..........................................14
+      4.2. Bind Operation ............................................16
+           4.2.1. Processing of the Bind Request .....................17
+           4.2.2. Bind Response ......................................18
+      4.3. Unbind Operation ..........................................18
+      4.4. Unsolicited Notification ..................................19
+           4.4.1. Notice of Disconnection ............................19
+      4.5. Search Operation ..........................................20
+           4.5.1. Search Request .....................................20
+           4.5.2. Search Result ......................................27
+           4.5.3. Continuation References in the Search Result .......28
+      4.6. Modify Operation ..........................................31
+      4.7. Add Operation .............................................33
+      4.8. Delete Operation ..........................................34
+      4.9. Modify DN Operation .......................................34
+      4.10. Compare Operation ........................................36
+      4.11. Abandon Operation ........................................36
+      4.12. Extended Operation .......................................37
+      4.13. IntermediateResponse Message .............................39
+           4.13.1. Usage with LDAP ExtendedRequest and
+                   ExtendedResponse ..................................40
+           4.13.2. Usage with LDAP Request Controls ..................40
+      4.14. StartTLS Operation .......................................40
+           4.14.1. StartTLS Request ..................................40
+           4.14.2. StartTLS Response .................................41
+           4.14.3. Removal of the TLS Layer ..........................41
+   5. Protocol Encoding, Connection, and Transfer ....................42
+      5.1. Protocol Encoding .........................................42
+      5.2. Transmission Control Protocol (TCP) .......................43
+      5.3. Termination of the LDAP session ...........................43
+   6. Security Considerations ........................................43
+   7. Acknowledgements ...............................................45
+   8. Normative References ...........................................46
+   9. Informative References .........................................48
+   10. IANA Considerations ...........................................48
+   Appendix A. LDAP Result Codes .....................................49
+      A.1. Non-Error Result Codes ....................................49
+      A.2. Result Codes ..............................................49
+   Appendix B. Complete ASN.1 Definition .............................54
+   Appendix C. Changes ...............................................60
+      C.1. Changes Made to RFC 2251 ..................................60
+      C.2. Changes Made to RFC 2830 ..................................66
+      C.3. Changes Made to RFC 3771 ..................................66
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 2]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+1.  Introduction
+
+   The Directory is "a collection of open systems cooperating to provide
+   directory services" [X.500].  A directory user, which may be a human
+   or other entity, accesses the Directory through a client (or
+   Directory User Agent (DUA)).  The client, on behalf of the directory
+   user, interacts with one or more servers (or Directory System Agents
+   (DSA)).  Clients interact with servers using a directory access
+   protocol.
+
+   This document details the protocol elements of the Lightweight
+   Directory Access Protocol (LDAP), along with their semantics.
+   Following the description of protocol elements, it describes the way
+   in which the protocol elements are encoded and transferred.
+
+1.1.  Relationship to Other LDAP Specifications
+
+   This document is an integral part of the LDAP Technical Specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document, together with [RFC4510], [RFC4513], and [RFC4512],
+   obsoletes RFC 2251 in its entirety.  Section 3.3 is obsoleted by
+   [RFC4510].  Sections 4.2.1 (portions) and 4.2.2 are obsoleted by
+   [RFC4513].  Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+   4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+   are obsoleted by [RFC4512].  The remainder of RFC 2251 is obsoleted
+   by this document.  Appendix C.1 summarizes substantive changes in the
+   remainder.
+
+   This document obsoletes RFC 2830, Sections 2 and 4.  The remainder of
+   RFC 2830 is obsoleted by [RFC4513].  Appendix C.2 summarizes
+   substantive changes to the remaining sections.
+
+   This document also obsoletes RFC 3771 in entirety.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 3]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+   The term "transport connection" refers to the underlying transport
+   services used to carry the protocol exchange, as well as associations
+   established by these services.
+
+   The term "TLS layer" refers to Transport Layer Security (TLS)
+   services used in providing security services, as well as associations
+   established by these services.
+
+   The term "SASL layer" refers to Simply Authentication and Security
+   Layer (SASL) services used in providing security services, as well as
+   associations established by these services.
+
+   The term "LDAP message layer" refers to the LDAP Message Protocol
+   Data Unit (PDU) services used in providing directory services, as
+   well as associations established by these services.
+
+   The term "LDAP session" refers to combined services (transport
+   connection, TLS layer, SASL layer, LDAP message layer) and their
+   associations.
+
+   See the table in Section 5 for an illustration of these four terms.
+
+3.  Protocol Model
+
+   The general model adopted by this protocol is one of clients
+   performing protocol operations against servers.  In this model, a
+   client transmits a protocol request describing the operation to be
+   performed to a server.  The server is then responsible for performing
+   the necessary operation(s) in the Directory.  Upon completion of an
+   operation, the server typically returns a response containing
+   appropriate data to the requesting client.
+
+   Protocol operations are generally independent of one another.  Each
+   operation is processed as an atomic action, leaving the directory in
+   a consistent state.
+
+   Although servers are required to return responses whenever such
+   responses are defined in the protocol, there is no requirement for
+   synchronous behavior on the part of either clients or servers.
+   Requests and responses for multiple operations generally may be
+   exchanged between a client and server in any order.  If required,
+   synchronous behavior may be controlled by client applications.
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 4]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The core protocol operations defined in this document can be mapped
+   to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+   However, there is not a one-to-one mapping between LDAP operations
+   and X.500 Directory Access Protocol (DAP) operations.  Server
+   implementations acting as a gateway to X.500 directories may need to
+   make multiple DAP requests to service a single LDAP request.
+
+3.1.  Operation and LDAP Message Layer Relationship
+
+   Protocol operations are exchanged at the LDAP message layer.  When
+   the transport connection is closed, any uncompleted operations at the
+   LDAP message layer are abandoned (when possible) or are completed
+   without transmission of the response (when abandoning them is not
+   possible).  Also, when the transport connection is closed, the client
+   MUST NOT assume that any uncompleted update operations have succeeded
+   or failed.
+
+4.  Elements of Protocol
+
+   The protocol is described using Abstract Syntax Notation One
+   ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding
+   Rules ([BER]).  Section 5 specifies how the protocol elements are
+   encoded and transferred.
+
+   In order to support future extensions to this protocol, extensibility
+   is implied where it is allowed per ASN.1 (i.e., sequence, set,
+   choice, and enumerated types are extensible).  In addition, ellipses
+   (...) have been supplied in ASN.1 types that are explicitly
+   extensible as discussed in [RFC4520].  Because of the implied
+   extensibility, clients and servers MUST (unless otherwise specified)
+   ignore trailing SEQUENCE components whose tags they do not recognize.
+
+   Changes to the protocol other than through the extension mechanisms
+   described here require a different version number.  A client
+   indicates the version it is using as part of the BindRequest,
+   described in Section 4.2.  If a client has not sent a Bind, the
+   server MUST assume the client is using version 3 or later.
+
+   Clients may attempt to determine the protocol versions a server
+   supports by reading the 'supportedLDAPVersion' attribute from the
+   root DSE (DSA-Specific Entry) [RFC4512].
+
+4.1.  Common Elements
+
+   This section describes the LDAPMessage envelope Protocol Data Unit
+   (PDU) format, as well as data type definitions, which are used in the
+   protocol operations.
+
+
+
+
+Sermersheim                 Standards Track                     [Page 5]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+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 {
+             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,
+                  ...,
+                  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
+
+
+   For certain result codes (typically, but not restricted to
+   noSuchObject, aliasProblem, invalidDNSyntax, and
+   aliasDereferencingProblem), the matchedDN field is set (subject to
+   access controls) to the name of the last entry (object or alias) used
+   in finding the target (or base) object.  This will be a truncated
+   form of the provided name or, if an alias was dereferenced while
+   attempting to locate the entry, of the resulting name.  Otherwise,
+   the matchedDN field is empty.
+
+4.1.10.  Referral
+
+   The referral result code indicates that the contacted server cannot
+   or will not perform the operation and that one or more other servers
+   may be able to.  Reasons for this include:
+
+   - The target entry of the request is not held locally, but the server
+     has knowledge of its possible existence elsewhere.
+
+   - The operation is restricted on this server -- perhaps due to a
+     read-only copy of an entry to be modified.
+
+   The referral field is present in an LDAPResult if the resultCode is
+   set to referral, and it is absent with all other result codes.  It
+   contains one or more references to one or more servers or services
+   that may be accessed via LDAP or other protocols.  Referrals can be
+   returned in response to any operation request (except Unbind and
+   Abandon, which do not have responses).  At least one URI MUST be
+   present in the Referral.
+
+   During a Search operation, after the baseObject is located, and
+   entries are being evaluated, the referral is not returned.  Instead,
+   continuation references, described in Section 4.5.3, are returned
+   when other servers would need to be contacted to complete the
+   operation.
+
+        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+        URI ::= LDAPString     -- limited to characters permitted in
+                               -- URIs
+
+   If the client wishes to progress the operation, it contacts one of
+   the supported services found in the referral.  If multiple URIs are
+   present, the client assumes that any supported URI may be used to
+   progress the operation.
+
+   Clients that follow referrals MUST ensure that they do not loop
+   between servers.  They MUST NOT repeatedly contact the same server
+   for the same request with the same parameters.  Some clients use a
+
+
+
+Sermersheim                 Standards Track                    [Page 12]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   counter that is incremented each time referral handling occurs for an
+   operation, and these kinds of clients MUST be able to handle at least
+   ten nested referrals while progressing the operation.
+
+   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+   v6) [RFC793][RFC791] is written as an LDAP URL according to
+   [RFC4516].
+
+   Referral values that are LDAP URLs follow these rules:
+
+   - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be
+     present, with the new target object name.
+
+   - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
+
+   - If the <dn> part is present, the client uses this name in its next
+     request to progress the operation, and if it is not present the
+     client uses the same name as in the original request.
+
+   - Some servers (e.g., participating in distributed indexing) may
+     provide a different filter in a URL of a referral for a Search
+     operation.
+
+   - If the <filter> part of the LDAP URL is present, the client uses
+     this filter in its next request to progress this Search, and if it
+     is not present the client uses the same filter as it used for that
+     Search.
+
+   - For Search, it is RECOMMENDED that the <scope> part be present to
+     avoid ambiguity.
+
+   - If the <scope> part is missing, the scope of the original Search is
+     used by the client to progress the operation.
+
+   - Other aspects of the new request may be the same as or different
+     from the request that generated the referral.
+
+   Other kinds of URIs may be returned.  The syntax and semantics of
+   such URIs is left to future specifications.  Clients may ignore URIs
+   that they do not support.
+
+   UTF-8 encoded characters appearing in the string representation of a
+   DN, search filter, or other fields of the referral value may not be
+   legal for URIs (e.g., spaces) and MUST be escaped using the % method
+   in [RFC3986].
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 13]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.1.11.  Controls
+
+   Controls provide a mechanism whereby the semantics and arguments of
+   existing LDAP operations may be extended.  One or more controls may
+   be attached to a single LDAP message.  A control only affects the
+   semantics of the message it is attached to.
+
+   Controls sent by clients are termed 'request controls', and those
+   sent by servers are termed 'response controls'.
+
+        Controls ::= SEQUENCE OF control Control
+
+        Control ::= SEQUENCE {
+             controlType             LDAPOID,
+             criticality             BOOLEAN DEFAULT FALSE,
+             controlValue            OCTET STRING OPTIONAL }
+
+   The controlType field is the dotted-decimal representation of an
+   OBJECT IDENTIFIER that uniquely identifies the control.  This
+   provides unambiguous naming of controls.  Often, response control(s)
+   solicited by a request control share controlType values with the
+   request control.
+
+   The criticality field only has meaning in controls attached to
+   request messages (except UnbindRequest).  For controls attached to
+   response messages and the UnbindRequest, the criticality field SHOULD
+   be FALSE, and MUST be ignored by the receiving protocol peer.  A
+   value of TRUE indicates that it is unacceptable to perform the
+   operation without applying the semantics of the control.
+   Specifically, the criticality field is applied as follows:
+
+   - If the server does not recognize the control type, determines that
+     it is not appropriate for the operation, or is otherwise unwilling
+     to perform the operation with the control, and if the criticality
+     field is TRUE, the server MUST NOT perform the operation, and for
+     operations that have a response message, it MUST return with the
+     resultCode set to unavailableCriticalExtension.
+
+   - If the server does not recognize the control type, determines that
+     it is not appropriate for the operation, or is otherwise unwilling
+     to perform the operation with the control, and if the criticality
+     field is FALSE, the server MUST ignore the control.
+
+   - Regardless of criticality, if a control is applied to an
+     operation, it is applied consistently and impartially to the
+     entire operation.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 14]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The controlValue may contain information associated with the
+   controlType.  Its format is defined by the specification of the
+   control.  Implementations MUST be prepared to handle arbitrary
+   contents of the controlValue octet string, including zero bytes.  It
+   is absent only if there is no value information that is associated
+   with a control of its type.  When a controlValue is defined in terms
+   of ASN.1, and BER-encoded according to Section 5.1, it also follows
+   the extensibility rules in Section 4.
+
+   Servers list the controlType of request controls they recognize in
+   the 'supportedControl' attribute in the root DSE (Section 5.1 of
+   [RFC4512]).
+
+   Controls SHOULD NOT be combined unless the semantics of the
+   combination has been specified.  The semantics of control
+   combinations, if specified, are generally found in the control
+   specification most recently published.  When a combination of
+   controls is encountered whose semantics are invalid, not specified
+   (or not known), the message is considered not well-formed; thus, the
+   operation fails with protocolError.  Controls with a criticality of
+   FALSE may be ignored in order to arrive at a valid combination.
+   Additionally, unless order-dependent semantics are given in a
+   specification, the order of a combination of controls in the SEQUENCE
+   is ignored.  Where the order is to be ignored but cannot be ignored
+   by the server, the message is considered not well-formed, and the
+   operation fails with protocolError.  Again, controls with a
+   criticality of FALSE may be ignored in order to arrive at a valid
+   combination.
+
+   This document does not specify any controls.  Controls may be
+   specified in other documents.  Documents detailing control extensions
+   are to provide for each control:
+
+   - the OBJECT IDENTIFIER assigned to the control,
+
+   - direction as to what value the sender should provide for the
+     criticality field (note: the semantics of the criticality field are
+     defined above should not be altered by the control's
+     specification),
+
+   - whether the controlValue field is present, and if so, the format of
+     its contents,
+
+   - the semantics of the control, and
+
+   - optionally, semantics regarding the combination of the control with
+     other controls.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 15]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.2.  Bind Operation
+
+   The function of the Bind operation is to allow authentication
+   information to be exchanged between the client and server.  The Bind
+   operation should be thought of as the "authenticate" operation.
+   Operational, authentication, and security-related semantics of this
+   operation are given in [RFC4513].
+
+   The Bind request is defined as follows:
+
+        BindRequest ::= [APPLICATION 0] SEQUENCE {
+             version                 INTEGER (1 ..  127),
+             name                    LDAPDN,
+             authentication          AuthenticationChoice }
+
+        AuthenticationChoice ::= CHOICE {
+             simple                  [0] OCTET STRING,
+                                     -- 1 and 2 reserved
+             sasl                    [3] SaslCredentials,
+             ...  }
+
+        SaslCredentials ::= SEQUENCE {
+             mechanism               LDAPString,
+             credentials             OCTET STRING OPTIONAL }
+
+   Fields of the BindRequest are:
+
+   - version: A version number indicating the version of the protocol to
+     be used at the LDAP message layer.  This document describes version
+     3 of the protocol.  There is no version negotiation.  The client
+     sets this field to the version it desires.  If the server does not
+     support the specified version, it MUST respond with a BindResponse
+     where the resultCode is set to protocolError.
+
+   - name: If not empty, the name of the Directory object that the
+     client wishes to bind as.  This field may take on a null value (a
+     zero-length string) for the purposes of anonymous binds ([RFC4513],
+     Section 5.1) or when using SASL [RFC4422] authentication
+     ([RFC4513], Section 5.2).  Where the server attempts to locate the
+     named object, it SHALL NOT perform alias dereferencing.
+
+   - authentication: Information used in authentication.  This type is
+     extensible as defined in Section 3.7 of [RFC4520].  Servers that do
+     not support a choice supplied by a client return a BindResponse
+     with the resultCode set to authMethodNotSupported.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 16]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+     Textual passwords (consisting of a character sequence with a known
+     character set and encoding) transferred to the server using the
+     simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629]
+     encoded [Unicode].  Prior to transfer, clients SHOULD prepare text
+     passwords as "query" strings by applying the SASLprep [RFC4013]
+     profile of the stringprep [RFC3454] algorithm.  Passwords
+     consisting of other data (such as random octets) MUST NOT be
+     altered.  The determination of whether a password is textual is a
+     local client matter.
+
+4.2.1.  Processing of the Bind Request
+
+   Before processing a BindRequest, all uncompleted operations MUST
+   either complete or be abandoned.  The server may either wait for the
+   uncompleted operations to complete, or abandon them.  The server then
+   proceeds to authenticate the client in either a single-step or
+   multi-step Bind process.  Each step requires the server to return a
+   BindResponse to indicate the status of authentication.
+
+   After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+   until receiving the BindResponse.  Similarly, servers SHOULD NOT
+   process or respond to requests received while processing a
+   BindRequest.
+
+   If the client did not bind before sending a request and receives an
+   operationsError to that request, it may then send a BindRequest.  If
+   this also fails or the client chooses not to bind on the existing
+   LDAP session, it may terminate the LDAP session, re-establish it, and
+   begin again by first sending a BindRequest.  This will aid in
+   interoperating with servers implementing other versions of LDAP.
+
+   Clients may send multiple Bind requests to change the authentication
+   and/or security associations or to complete a multi-stage Bind
+   process.  Authentication from earlier binds is subsequently ignored.
+
+   For some SASL authentication mechanisms, it may be necessary for the
+   client to invoke the BindRequest multiple times ([RFC4513], Section
+   5.2).  Clients MUST NOT invoke operations between two Bind requests
+   made as part of a multi-stage Bind.
+
+   A client may abort a SASL bind negotiation by sending a BindRequest
+   with a different value in the mechanism field of SaslCredentials, or
+   an AuthenticationChoice other than sasl.
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 17]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   If the client sends a BindRequest with the sasl mechanism field as an
+   empty string, the server MUST return a BindResponse with the
+   resultCode set to authMethodNotSupported.  This will allow the client
+   to abort a negotiation if it wishes to try again with the same SASL
+   mechanism.
+
+4.2.2.  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 the
+   status of the client's request for authentication.
+
+   A successful Bind operation is indicated by a BindResponse with a
+   resultCode set to success.  Otherwise, an appropriate result code is
+   set in the BindResponse.  For BindResponse, the protocolError result
+   code may be used to indicate that the version number supplied by the
+   client is unsupported.
+
+   If the client receives a BindResponse where the resultCode is set to
+   protocolError, it is to assume that the server does not support this
+   version of LDAP.  While the client may be able proceed with another
+   version of this protocol (which may or may not require closing and
+   re-establishing the transport connection), how to proceed with
+   another version of this protocol is beyond the scope of this
+   document.  Clients that are unable or unwilling to proceed SHOULD
+   terminate the LDAP session.
+
+   The serverSaslCreds field is 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 simple choice, or the SASL mechanism
+   does not require the server to return information to the client, then
+   this field SHALL NOT be included in the BindResponse.
+
+4.3.  Unbind Operation
+
+   The function of the Unbind operation is to terminate an LDAP session.
+   The Unbind operation is not the antithesis of the Bind operation as
+   the name implies.  The naming of these operations are historical.
+   The Unbind operation should be thought of as the "quit" operation.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 18]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The Unbind operation is defined as follows:
+
+        UnbindRequest ::= [APPLICATION 2] NULL
+
+   The client, upon transmission of the UnbindRequest, and the server,
+   upon receipt of the UnbindRequest, are to gracefully terminate the
+   LDAP session as described in Section 5.3.  Uncompleted operations are
+   handled as specified in Section 3.1.
+
+4.4.  Unsolicited Notification
+
+   An unsolicited notification is an LDAPMessage sent from the server to
+   the client that 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 LDAP session 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 zero and protocolOp is set to the extendedResp
+   choice using the ExtendedResponse type (See Section 4.12).  The
+   responseName field of the ExtendedResponse always contains an LDAPOID
+   that is unique for this notification.
+
+   One unsolicited notification (Notice of Disconnection) is defined in
+   this document.  The specification of an unsolicited notification
+   consists of:
+
+   - the OBJECT IDENTIFIER assigned to the notification (to be specified
+     in the responseName,
+
+   - the format of the contents of the responseValue (if any),
+
+   - the circumstances which will cause the notification to be sent, and
+
+   - the semantics of the message.
+
+4.4.1.  Notice of Disconnection
+
+   This notification may be used by the server to advise the client that
+   the server is about to terminate the LDAP session on its own
+   initiative.  This notification is intended to assist clients in
+   distinguishing between an exceptional server condition and a
+   transient network failure.  Note that this notification is not a
+   response to an Unbind requested by the client.  Uncompleted
+   operations are handled as specified in Section 3.1.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 19]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+   is absent, and the resultCode is used to indicate the reason for the
+   disconnection.  When the strongerAuthRequired resultCode is returned
+   with this message, it indicates that the server has detected that an
+   established security association between the client and server has
+   unexpectedly failed or been compromised.
+
+   Upon transmission of the Notice of Disconnection, the server
+   gracefully terminates the LDAP session as described in Section 5.3.
+
+4.5.  Search Operation
+
+   The Search operation is used to request a server to return, subject
+   to access controls and other restrictions, a set of entries matching
+   a complex search criterion.  This can be used to read attributes from
+   a single entry, from entries immediately subordinate to a particular
+   entry, or from 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),
+                  derefAlways             (3) },
+             sizeLimit       INTEGER (0 ..  maxInt),
+             timeLimit       INTEGER (0 ..  maxInt),
+             typesOnly       BOOLEAN,
+             filter          Filter,
+             attributes      AttributeSelection }
+
+        AttributeSelection ::= SEQUENCE OF selector LDAPString
+                        -- The LDAPString is constrained to
+                        -- <attributeSelector> in Section 4.5.1.8
+
+        Filter ::= CHOICE {
+             and             [0] SET SIZE (1..MAX) OF filter Filter,
+             or              [1] SET SIZE (1..MAX) OF filter Filter,
+             not             [2] Filter,
+
+
+
+Sermersheim                 Standards Track                    [Page 20]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+             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,
+             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+                  initial [0] AssertionValue,  -- can occur at most once
+                  any     [1] AssertionValue,
+                  final   [2] AssertionValue } -- can occur at most once
+             }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+             matchingRule    [1] MatchingRuleId OPTIONAL,
+             type            [2] AttributeDescription OPTIONAL,
+             matchValue      [3] AssertionValue,
+             dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+   Note that an X.500 "list"-like operation can be emulated by the
+   client requesting a singleLevel Search operation with a filter
+   checking for the presence of the 'objectClass' attribute, and that an
+   X.500 "read"-like operation can be emulated by a baseObject Search
+   operation with the same filter.  A server that provides a gateway to
+   X.500 is not required to use the Read or List operations, although it
+   may choose to do so, and if it does, it must provide the same
+   semantics as the X.500 Search operation.
+
+4.5.1.1.  SearchRequest.baseObject
+
+   The name of the base object entry (or possibly the root) relative to
+   which the Search is to be performed.
+
+4.5.1.2.  SearchRequest.scope
+
+   Specifies the scope of the Search to be performed.  The semantics (as
+   described in [X.511]) of the defined values of this field are:
+
+      baseObject: The scope is constrained to the entry named by
+      baseObject.
+
+      singleLevel: The scope is constrained to the immediate
+      subordinates of the entry named by baseObject.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 21]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      wholeSubtree: The scope is constrained to the entry named by
+      baseObject and to all its subordinates.
+
+4.5.1.3.  SearchRequest.derefAliases
+
+   An indicator as to whether or not alias entries (as defined in
+   [RFC4512]) are to be dereferenced during stages of the Search
+   operation.
+
+   The act of dereferencing an alias includes recursively dereferencing
+   aliases that refer to aliases.
+
+   Servers MUST detect looping while dereferencing aliases in order to
+   prevent denial-of-service attacks of this nature.
+
+   The semantics of the defined values of this field are:
+
+      neverDerefAliases: Do not dereference aliases in searching or in
+      locating the base object of the Search.
+
+      derefInSearching: While searching subordinates of the base object,
+      dereference any alias within the search scope.  Dereferenced
+      objects become the vertices of further search scopes where the
+      Search operation is also applied.  If the search scope is
+      wholeSubtree, the Search continues in the subtree(s) of any
+      dereferenced object.  If the search scope is singleLevel, the
+      search is applied to any dereferenced objects and is not applied
+      to their subordinates.  Servers SHOULD eliminate duplicate entries
+      that arise due to alias dereferencing while searching.
+
+      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.
+
+4.5.1.4.  SearchRequest.sizeLimit
+
+   A size limit that restricts the maximum number of entries to be
+   returned as a result of the Search.  A value of zero in this field
+   indicates that no client-requested size limit restrictions are in
+   effect for the Search.  Servers may also enforce a maximum number of
+   entries to return.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 22]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.5.1.5.  SearchRequest.timeLimit
+
+   A time limit that restricts the maximum time (in seconds) allowed for
+   a Search.  A value of zero in this field indicates that no client-
+   requested time limit restrictions are in effect for the Search.
+   Servers may also enforce a maximum time limit for the Search.
+
+4.5.1.6.  SearchRequest.typesOnly
+
+   An indicator as to whether Search results are to contain both
+   attribute descriptions and values, or just attribute descriptions.
+   Setting this field to TRUE causes only attribute descriptions (and
+   not values) to be returned.  Setting this field to FALSE causes both
+   attribute descriptions and values to be returned.
+
+4.5.1.7.  SearchRequest.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 were explicit.)
+
+   A server MUST evaluate filters according to the three-valued logic of
+   [X.511] (1993), Clause 7.8.1.  In summary, a filter is evaluated to
+   "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.
+
+   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
+   Undefined otherwise.  A filter of the "or" choice is FALSE if all the
+   filters in the SET OF evaluate to FALSE, TRUE if at least one filter
+   is TRUE, and Undefined otherwise.  A filter of the 'not' choice is
+   TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
+   Undefined if it is Undefined.
+
+   A filter item evaluates to Undefined when the server would not be
+   able to determine whether the assertion value matches an entry.
+   Examples include:
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 23]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - An attribute description in an equalityMatch, substrings,
+     greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
+     is not recognized by the server.
+
+   - The attribute type does not define the appropriate matching rule.
+
+   - A MatchingRuleId in the extensibleMatch is not recognized by the
+     server or is not valid for the attribute type.
+
+   - The type of filtering requested is not implemented.
+
+   - The assertion value is invalid.
+
+   For example, if a server did not recognize the attribute type
+   shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
+   and (shoeSize<=12) would each evaluate to Undefined.
+
+   Servers MUST NOT return errors if attribute descriptions or matching
+   rule ids are not recognized, assertion values are invalid, or the
+   assertion syntax is not supported.  More details of filter processing
+   are given in Clause 7.8 of [X.511].
+
+4.5.1.7.1.  SearchRequest.filter.equalityMatch
+
+   The matching rule for an equalityMatch filter is defined by the
+   EQUALITY matching rule for the attribute type or subtype.  The filter
+   is TRUE when the EQUALITY rule returns TRUE as applied to the
+   attribute or subtype and the asserted value.
+
+4.5.1.7.2.  SearchRequest.filter.substrings
+
+   There SHALL be at most one 'initial' and at most one 'final' in the
+   'substrings' of a SubstringFilter.  If 'initial' is present, it SHALL
+   be the first element of 'substrings'.  If 'final' is present, it
+   SHALL be the last element of 'substrings'.
+
+   The matching rule for an AssertionValue in a substrings filter item
+   is defined by the SUBSTR matching rule for the attribute type or
+   subtype.  The filter is TRUE when the SUBSTR rule returns TRUE as
+   applied to the attribute or subtype and the asserted value.
+
+   Note that the AssertionValue in a substrings filter item conforms to
+   the assertion syntax of the EQUALITY matching rule for the attribute
+   type rather than to the assertion syntax of the SUBSTR matching rule
+   for the attribute type.  Conceptually, the entire SubstringFilter is
+   converted into an assertion value of the substrings matching rule
+   prior to applying the rule.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 24]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.5.1.7.3.  SearchRequest.filter.greaterOrEqual
+
+   The matching rule for a greaterOrEqual filter is defined by the
+   ORDERING matching rule for the attribute type or subtype.  The filter
+   is TRUE when the ORDERING rule returns FALSE as applied to the
+   attribute or subtype and the asserted value.
+
+4.5.1.7.4.  SearchRequest.filter.lessOrEqual
+
+   The matching rules for a lessOrEqual filter are defined by the
+   ORDERING and EQUALITY matching rules for the attribute type or
+   subtype.  The filter is TRUE when either the ORDERING or EQUALITY
+   rule returns TRUE as applied to the attribute or subtype and the
+   asserted value.
+
+4.5.1.7.5.  SearchRequest.filter.present
+
+   A present filter is TRUE when there is an attribute or subtype of the
+   specified attribute description present in an entry, FALSE when no
+   attribute or subtype of the specified attribute description is
+   present in an entry, and Undefined otherwise.
+
+4.5.1.7.6.  SearchRequest.filter.approxMatch
+
+   An approxMatch filter is TRUE when there is a value of the attribute
+   type or subtype for which some locally-defined approximate matching
+   algorithm (e.g., spelling variations, phonetic match, etc.) returns
+   TRUE.  If a value matches for equality, it also satisfies an
+   approximate match.  If approximate matching is not supported for the
+   attribute, this filter item should be treated as an equalityMatch.
+
+4.5.1.7.7.  SearchRequest.filter.extensibleMatch
+
+   The fields of the extensibleMatch filter item are evaluated as
+   follows:
+
+   - If the matchingRule field is absent, the type field MUST be
+     present, and an equality match is performed for that type.
+
+   - If the type field is absent and the matchingRule is present, the
+     matchValue is compared against all attributes in an entry that
+     support that matchingRule.
+
+   - If the type field is present and the matchingRule is present, the
+     matchValue is compared against the specified attribute type and its
+     subtypes.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 25]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - If the dnAttributes field is set to TRUE, the match is additionally
+     applied against all the AttributeValueAssertions in an entry's
+     distinguished name, and it evaluates to TRUE if there is at least
+     one attribute or subtype in the distinguished name for which the
+     filter item evaluates to TRUE.  The dnAttributes field is present
+     to alleviate the need for multiple versions of generic matching
+     rules (such as word matching), where one applies to entries and
+     another applies to entries and DN attributes as well.
+
+   The matchingRule used for evaluation determines the syntax for the
+   assertion value.  Once the matchingRule and attribute(s) have been
+   determined, the filter item evaluates to TRUE if it matches at least
+   one attribute type or subtype in the entry, FALSE if it does not
+   match any attribute type or subtype in the entry, and Undefined if
+   the matchingRule is not recognized, the matchingRule is unsuitable
+   for use with the specified type, or the assertionValue is invalid.
+
+4.5.1.8.  SearchRequest.attributes
+
+   A selection list of the attributes to be returned from each entry
+   that matches the search filter.  Attributes that are subtypes of
+   listed attributes are implicitly included.  LDAPString values of this
+   field are constrained to the following Augmented Backus-Naur Form
+   (ABNF) [RFC4234]:
+
+      attributeSelector = attributedescription / selectorspecial
+
+      selectorspecial = noattrs / alluserattrs
+
+      noattrs = %x31.2E.31 ; "1.1"
+
+      alluserattrs = %x2A ; asterisk ("*")
+
+      The <attributedescription> production is defined in Section 2.5 of
+      [RFC4512].
+
+      There are three special cases that may appear in the attributes
+      selection list:
+
+      1. An empty list with no attributes requests the return of all
+         user attributes.
+
+      2. A list containing "*" (with zero or more attribute
+         descriptions) requests the return of all user attributes in
+         addition to other listed (operational) attributes.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 26]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      3. A list containing only the OID "1.1" indicates that no
+         attributes are to be returned.  If "1.1" is provided with other
+         attributeSelector values, the "1.1" attributeSelector is
+         ignored.  This OID was chosen because it does not (and can not)
+         correspond to any attribute in use.
+
+   Client implementors should note that even if all user attributes are
+   requested, some attributes and/or attribute values of the entry may
+   not be included in Search results due to access controls or other
+   restrictions.  Furthermore, servers will not return operational
+   attributes, such as objectClasses or attributeTypes, unless they are
+   listed by name.  Operational attributes are described in [RFC4512].
+
+   Attributes are returned at most once in an entry.  If an attribute
+   description is named more than once in the list, the subsequent names
+   are ignored.  If an attribute description in the list is not
+   recognized, it is ignored by the server.
+
+4.5.2.  Search Result
+
+   The results of the Search operation are returned as zero or more
+   SearchResultEntry and/or SearchResultReference messages, followed by
+   a single SearchResultDone message.
+
+        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+             objectName      LDAPDN,
+             attributes      PartialAttributeList }
+
+        PartialAttributeList ::= SEQUENCE OF
+                             partialAttribute PartialAttribute
+
+        SearchResultReference ::= [APPLICATION 19] SEQUENCE
+                                  SIZE (1..MAX) OF uri URI
+
+        SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+   Each SearchResultEntry represents an entry found during the Search.
+   Each SearchResultReference represents an area not yet explored during
+   the Search.  The SearchResultEntry and SearchResultReference messages
+   may come in any order.  Following all the SearchResultReference and
+   SearchResultEntry responses, the server returns a SearchResultDone
+   response, which contains an indication of success or details any
+   errors that have occurred.
+
+   Each entry returned in a SearchResultEntry will contain all
+   appropriate attributes as specified in the attributes field of the
+   Search Request, subject to access control and other administrative
+   policy.  Note that the PartialAttributeList may hold zero elements.
+
+
+
+Sermersheim                 Standards Track                    [Page 27]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   This may happen when none of the attributes of an entry were
+   requested or could be returned.  Note also that the partialAttribute
+   vals set may hold zero elements.  This may happen when typesOnly is
+   requested, access controls prevent the return of values, or other
+   reasons.
+
+   Some attributes may be constructed by the server and appear in a
+   SearchResultEntry attribute list, although they are not stored
+   attributes of an entry.  Clients SHOULD NOT assume that all
+   attributes can be modified, even if this is permitted by access
+   control.
+
+   If the server's schema defines short names [RFC4512] for an attribute
+   type, then the server SHOULD use one of those names in attribute
+   descriptions for that attribute type (in preference to using the
+   <numericoid> [RFC4512] format of the attribute type's object
+   identifier).  The server SHOULD NOT use the short name if that name
+   is known by the server to be ambiguous, or if it is otherwise likely
+   to cause interoperability problems.
+
+4.5.3.  Continuation References in the Search Result
+
+   If the server was able to locate the entry referred to by the
+   baseObject but was unable or unwilling to search one or more non-
+   local entries, the server may return one or more
+   SearchResultReference messages, each containing a reference to
+   another set of servers for continuing the operation.  A server MUST
+   NOT return any SearchResultReference messages if it has not located
+   the baseObject and thus has not searched any entries.  In this case,
+   it would return a SearchResultDone containing either a referral or
+   noSuchObject result code (depending on the server's knowledge of the
+   entry named in the baseObject).
+
+   If a server holds a copy or partial copy of the subordinate naming
+   context (Section 5 of [RFC4512]), it may use the search filter to
+   determine whether or not to return a SearchResultReference response.
+   Otherwise, SearchResultReference responses are always returned when
+   in scope.
+
+   The SearchResultReference is of the same data type as the Referral.
+
+   If the client wishes to progress the Search, it issues a new Search
+   operation for each SearchResultReference that is returned.  If
+   multiple URIs are present, the client assumes that any supported URI
+   may be used to progress the operation.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 28]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Clients that follow search continuation references MUST ensure that
+   they do not loop between servers.  They MUST NOT repeatedly contact
+   the same server for the same request with the same parameters.  Some
+   clients use a counter that is incremented each time search result
+   reference handling occurs for an operation, and these kinds of
+   clients MUST be able to handle at least ten nested referrals while
+   progressing the operation.
+
+   Note that the Abandon operation described in Section 4.11 applies
+   only to a particular operation sent at the LDAP message layer between
+   a client and server.  The client must individually abandon subsequent
+   Search operations it wishes to.
+
+   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+   v6) [RFC793][RFC791] is written as an LDAP URL according to
+   [RFC4516].
+
+   SearchResultReference values that are LDAP URLs follow these rules:
+
+   - The <dn> part of the LDAP URL MUST be present, with the new target
+     object name.  The client uses this name when following the
+     reference.
+
+   - Some servers (e.g., participating in distributed indexing) may
+     provide a different filter in the LDAP URL.
+
+   - If the <filter> part of the LDAP URL is present, the client uses
+     this filter in its next request to progress this Search, and if it
+     is not present the client uses the same filter as it used for that
+     Search.
+
+   - If the originating search scope was singleLevel, the <scope> part
+     of the LDAP URL will be "base".
+
+   - It is RECOMMENDED that the <scope> part be present to avoid
+     ambiguity.  In the absence of a <scope> part, the scope of the
+     original Search request is assumed.
+
+   - Other aspects of the new Search request may be the same as or
+     different from the Search request that generated the
+     SearchResultReference.
+
+   - The name of an unexplored subtree in a SearchResultReference need
+     not be subordinate to the base object.
+
+   Other kinds of URIs may be returned.  The syntax and semantics of
+   such URIs is left to future specifications.  Clients may ignore URIs
+   that they do not support.
+
+
+
+Sermersheim                 Standards Track                    [Page 29]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   UTF-8-encoded characters appearing in the string representation of a
+   DN, search filter, or other fields of the referral value may not be
+   legal for URIs (e.g., spaces) and MUST be escaped using the % method
+   in [RFC3986].
+
+4.5.3.1.  Examples
+
+   For example, suppose the contacted server (hosta) holds the entry
+   <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>.  It
+   knows that both LDAP servers (hostb) and (hostc) hold
+   <OU=People,DC=Example,DC=NET> (one is the master and the other server
+   a shadow), and that LDAP-capable server (hostd) holds the subtree
+   <OU=Roles,DC=Example,DC=NET>.  If a wholeSubtree Search of
+   <DC=Example,DC=NET> is requested to the contacted server, it may
+   return the following:
+
+     SearchResultEntry for DC=Example,DC=NET
+     SearchResultEntry for CN=Manager,DC=Example,DC=NET
+     SearchResultReference {
+       ldap://hostb/OU=People,DC=Example,DC=NET??sub
+       ldap://hostc/OU=People,DC=Example,DC=NET??sub }
+     SearchResultReference {
+       ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
+     SearchResultDone (success)
+
+   Client implementors should note that when following a
+   SearchResultReference, additional SearchResultReference may be
+   generated.  Continuing the example, if the client contacted the
+   server (hostb) and issued the Search request for the subtree
+   <OU=People,DC=Example,DC=NET>, the server might respond as follows:
+
+     SearchResultEntry for OU=People,DC=Example,DC=NET
+     SearchResultReference {
+       ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
+     SearchResultReference {
+       ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+     SearchResultDone (success)
+
+   Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
+   requested to the contacted server, it may return the following:
+
+     SearchResultEntry for CN=Manager,DC=Example,DC=NET
+     SearchResultReference {
+       ldap://hostb/OU=People,DC=Example,DC=NET??base
+       ldap://hostc/OU=People,DC=Example,DC=NET??base }
+     SearchResultReference {
+       ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
+     SearchResultDone (success)
+
+
+
+Sermersheim                 Standards Track                    [Page 30]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   If the contacted server does not hold the base object for the Search,
+   but has knowledge of its possible location, then it may return a
+   referral to the client.  In this case, if the client requests a
+   subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
+   SearchResultDone containing a referral.
+
+     SearchResultDone (referral) {
+       ldap://hostg/DC=Example,DC=ORG??sub }
+
+4.6.  Modify Operation
+
+   The Modify operation allows a client to request that a modification
+   of an entry be performed on its behalf by a server.  The Modify
+   Request is defined as follows:
+
+        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+             object          LDAPDN,
+             changes         SEQUENCE OF change SEQUENCE {
+                  operation       ENUMERATED {
+                       add     (0),
+                       delete  (1),
+                       replace (2),
+                       ...  },
+                  modification    PartialAttribute } }
+
+   Fields of the Modify Request are:
+
+   - object: The value of this field contains the name of the entry to
+     be modified.  The server SHALL NOT perform any alias dereferencing
+     in determining the object to be modified.
+
+   - changes: A list of modifications to be performed on the entry.  The
+     entire list of modifications MUST be performed in the order they
+     are listed as a single atomic operation.  While individual
+     modifications may violate certain aspects of the directory schema
+     (such as the object class definition and Directory Information Tree
+     (DIT) content rule), the resulting entry after the entire list of
+     modifications is performed MUST conform to the requirements of the
+     directory model and controlling schema [RFC4512].
+
+     -  operation: Used to specify the type of modification being
+        performed.  Each operation type acts on the following
+        modification.  The values of this field have the following
+        semantics, respectively:
+
+           add: add values listed to the modification attribute,
+           creating the attribute if necessary.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 31]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+           delete: delete values listed from the modification attribute.
+           If no values are listed, or if all current values of the
+           attribute are listed, the entire attribute is removed.
+
+           replace: replace all existing values of the modification
+           attribute with the new values listed, creating the attribute
+           if it did not already exist.  A replace with no value will
+           delete the entire attribute if it exists, and it is ignored
+           if the attribute does not exist.
+
+     -  modification: A PartialAttribute (which may have an empty SET
+        of vals) used to hold the attribute type or attribute type and
+        values being modified.
+
+   Upon receipt of a Modify Request, the server attempts to perform the
+   necessary modifications to the DIT and returns the result in a Modify
+   Response, defined as follows:
+
+        ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+   The server will return to the client a single Modify Response
+   indicating either the successful completion of the DIT modification,
+   or the reason that the modification failed.  Due to the requirement
+   for atomicity in applying the list of modifications in the Modify
+   Request, the client may expect that no modifications of the DIT have
+   been performed if the Modify Response received indicates any sort of
+   error, and that all requested modifications have been performed if
+   the Modify Response indicates successful completion of the Modify
+   operation.  Whether or not the modification was applied cannot be
+   determined by the client if the Modify Response was not received
+   (e.g., the LDAP session was terminated or the Modify operation was
+   abandoned).
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.  The Modify operation cannot
+   be used to remove from an entry any of its distinguished values,
+   i.e., those values which form the entry's relative distinguished
+   name.  An attempt to do so will result in the server returning the
+   notAllowedOnRDN result code.  The Modify DN operation described in
+   Section 4.9 is used to rename an entry.
+
+   For attribute types that specify no equality matching, the rules in
+   Section 2.5.1 of [RFC4512] are followed.
+
+   Note that due to the simplifications made in LDAP, there is not a
+   direct mapping of the changes in an LDAP ModifyRequest onto the
+   changes of a DAP ModifyEntry operation, and different implementations
+
+
+
+
+Sermersheim                 Standards Track                    [Page 32]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   of LDAP-DAP gateways may use different means of representing the
+   change.  If successful, the final effect of the operations on the
+   entry MUST be identical.
+
+4.7.  Add Operation
+
+   The Add operation allows a client to request the addition of an entry
+   into the Directory.  The Add Request is defined as follows:
+
+        AddRequest ::= [APPLICATION 8] SEQUENCE {
+             entry           LDAPDN,
+             attributes      AttributeList }
+
+        AttributeList ::= SEQUENCE OF attribute Attribute
+
+   Fields of the Add Request are:
+
+   - entry: the name of the entry to be added.  The server SHALL NOT
+     dereference any aliases in locating the entry to be added.
+
+   - attributes: the list of attributes that, along with those from the
+     RDN, make up the content of the entry being added.  Clients MAY or
+     MAY NOT include the RDN attribute(s) in this list.  Clients MUST
+     NOT supply NO-USER-MODIFICATION attributes such as the
+     createTimestamp or creatorsName attributes, since the server
+     maintains these automatically.
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.  For attribute types that
+   specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+   are followed (this applies to the naming attribute in addition to any
+   multi-valued attributes being added).
+
+   The entry named in the entry field of the AddRequest MUST NOT exist
+   for the AddRequest to succeed.  The immediate superior (parent) of an
+   object or alias entry to be added MUST exist.  For example, if the
+   client attempted to add <CN=JS,DC=Example,DC=NET>, the
+   <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+   exist, then the server would return the noSuchObject result code with
+   the matchedDN field containing <DC=NET>.
+
+   Upon receipt of an Add Request, a server will attempt to add the
+   requested entry.  The result of the Add attempt will be returned to
+   the client in the Add Response, defined as follows:
+
+        AddResponse ::= [APPLICATION 9] LDAPResult
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 33]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   A response of success indicates that the new entry has been added to
+   the Directory.
+
+4.8.  Delete Operation
+
+   The Delete operation allows a client to request the removal of an
+   entry from the Directory.  The Delete Request is defined as follows:
+
+        DelRequest ::= [APPLICATION 10] LDAPDN
+
+   The Delete Request consists of the name of the entry to be deleted.
+   The server SHALL NOT dereference aliases while resolving the name of
+   the target entry to be removed.
+
+   Only leaf entries (those with no subordinate entries) can be deleted
+   with this operation.
+
+   Upon receipt of a Delete Request, a server will attempt to perform
+   the entry removal requested and return the result in the Delete
+   Response defined as follows:
+
+        DelResponse ::= [APPLICATION 11] LDAPResult
+
+4.9.  Modify DN Operation
+
+   The Modify DN operation allows a client to change the Relative
+   Distinguished Name (RDN) of an entry in the Directory and/or to move
+   a subtree of entries to a new location in the Directory.  The Modify
+   DN Request is defined as follows:
+
+        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+             entry           LDAPDN,
+             newrdn          RelativeLDAPDN,
+             deleteoldrdn    BOOLEAN,
+             newSuperior     [0] LDAPDN OPTIONAL }
+
+   Fields of the Modify DN Request are:
+
+   - entry: the name of the entry to be changed.  This entry may or may
+     not have subordinate entries.
+
+   - newrdn: the new RDN of the entry.  The value of the old RDN is
+     supplied when moving the entry to a new superior without changing
+     its RDN.  Attribute values of the new RDN not matching any
+     attribute value of the entry are added to the entry, and an
+     appropriate error is returned if this fails.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 34]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - deleteoldrdn: a boolean field that controls whether the old RDN
+     attribute values are to be retained as attributes of the entry or
+     deleted from the entry.
+
+   - newSuperior: if present, this is the name of an existing object
+     entry that becomes the immediate superior (parent) of the
+     existing entry.
+
+   The server SHALL NOT dereference any aliases in locating the objects
+   named in entry or newSuperior.
+
+   Upon receipt of a ModifyDNRequest, a server will attempt to perform
+   the name change and return the result in the Modify DN Response,
+   defined as follows:
+
+        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+   For example, if the entry named in the entry field was <cn=John
+   Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
+   newSuperior field was absent, then this operation would attempt to
+   rename the entry as <cn=John Cougar Smith,c=US>.  If there was
+   already an entry with that name, the operation would fail with the
+   entryAlreadyExists result code.
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.  For attribute types that
+   specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+   are followed (this pertains to newrdn and deleteoldrdn).
+
+   The object named in newSuperior MUST exist.  For example, if the
+   client attempted to add <CN=JS,DC=Example,DC=NET>, the
+   <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+   exist, then the server would return the noSuchObject result code with
+   the matchedDN field containing <DC=NET>.
+
+   If the deleteoldrdn field is TRUE, the attribute values forming the
+   old RDN (but not the new RDN) are deleted from the entry.  If the
+   deleteoldrdn field is FALSE, the attribute values forming the old RDN
+   will be retained as non-distinguished attribute values of the entry.
+
+   Note that X.500 restricts the ModifyDN operation to affect only
+   entries that are contained within a single server.  If the LDAP
+   server is mapped onto DAP, then this restriction will apply, and the
+   affectsMultipleDSAs result code will be returned if this error
+   occurred.  In general, clients MUST NOT expect to be able to perform
+   arbitrary movements of entries and subtrees between servers or
+   between naming contexts.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 35]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.10.  Compare Operation
+
+   The Compare operation allows a client to compare an assertion value
+   with the values of a particular attribute in a particular entry in
+   the Directory.  The Compare Request is defined as follows:
+
+        CompareRequest ::= [APPLICATION 14] SEQUENCE {
+             entry           LDAPDN,
+             ava             AttributeValueAssertion }
+
+   Fields of the Compare Request are:
+
+   - entry: the name of the entry to be compared.  The server SHALL NOT
+     dereference any aliases in locating the entry to be compared.
+
+   - ava: holds the attribute value assertion to be compared.
+
+   Upon receipt of a Compare Request, a server will attempt to perform
+   the requested comparison and return the result in the Compare
+   Response, defined as follows:
+
+        CompareResponse ::= [APPLICATION 15] LDAPResult
+
+   The resultCode is set to compareTrue, compareFalse, or an appropriate
+   error.  compareTrue indicates that the assertion value in the ava
+   field matches a value of the attribute or subtype according to the
+   attribute's EQUALITY matching rule.  compareFalse indicates that the
+   assertion value in the ava field and the values of the attribute or
+   subtype did not match.  Other result codes indicate either that the
+   result of the comparison was Undefined (Section 4.5.1.7), or that
+   some error occurred.
+
+   Note that some directory systems may establish access controls that
+   permit the values of certain attributes (such as userPassword) to be
+   compared but not interrogated by other means.
+
+4.11.  Abandon Operation
+
+   The function of the Abandon operation is to allow a client to request
+   that the server abandon an uncompleted operation.  The Abandon
+   Request is defined as follows:
+
+        AbandonRequest ::= [APPLICATION 16] MessageID
+
+   The MessageID is that of an operation that was requested earlier at
+   this LDAP message layer.  The Abandon request itself has its own
+   MessageID.  This is distinct from the MessageID of the earlier
+   operation being abandoned.
+
+
+
+Sermersheim                 Standards Track                    [Page 36]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   There is no response defined in the Abandon operation.  Upon receipt
+   of an AbandonRequest, the server MAY abandon the operation identified
+   by the MessageID.  Since the client cannot tell the difference
+   between a successfully abandoned operation and an uncompleted
+   operation, the application of the Abandon operation is limited to
+   uses where the client does not require an indication of its outcome.
+
+   Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
+
+   In the event that a server receives an Abandon Request on a Search
+   operation in the midst of transmitting responses to the Search, that
+   server MUST cease transmitting entry responses to the abandoned
+   request immediately, and it MUST NOT send the SearchResultDone.  Of
+   course, the server MUST ensure that only properly encoded LDAPMessage
+   PDUs are transmitted.
+
+   The ability to abandon other (particularly update) operations is at
+   the discretion of the server.
+
+   Clients should not send Abandon requests for the same operation
+   multiple times, and they MUST also be prepared to receive results
+   from operations they have abandoned (since these might have been in
+   transit when the Abandon was requested or might not be able to be
+   abandoned).
+
+   Servers MUST discard Abandon requests for messageIDs they do not
+   recognize, for operations that cannot be abandoned, and for
+   operations that have already been abandoned.
+
+4.12.  Extended Operation
+
+   The Extended operation allows additional operations to be defined for
+   services not already available in the protocol; for example, to Add
+   operations to install transport layer security (see Section 4.14).
+
+   The Extended operation allows clients to make requests and receive
+   responses with predefined syntaxes and semantics.  These may be
+   defined in RFCs or be private to particular implementations.
+
+   Each Extended operation consists of an Extended request and an
+   Extended response.
+
+        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+             requestName      [0] LDAPOID,
+             requestValue     [1] OCTET STRING OPTIONAL }
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 37]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The requestName is a dotted-decimal representation of the unique
+   OBJECT IDENTIFIER corresponding to the request.  The requestValue is
+   information in a form defined by that request, encapsulated inside an
+   OCTET STRING.
+
+   The server will respond to this with an LDAPMessage containing an
+   ExtendedResponse.
+
+        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             responseName     [10] LDAPOID OPTIONAL,
+             responseValue    [11] OCTET STRING OPTIONAL }
+
+   The responseName field, when present, contains an LDAPOID that is
+   unique for this extended operation or response.  This field is
+   optional (even when the extension specification defines an LDAPOID
+   for use in this field).  The field will be absent whenever the server
+   is unable or unwilling to determine the appropriate LDAPOID to
+   return, for instance, when the requestName cannot be parsed or its
+   value is not recognized.
+
+   Where the requestName is not recognized, the server returns
+   protocolError.  (The server may return protocolError in other cases.)
+
+   The requestValue and responseValue fields contain information
+   associated with the operation.  The format of these fields is defined
+   by the specification of the Extended operation.  Implementations MUST
+   be prepared to handle arbitrary contents of these fields, including
+   zero bytes.  Values that are defined in terms of ASN.1 and BER-
+   encoded according to Section 5.1 also follow the extensibility rules
+   in Section 4.
+
+   Servers list the requestName of Extended Requests they recognize in
+   the 'supportedExtension' attribute in the root DSE (Section 5.1 of
+   [RFC4512]).
+
+   Extended operations may be specified in other documents.  The
+   specification of an Extended operation consists of:
+
+   - the OBJECT IDENTIFIER assigned to the requestName,
+
+   - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+     that the same OBJECT IDENTIFIER may be used for both the
+     requestName and responseName),
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 38]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - the format of the contents of the requestValue and responseValue
+     (if any), and
+
+   - the semantics of the operation.
+
+4.13.  IntermediateResponse Message
+
+   While the Search operation provides a mechanism to return multiple
+   response messages for a single Search request, other operations, by
+   nature, do not provide for multiple response messages.
+
+   The IntermediateResponse message provides a general mechanism for
+   defining single-request/multiple-response operations in LDAP.  This
+   message is intended to be used in conjunction with the Extended
+   operation to define new single-request/multiple-response operations
+   or in conjunction with a control when extending existing LDAP
+   operations in a way that requires them to return Intermediate
+   response information.
+
+   It is intended that the definitions and descriptions of Extended
+   operations and controls that make use of the IntermediateResponse
+   message will define the circumstances when an IntermediateResponse
+   message can be sent by a server and the associated meaning of an
+   IntermediateResponse message sent in a particular circumstance.
+
+        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+                responseName     [0] LDAPOID OPTIONAL,
+                responseValue    [1] OCTET STRING OPTIONAL }
+
+   IntermediateResponse messages SHALL NOT be returned to the client
+   unless the client issues a request that specifically solicits their
+   return.  This document defines two forms of solicitation: Extended
+   operation and request control.  IntermediateResponse messages are
+   specified in documents describing the manner in which they are
+   solicited (i.e., in the Extended operation or request control
+   specification that uses them).  These specifications include:
+
+   - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+   - the format of the contents of the responseValue (if any), and
+
+   - the semantics associated with the IntermediateResponse message.
+
+   Extensions that allow the return of multiple types of
+   IntermediateResponse messages SHALL identify those types using unique
+   responseName values (note that one of these may specify no value).
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 39]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Sections 4.13.1 and 4.13.2 describe additional requirements on the
+   inclusion of responseName and responseValue in IntermediateResponse
+   messages.
+
+4.13.1.  Usage with LDAP ExtendedRequest and ExtendedResponse
+
+   A single-request/multiple-response operation may be defined using a
+   single ExtendedRequest message to solicit zero or more
+   IntermediateResponse messages of one or more kinds, followed by an
+   ExtendedResponse message.
+
+4.13.2.  Usage with LDAP Request Controls
+
+   A control's semantics may include the return of zero or more
+   IntermediateResponse messages prior to returning the final result
+   code for the operation.  One or more kinds of IntermediateResponse
+   messages may be sent in response to a request control.
+
+   All IntermediateResponse messages associated with request controls
+   SHALL include a responseName.  This requirement ensures that the
+   client can correctly identify the source of IntermediateResponse
+   messages when:
+
+   - two or more controls using IntermediateResponse messages are
+     included in a request for any LDAP operation or
+
+   - one or more controls using IntermediateResponse messages are
+     included in a request with an LDAP Extended operation that uses
+     IntermediateResponse messages.
+
+4.14.  StartTLS Operation
+
+   The Start Transport Layer Security (StartTLS) operation's purpose is
+   to initiate installation of a TLS layer.  The StartTLS operation is
+   defined using the Extended operation mechanism described in Section
+   4.12.
+
+4.14.1.  StartTLS Request
+
+   A client requests TLS establishment by transmitting a StartTLS
+   request message to the server.  The StartTLS request is defined in
+   terms of an ExtendedRequest.  The requestName is
+   "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+   absent.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 40]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The client MUST NOT send any LDAP PDUs at this LDAP message layer
+   following this request until it receives a StartTLS Extended response
+   and, in the case of a successful response, completes TLS
+   negotiations.
+
+   Detected sequencing problems (particularly those detailed in Section
+   3.1.1 of [RFC4513]) result in the resultCode being set to
+   operationsError.
+
+   If the server does not support TLS (whether by design or by current
+   configuration), it returns with the resultCode set to protocolError
+   as described in Section 4.12.
+
+4.14.2.  StartTLS Response
+
+   When a StartTLS request is received, servers supporting the operation
+   MUST return a StartTLS response message to the requestor.  The
+   responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section
+   4.12).  The responseValue is always absent.
+
+   If the server is willing and able to negotiate TLS, it returns the
+   StartTLS response with the resultCode set to success.  Upon client
+   receipt of a successful StartTLS response, protocol peers may
+   commence with TLS negotiation as discussed in Section 3 of [RFC4513].
+
+   If the server is otherwise unwilling or unable to perform this
+   operation, the server is to return an appropriate result code
+   indicating the nature of the problem.  For example, if the TLS
+   subsystem is not presently available, the server may indicate this by
+   returning with the resultCode set to unavailable.  In cases where a
+   non-success result code is returned, the LDAP session is left without
+   a TLS layer.
+
+4.14.3.  Removal of the TLS Layer
+
+   Either the client or server MAY remove the TLS layer and leave the
+   LDAP message layer intact by sending and receiving a TLS closure
+   alert.
+
+   The initiating protocol peer sends the TLS closure alert and MUST
+   wait until it receives a TLS closure alert from the other peer before
+   sending further LDAP PDUs.
+
+   When a protocol peer receives the initial TLS closure alert, it may
+   choose to allow the LDAP message layer to remain intact.  In this
+   case, it MUST immediately transmit a TLS closure alert.  Following
+   this, it MAY send and receive LDAP PDUs.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 41]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Protocol peers MAY terminate the LDAP session after sending or
+   receiving a TLS closure alert.
+
+5.  Protocol Encoding, Connection, and Transfer
+
+   This protocol is designed to run over connection-oriented, reliable
+   transports, where the data stream is divided into octets (8-bit
+   units), with each octet and each bit being significant.
+
+   One underlying service, LDAP over TCP, is defined in Section 5.2.
+   This service is generally applicable to applications providing or
+   consuming X.500-based directory services on the Internet.  This
+   specification was generally written with the TCP mapping in mind.
+   Specifications detailing other mappings may encounter various
+   obstacles.
+
+   Implementations of LDAP over TCP MUST implement the mapping as
+   described in Section 5.2.
+
+   This table illustrates the relationship among the different layers
+   involved in an exchange between two protocol peers:
+
+               +----------------------+
+               |  LDAP message layer  |
+               +----------------------+ > LDAP PDUs
+               +----------------------+ < data
+               |      SASL layer      |
+               +----------------------+ > SASL-protected data
+               +----------------------+ < data
+               |       TLS layer      |
+   Application +----------------------+ > TLS-protected data
+   ------------+----------------------+ < data
+     Transport | transport connection |
+               +----------------------+
+
+5.1.  Protocol Encoding
+
+   The protocol elements of LDAP SHALL be encoded for exchange using the
+   Basic Encoding Rules [BER] of [ASN.1] with the following
+   restrictions:
+
+   - Only the definite form of length encoding is used.
+
+   - OCTET STRING values are encoded in the primitive form only.
+
+   - If the value of a BOOLEAN type is true, the encoding of the value
+     octet is set to hex "FF".
+
+
+
+
+Sermersheim                 Standards Track                    [Page 42]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - If a value of a type is its default value, it is absent.  Only some
+     BOOLEAN and INTEGER types have default values in this protocol
+     definition.
+
+   These restrictions are meant to ease the overhead of encoding and
+   decoding certain elements in BER.
+
+   These restrictions do not apply to ASN.1 types encapsulated inside of
+   OCTET STRING values, such as attribute values, unless otherwise
+   stated.
+
+5.2.  Transmission Control Protocol (TCP)
+
+   The encoded LDAPMessage PDUs are mapped directly onto the TCP
+   [RFC793] bytestream using the BER-based encoding described in Section
+   5.1.  It is recommended that server implementations running over the
+   TCP provide a protocol listener on the Internet Assigned Numbers
+   Authority (IANA)-assigned LDAP port, 389 [PortReg].  Servers may
+   instead provide a listener on a different port number.  Clients MUST
+   support contacting servers on any valid TCP port.
+
+5.3.  Termination of the LDAP session
+
+   Termination of the LDAP session is typically initiated by the client
+   sending an UnbindRequest (Section 4.3), or by the server sending a
+   Notice of Disconnection (Section 4.4.1).  In these cases, each
+   protocol peer gracefully terminates the LDAP session by ceasing
+   exchanges at the LDAP message layer, tearing down any SASL layer,
+   tearing down any TLS layer, and closing the transport connection.
+
+   A protocol peer may determine that the continuation of any
+   communication would be pernicious, and in this case, it may abruptly
+   terminate the session by ceasing communication and closing the
+   transport connection.
+
+   In either case, when the LDAP session is terminated, uncompleted
+   operations are handled as specified in Section 3.1.
+
+6.  Security Considerations
+
+   This version of the protocol provides facilities for simple
+   authentication using a cleartext password, as well as any SASL
+   [RFC4422] mechanism.  Installing SASL and/or TLS layers can provide
+   integrity and other data security services.
+
+   It is also permitted that the server can return its credentials to
+   the client, if it chooses to do so.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 43]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Use of cleartext password is strongly discouraged where the
+   underlying transport service cannot guarantee confidentiality and may
+   result in disclosure of the password to unauthorized parties.
+
+   Servers are encouraged to prevent directory modifications by clients
+   that have authenticated anonymously [RFC4513].
+
+   Security considerations for authentication methods, SASL mechanisms,
+   and TLS are described in [RFC4513].
+
+   Note that SASL authentication exchanges do not provide data
+   confidentiality or integrity protection for the version or name
+   fields of the BindRequest or the resultCode, diagnosticMessage, or
+   referral fields of the BindResponse, nor for any information
+   contained in controls attached to Bind requests or responses.  Thus,
+   information contained in these fields SHOULD NOT be relied on unless
+   it is otherwise protected (such as by establishing protections at the
+   transport layer).
+
+   Implementors should note that various security factors (including
+   authentication and authorization information and data security
+   services) may change during the course of the LDAP session or even
+   during the performance of a particular operation.  For instance,
+   credentials could expire, authorization identities or access controls
+   could change, or the underlying security layer(s) could be replaced
+   or terminated.  Implementations should be robust in the handling of
+   changing security factors.
+
+   In some cases, it may be appropriate to continue the operation even
+   in light of security factor changes.  For instance, it may be
+   appropriate to continue an Abandon operation regardless of the
+   change, or to continue an operation when the change upgraded (or
+   maintained) the security factor.  In other cases, it may be
+   appropriate to fail or alter the processing of the operation.  For
+   instance, if confidential protections were removed, it would be
+   appropriate either to fail a request to return sensitive data or,
+   minimally, to exclude the return of sensitive data.
+
+   Implementations that cache attributes and entries obtained via LDAP
+   MUST ensure that access controls are maintained if that information
+   is to be provided to multiple clients, since servers may have access
+   control policies that prevent the return of entries or attributes in
+   Search results except to particular authenticated clients.  For
+   example, caches could serve result information only to the client
+   whose request caused it to be in the cache.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 44]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Servers may return referrals or Search result references that
+   redirect clients to peer servers.  It is possible for a rogue
+   application to inject such referrals into the data stream in an
+   attempt to redirect a client to a rogue server.  Clients are advised
+   to be aware of this and possibly reject referrals when
+   confidentiality measures are not in place.  Clients are advised to
+   reject referrals from the StartTLS operation.
+
+   The matchedDN and diagnosticMessage fields, as well as some
+   resultCode values (e.g., attributeOrValueExists and
+   entryAlreadyExists), could disclose the presence or absence of
+   specific data in the directory that is subject to access and other
+   administrative controls.  Server implementations should restrict
+   access to protected information equally under both normal and error
+   conditions.
+
+   Protocol peers MUST be prepared to handle invalid and arbitrary-
+   length protocol encodings.  Invalid protocol encodings include: BER
+   encoding exceptions, format string and UTF-8 encoding exceptions,
+   overflow exceptions, integer value exceptions, and binary mode on/off
+   flag exceptions.  The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+   excellent examples of these exceptions and test cases used to
+   discover flaws.
+
+   In the event that a protocol peer senses an attack that in its nature
+   could cause damage due to further communication at any layer in the
+   LDAP session, the protocol peer should abruptly terminate the LDAP
+   session as described in Section 5.3.
+
+7.  Acknowledgements
+
+   This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
+   Kille.  RFC 2251 was a product of the IETF ASID Working Group.
+
+   It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+   Mark Wahl.  RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+   It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga.
+   RFC 3771 was an individual submission to the IETF.
+
+   This document is a product of the IETF LDAPBIS Working Group.
+   Significant contributors of technical review and content include Kurt
+   Zeilenga, Steven Legg, and Hallvard Furuseth.
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 45]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+8.  Normative References
+
+   [ASN.1]       ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-
+                 1:2002 "Information Technology - Abstract Syntax
+                 Notation One (ASN.1): Specification of basic notation".
+
+   [BER]         ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+                 "Information technology - ASN.1 encoding rules:
+                 Specification of Basic Encoding Rules (BER), Canonical
+                 Encoding Rules (CER) and Distinguished Encoding Rules
+                 (DER)", 2002.
+
+   [ISO10646]    Universal Multiple-Octet Coded Character Set (UCS) -
+                 Architecture and Basic Multilingual Plane, ISO/IEC
+                 10646-1 : 1993.
+
+   [RFC791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
+                 September 1981.
+
+   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
+                 793, September 1981.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3454]     Hoffman P. and M. Blanchet, "Preparation of
+                 Internationalized Strings ('stringprep')", RFC 3454,
+                 December 2002.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
+                 "Uniform Resource Identifier (URI): Generic Syntax",
+                 STD 66, RFC 3986, January 2005.
+
+   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
+                 Names and Passwords", RFC 4013, February 2005.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4346]     Dierks, T. and E. Rescorla, "The TLS Protocol Version
+                 1.1", RFC 4346, March 2006.
+
+   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+                 Authentication and Security Layer (SASL)", RFC 4422,
+                 June 2006.
+
+
+
+Sermersheim                 Standards Track                    [Page 46]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4512]     Zeilenga, K., Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): Uniform Resource Locator", RFC
+                 4516, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [X.500]       ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+                 Models and Service", 1993.
+
+   [X.511]       ITU-T Rec. X.511, "The Directory: Abstract Service
+                 Definition", 1993.
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 47]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+9.  Informative References
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+   [PortReg]     IANA, "Port Numbers",
+                 <http://www.iana.org/assignments/port-numbers>.
+
+   [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+                 <http://www.ee.oulu.fi/research/ouspg/protos/testing/
+                 c06/ldapv3/>.
+
+10.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   result code registry to indicate that this document provides the
+   definitive technical specification for result codes 0-36, 48-54, 64-
+   70, 80-90.  It is also noted that one resultCode value
+   (strongAuthRequired) has been renamed (to strongerAuthRequired).
+
+   The IANA has also updated the LDAP Protocol Mechanism registry to
+   indicate that this document and [RFC4513] provides the definitive
+   technical specification for the StartTLS (1.3.6.1.4.1.1466.20037)
+   Extended operation.
+
+   IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the
+   ASN.1 module defined in this document.
+
+        Subject: Request for LDAP Object Identifier Registration
+        Person & email address to contact for further information:
+             Jim Sermersheim <jimse@novell.com>
+        Specification: RFC 4511
+        Author/Change Controller: IESG
+        Comments:
+             Identifies the LDAP ASN.1 module
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 48]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Appendix A.  LDAP Result Codes
+
+   This normative appendix details additional considerations regarding
+   LDAP result codes and provides a brief, general description of each
+   LDAP result code enumerated in Section 4.1.9.
+
+   Additional result codes MAY be defined for use with extensions
+   [RFC4520].  Client implementations SHALL treat any result code that
+   they do not recognize as an unknown error condition.
+
+   The descriptions provided here do not fully account for result code
+   substitutions used to prevent unauthorized disclosures (such as
+   substitution of noSuchObject for insufficientAccessRights, or
+   invalidCredentials for insufficientAccessRights).
+
+A.1.  Non-Error Result Codes
+
+   These result codes (called "non-error" result codes) do not indicate
+   an error condition:
+
+        success (0),
+        compareFalse (5),
+        compareTrue (6),
+        referral (10), and
+        saslBindInProgress (14).
+
+   The success, compareTrue, and compareFalse result codes indicate
+   successful completion (and, hence, are referred to as "successful"
+   result codes).
+
+   The referral and saslBindInProgress result codes indicate the client
+   needs to take additional action to complete the operation.
+
+A.2.  Result Codes
+
+   Existing LDAP result codes are described as follows:
+
+      success (0)
+         Indicates the successful completion of an operation.  Note:
+         this code is not used with the Compare operation.  See
+         compareFalse (5) and compareTrue (6).
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 49]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      operationsError (1)
+         Indicates that the operation is not properly sequenced with
+         relation to other operations (of same or different type).
+
+         For example, this code is returned if the client attempts to
+         StartTLS [RFC4346] while there are other uncompleted operations
+         or if a TLS layer was already installed.
+
+      protocolError (2)
+         Indicates the server received data that is not well-formed.
+
+         For Bind operation only, this code is also used to indicate
+         that the server does not support the requested protocol
+         version.
+
+         For Extended operations only, this code is also used to
+         indicate that the server does not support (by design or
+         configuration) the Extended operation associated with the
+         requestName.
+
+         For request operations specifying multiple controls, this may
+         be used to indicate that the server cannot ignore the order
+         of the controls as specified, or that the combination of the
+         specified controls is invalid or unspecified.
+
+      timeLimitExceeded (3)
+         Indicates that the time limit specified by the client was
+         exceeded before the operation could be completed.
+
+      sizeLimitExceeded (4)
+         Indicates that the size limit specified by the client was
+         exceeded before the operation could be completed.
+
+      compareFalse (5)
+         Indicates that the Compare operation has successfully
+         completed and the assertion has evaluated to FALSE or
+         Undefined.
+
+      compareTrue (6)
+         Indicates that the Compare operation has successfully
+         completed and the assertion has evaluated to TRUE.
+
+      authMethodNotSupported (7)
+         Indicates that the authentication method or mechanism is not
+         supported.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 50]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      strongerAuthRequired (8)
+         Indicates the server requires strong(er) authentication in
+         order to complete the operation.
+
+         When used with the Notice of Disconnection operation, this
+         code indicates that the server has detected that an
+         established security association between the client and
+         server has unexpectedly failed or been compromised.
+
+      referral (10)
+         Indicates that a referral needs to be chased to complete the
+         operation (see Section 4.1.10).
+
+      adminLimitExceeded (11)
+         Indicates that an administrative limit has been exceeded.
+
+      unavailableCriticalExtension (12)
+         Indicates a critical control is unrecognized (see Section
+         4.1.11).
+
+      confidentialityRequired (13)
+         Indicates that data confidentiality protections are required.
+
+      saslBindInProgress (14)
+         Indicates the server requires the client to send a new bind
+         request, with the same SASL mechanism, to continue the
+         authentication process (see Section 4.2).
+
+      noSuchAttribute (16)
+         Indicates that the named entry does not contain the specified
+         attribute or attribute value.
+
+      undefinedAttributeType (17)
+         Indicates that a request field contains an unrecognized
+         attribute description.
+
+      inappropriateMatching (18)
+         Indicates that an attempt was made (e.g., in an assertion) to
+         use a matching rule not defined for the attribute type
+         concerned.
+
+      constraintViolation (19)
+         Indicates that the client supplied an attribute value that
+         does not conform to the constraints placed upon it by the
+         data model.
+
+         For example, this code is returned when multiple values are
+         supplied to an attribute that has a SINGLE-VALUE constraint.
+
+
+
+Sermersheim                 Standards Track                    [Page 51]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      attributeOrValueExists (20)
+         Indicates that the client supplied an attribute or value to
+         be added to an entry, but the attribute or value already
+         exists.
+
+      invalidAttributeSyntax (21)
+         Indicates that a purported attribute value does not conform
+         to the syntax of the attribute.
+
+      noSuchObject (32)
+         Indicates that the object does not exist in the DIT.
+
+      aliasProblem (33)
+         Indicates that an alias problem has occurred.  For example,
+         the code may used to indicate an alias has been dereferenced
+         that names no object.
+
+      invalidDNSyntax (34)
+         Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search
+         base, target entry, ModifyDN newrdn, etc.) of a request does
+         not conform to the required syntax or contains attribute
+         values that do not conform to the syntax of the attribute's
+         type.
+
+      aliasDereferencingProblem (36)
+         Indicates that a problem occurred while dereferencing an
+         alias.  Typically, an alias was encountered in a situation
+         where it was not allowed or where access was denied.
+
+      inappropriateAuthentication (48)
+         Indicates the server requires the client that had attempted
+         to bind anonymously or without supplying credentials to
+         provide some form of credentials.
+
+      invalidCredentials (49)
+         Indicates that the provided credentials (e.g., the user's name
+         and password) are invalid.
+
+      insufficientAccessRights (50)
+         Indicates that the client does not have sufficient access
+         rights to perform the operation.
+
+      busy (51)
+         Indicates that the server is too busy to service the
+         operation.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 52]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      unavailable (52)
+         Indicates that the server is shutting down or a subsystem
+         necessary to complete the operation is offline.
+
+      unwillingToPerform (53)
+         Indicates that the server is unwilling to perform the
+         operation.
+
+      loopDetect (54)
+         Indicates that the server has detected an internal loop (e.g.,
+         while dereferencing aliases or chaining an operation).
+
+      namingViolation (64)
+         Indicates that the entry's name violates naming restrictions.
+
+      objectClassViolation (65)
+         Indicates that the entry violates object class restrictions.
+
+      notAllowedOnNonLeaf (66)
+         Indicates that the operation is inappropriately acting upon a
+         non-leaf entry.
+
+      notAllowedOnRDN (67)
+         Indicates that the operation is inappropriately attempting to
+         remove a value that forms the entry's relative distinguished
+         name.
+
+      entryAlreadyExists (68)
+         Indicates that the request cannot be fulfilled (added, moved,
+         or renamed) as the target entry already exists.
+
+      objectClassModsProhibited (69)
+         Indicates that an attempt to modify the object class(es) of
+         an entry's 'objectClass' attribute is prohibited.
+
+         For example, this code is returned when a client attempts to
+         modify the structural object class of an entry.
+
+      affectsMultipleDSAs (71)
+         Indicates that the operation cannot be performed as it would
+         affect multiple servers (DSAs).
+
+      other (80)
+         Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 53]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Appendix B.  Complete ASN.1 Definition
+
+   This appendix is normative.
+
+        Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
+        -- Copyright (C) The Internet Society (2006).  This version of
+        -- this ASN.1 module is part of RFC 4511; see the RFC itself
+        -- for full legal notices.
+        DEFINITIONS
+        IMPLICIT TAGS
+        EXTENSIBILITY IMPLIED ::=
+
+        BEGIN
+
+        LDAPMessage ::= SEQUENCE {
+             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,
+                  ...,
+                  intermediateResponse  IntermediateResponse },
+             controls       [0] Controls OPTIONAL }
+
+        MessageID ::= INTEGER (0 ..  maxInt)
+
+        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+        LDAPString ::= OCTET STRING -- UTF-8 encoded,
+                                    -- [ISO10646] characters
+
+
+
+
+Sermersheim                 Standards Track                    [Page 54]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+                                 -- [RFC4512]
+
+        LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
+                              -- [RFC4514]
+
+        RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+                                      -- [RFC4514]
+
+        AttributeDescription ::= LDAPString
+                                -- Constrained to <attributedescription>
+                                -- [RFC4512]
+
+        AttributeValue ::= OCTET STRING
+
+        AttributeValueAssertion ::= SEQUENCE {
+             attributeDesc   AttributeDescription,
+             assertionValue  AssertionValue }
+
+        AssertionValue ::= OCTET STRING
+
+        PartialAttribute ::= SEQUENCE {
+             type       AttributeDescription,
+             vals       SET OF value AttributeValue }
+
+        Attribute ::= PartialAttribute(WITH COMPONENTS {
+             ...,
+             vals (SIZE(1..MAX))})
+
+        MatchingRuleId ::= LDAPString
+
+        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),
+
+
+
+Sermersheim                 Standards Track                    [Page 55]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+                  noSuchAttribute              (16),
+                  undefinedAttributeType       (17),
+                  inappropriateMatching        (18),
+                  constraintViolation          (19),
+                  attributeOrValueExists       (20),
+                  invalidAttributeSyntax       (21),
+                       -- 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 }
+
+        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+        URI ::= LDAPString     -- limited to characters permitted in
+                               -- URIs
+
+        Controls ::= SEQUENCE OF control Control
+
+        Control ::= SEQUENCE {
+             controlType             LDAPOID,
+             criticality             BOOLEAN DEFAULT FALSE,
+             controlValue            OCTET STRING OPTIONAL }
+
+
+
+
+Sermersheim                 Standards Track                    [Page 56]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        BindRequest ::= [APPLICATION 0] SEQUENCE {
+             version                 INTEGER (1 ..  127),
+             name                    LDAPDN,
+             authentication          AuthenticationChoice }
+
+        AuthenticationChoice ::= CHOICE {
+             simple                  [0] OCTET STRING,
+                                     -- 1 and 2 reserved
+             sasl                    [3] SaslCredentials,
+             ...  }
+
+        SaslCredentials ::= SEQUENCE {
+             mechanism               LDAPString,
+             credentials             OCTET STRING OPTIONAL }
+
+        BindResponse ::= [APPLICATION 1] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             serverSaslCreds    [7] OCTET STRING OPTIONAL }
+
+        UnbindRequest ::= [APPLICATION 2] NULL
+
+        SearchRequest ::= [APPLICATION 3] SEQUENCE {
+             baseObject      LDAPDN,
+             scope           ENUMERATED {
+                  baseObject              (0),
+                  singleLevel             (1),
+                  wholeSubtree            (2),
+                  ...  },
+             derefAliases    ENUMERATED {
+                  neverDerefAliases       (0),
+                  derefInSearching        (1),
+                  derefFindingBaseObj     (2),
+                  derefAlways             (3) },
+             sizeLimit       INTEGER (0 ..  maxInt),
+             timeLimit       INTEGER (0 ..  maxInt),
+             typesOnly       BOOLEAN,
+             filter          Filter,
+             attributes      AttributeSelection }
+
+        AttributeSelection ::= SEQUENCE OF selector LDAPString
+                       -- The LDAPString is constrained to
+                       -- <attributeSelector> in Section 4.5.1.8
+
+        Filter ::= CHOICE {
+             and             [0] SET SIZE (1..MAX) OF filter Filter,
+             or              [1] SET SIZE (1..MAX) OF filter Filter,
+             not             [2] Filter,
+             equalityMatch   [3] AttributeValueAssertion,
+
+
+
+Sermersheim                 Standards Track                    [Page 57]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+             substrings      [4] SubstringFilter,
+             greaterOrEqual  [5] AttributeValueAssertion,
+             lessOrEqual     [6] AttributeValueAssertion,
+             present         [7] AttributeDescription,
+             approxMatch     [8] AttributeValueAssertion,
+             extensibleMatch [9] MatchingRuleAssertion,
+             ...  }
+
+        SubstringFilter ::= SEQUENCE {
+             type           AttributeDescription,
+             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+                  initial [0] AssertionValue,  -- can occur at most once
+                  any     [1] AssertionValue,
+                  final   [2] AssertionValue } -- can occur at most once
+             }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+             matchingRule    [1] MatchingRuleId OPTIONAL,
+             type            [2] AttributeDescription OPTIONAL,
+             matchValue      [3] AssertionValue,
+             dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+             objectName      LDAPDN,
+             attributes      PartialAttributeList }
+
+        PartialAttributeList ::= SEQUENCE OF
+                             partialAttribute PartialAttribute
+
+        SearchResultReference ::= [APPLICATION 19] SEQUENCE
+                                  SIZE (1..MAX) OF uri URI
+
+        SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+             object          LDAPDN,
+             changes         SEQUENCE OF change SEQUENCE {
+                  operation       ENUMERATED {
+                       add     (0),
+                       delete  (1),
+                       replace (2),
+                       ...  },
+                  modification    PartialAttribute } }
+
+        ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 58]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        AddRequest ::= [APPLICATION 8] SEQUENCE {
+             entry           LDAPDN,
+             attributes      AttributeList }
+
+        AttributeList ::= SEQUENCE OF attribute Attribute
+
+        AddResponse ::= [APPLICATION 9] LDAPResult
+
+        DelRequest ::= [APPLICATION 10] LDAPDN
+
+        DelResponse ::= [APPLICATION 11] LDAPResult
+
+        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+             entry           LDAPDN,
+             newrdn          RelativeLDAPDN,
+             deleteoldrdn    BOOLEAN,
+             newSuperior     [0] LDAPDN OPTIONAL }
+
+        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+        CompareRequest ::= [APPLICATION 14] SEQUENCE {
+             entry           LDAPDN,
+             ava             AttributeValueAssertion }
+
+        CompareResponse ::= [APPLICATION 15] LDAPResult
+
+        AbandonRequest ::= [APPLICATION 16] MessageID
+
+        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+             requestName      [0] LDAPOID,
+             requestValue     [1] OCTET STRING OPTIONAL }
+
+        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             responseName     [10] LDAPOID OPTIONAL,
+             responseValue    [11] OCTET STRING OPTIONAL }
+
+        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+             responseName     [0] LDAPOID OPTIONAL,
+             responseValue    [1] OCTET STRING OPTIONAL }
+
+        END
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 59]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Appendix C.  Changes
+
+   This appendix is non-normative.
+
+   This appendix summarizes substantive changes made to RFC 2251, RFC
+   2830, and RFC 3771.
+
+C.1.  Changes Made to RFC 2251
+
+   This section summarizes the substantive changes made to Sections 1,
+   2, 3.1, and 4, and the remainder of RFC 2251.  Readers should
+   consult [RFC4512] and [RFC4513] for summaries of changes to other
+   sections.
+
+C.1.1.  Section 1 (Status of this Memo)
+
+   - Removed IESG note.  Post publication of RFC 2251, mandatory LDAP
+     authentication mechanisms have been standardized which are
+     sufficient to remove this note.  See [RFC4513] for authentication
+     mechanisms.
+
+C.1.2.  Section 3.1 (Protocol Model) and others
+
+   - Removed notes giving history between LDAP v1, v2, and v3.  Instead,
+     added sufficient language so that this document can stand on its
+     own.
+
+C.1.3.  Section 4 (Elements of Protocol)
+
+   - Clarified where the extensibility features of ASN.1 apply to the
+     protocol.  This change affected various ASN.1 types by the
+     inclusion of ellipses (...) to certain elements.
+   - Removed the requirement that servers that implement version 3 or
+     later MUST provide the 'supportedLDAPVersion' attribute.  This
+     statement provided no interoperability advantages.
+
+C.1.4.  Section 4.1.1 (Message Envelope)
+
+   - There was a mandatory requirement for the server to return a
+     Notice of Disconnection and drop the transport connection when a
+     PDU is malformed in a certain way.  This has been updated such that
+     the server SHOULD return the Notice of Disconnection, and it MUST
+     terminate the LDAP Session.
+
+C.1.5.  Section 4.1.1.1 (Message ID)
+
+   - Required that the messageID of requests MUST be non-zero as the
+     zero is reserved for Notice of Disconnection.
+
+
+
+Sermersheim                 Standards Track                    [Page 60]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - Specified when it is and isn't appropriate to return an already
+     used messageID.  RFC 2251 accidentally imposed synchronous server
+     behavior in its wording of this.
+
+C.1.6.  Section 4.1.2 (String Types)
+
+   - Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
+
+C.1.7.  Section 4.1.5.1 (Binary Option) and others
+
+   - Removed the Binary Option from the specification.  There are
+     numerous interoperability problems associated with this method of
+     alternate attribute type encoding.  Work to specify a suitable
+     replacement is ongoing.
+
+C.1.8.  Section 4.1.8 (Attribute)
+
+   - Combined the definitions of PartialAttribute and Attribute here,
+     and defined Attribute in terms of PartialAttribute.
+
+C.1.9.  Section 4.1.10 (Result Message)
+
+   - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
+     be sent for non-error results.
+   - Moved some language into Appendix A, and referred the reader there.
+   - Allowed matchedDN to be present for other result codes than those
+     listed in RFC 2251.
+   - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to
+     clarify that this code may often be returned to indicate that a
+     stronger authentication is needed to perform a given operation.
+
+C.1.10.  Section 4.1.11 (Referral)
+
+   - Defined referrals in terms of URIs rather than URLs.
+   - Removed the requirement that all referral URIs MUST be equally
+     capable of progressing the operation.  The statement was ambiguous
+     and provided no instructions on how to carry it out.
+   - Added the requirement that clients MUST NOT loop between servers.
+   - Clarified the instructions for using LDAPURLs in referrals, and in
+     doing so added a recommendation that the scope part be present.
+   - Removed imperatives which required clients to use URLs in specific
+     ways to progress an operation.  These did nothing for
+     interoperability.
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 61]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+C.1.11.  Section 4.1.12 (Controls)
+
+   - Specified how control values defined in terms of ASN.1 are to be
+     encoded.
+   - Noted that the criticality field is only applied to request
+     messages (except UnbindRequest), and must be ignored when present
+     on response messages and UnbindRequest.
+   - Specified that non-critical controls may be ignored at the
+     server's discretion.  There was confusion in the original wording
+     which led some to believe that recognized controls may not be
+     ignored as long as they were associated with a proper request.
+   - Added language regarding combinations of controls and the ordering
+     of controls on a message.
+   - Specified that when the semantics of the combination of controls
+     is undefined or unknown, it results in a protocolError.
+   - Changed "The server MUST be prepared" to "Implementations MUST be
+     prepared" in paragraph 8 to reflect that both client and server
+     implementations must be able to handle this (as both parse
+     controls).
+
+C.1.12.  Section 4.2 (Bind Operation)
+
+   - Mandated that servers return protocolError when the version is not
+     supported.
+   - Disambiguated behavior when the simple authentication is used, the
+     name is empty, and the password is non-empty.
+   - Required servers to not dereference aliases for Bind.  This was
+     added for consistency with other operations and to help ensure
+     data consistency.
+   - Required that textual passwords be transferred as UTF-8 encoded
+     Unicode, and added recommendations on string preparation.  This was
+     to help ensure interoperability of passwords being sent from
+     different clients.
+
+C.1.13.  Section 4.2.1 (Sequencing of the Bind Request)
+
+   - This section was largely reorganized for readability, and language
+     was added to clarify the authentication state of failed and
+     abandoned Bind operations.
+   - Removed: "If a SASL transfer encryption or integrity mechanism has
+     been negotiated, that mechanism does not support the changing of
+     credentials from one identity to another, then the client MUST
+     instead establish a new connection."
+     If there are dependencies between multiple negotiations of a
+     particular SASL mechanism, the technical specification for that
+     SASL mechanism details how applications are to deal with them.
+     LDAP should not require any special handling.
+   - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
+
+
+
+Sermersheim                 Standards Track                    [Page 62]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - Mandated that clients not send non-Bind operations while a Bind is
+     in progress, and suggested that servers not process them if they
+     are received.  This is needed to ensure proper sequencing of the
+     Bind in relationship to other operations.
+
+C.1.14.  Section 4.2.3 (Bind Response)
+
+   - Moved most error-related text to Appendix A, and added text
+     regarding certain errors used in conjunction with the Bind
+     operation.
+   - Prohibited the server from specifying serverSaslCreds when not
+     appropriate.
+
+C.1.15.  Section 4.3 (Unbind Operation)
+
+   - Specified that both peers are to cease transmission and terminate
+     the LDAP session for the Unbind operation.
+
+C.1.16.  Section 4.4 (Unsolicited Notification)
+
+   - Added instructions for future specifications of Unsolicited
+     Notifications.
+
+C.1.17.  Section 4.5.1 (Search Request)
+
+   - SearchRequest attributes is now defined as an AttributeSelection
+     type rather than AttributeDescriptionList, and an ABNF is
+     provided.
+   - SearchRequest attributes may contain duplicate attribute
+     descriptions.  This was previously prohibited.  Now servers are
+     instructed to ignore subsequent names when they are duplicated.
+     This was relaxed in order to allow different short names and also
+     OIDs to be requested for an attribute.
+   - The present search filter now evaluates to Undefined when the
+     specified attribute is not known to the server.  It used to
+     evaluate to FALSE, which caused behavior inconsistent with what
+     most would expect, especially when the 'not' operator was used.
+   - The Filter choice SubstringFilter substrings type is now defined
+     with a lower bound of 1.
+   - The SubstringFilter substrings 'initial, 'any', and 'final' types
+     are now AssertionValue rather than LDAPString.  Also, added
+     imperatives stating that 'initial' (if present) must be listed
+     first, and 'final' (if present) must be listed last.
+   - Disambiguated the semantics of the derefAliases choices.  There was
+     question as to whether derefInSearching applied to the base object
+     in a wholeSubtree Search.
+   - Added instructions for equalityMatch, substrings, greaterOrEqual,
+     lessOrEqual, and approxMatch.
+
+
+
+Sermersheim                 Standards Track                    [Page 63]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+
+C.1.18.  Section 4.5.2 (Search Result)
+
+   - Recommended that servers not use attribute short names when it
+     knows they are ambiguous or may cause interoperability problems.
+   - Removed all mention of ExtendedResponse due to lack of
+     implementation.
+
+C.1.19.  Section 4.5.3 (Continuation References in the Search Result)
+
+   - Made changes similar to those made to Section 4.1.11.
+
+C.1.20.  Section 4.5.3.1 (Example)
+
+   - Fixed examples to adhere to changes made to Section 4.5.3.
+
+C.1.21.  Section 4.6 (Modify Operation)
+
+   - Replaced AttributeTypeAndValues with Attribute as they are
+     equivalent.
+   - Specified the types of modification changes that might
+     temporarily violate schema.  Some readers were under the impression
+     that any temporary schema violation was allowed.
+
+C.1.22.  Section 4.7 (Add Operation)
+
+   - Aligned Add operation with X.511 in that the attributes of the RDN
+     are used in conjunction with the listed attributes to create the
+     entry.  Previously, Add required that the distinguished values be
+     present in the listed attributes.
+   - Removed requirement that the objectClass attribute MUST be
+     specified as some DSE types do not require this attribute.
+     Instead, generic wording was added, requiring the added entry to
+     adhere to the data model.
+   - Removed recommendation regarding placement of objects.  This is
+     covered in the data model document.
+
+C.1.23.  Section 4.9 (Modify DN Operation)
+
+   - Required servers to not dereference aliases for Modify DN.  This
+     was added for consistency with other operations and to help ensure
+     data consistency.
+   - Allow Modify DN to fail when moving between naming contexts.
+   - Specified what happens when the attributes of the newrdn are not
+     present on the entry.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 64]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+C.1.24.  Section 4.10 (Compare Operation)
+
+   - Specified that compareFalse means that the Compare took place and
+     the result is false.  There was confusion that led people to
+     believe that an Undefined match resulted in compareFalse.
+   - Required servers to not dereference aliases for Compare.  This was
+     added for consistency with other operations and to help ensure
+     data consistency.
+
+C.1.25.  Section 4.11 (Abandon Operation)
+
+   - Explained that since Abandon returns no response, clients should
+     not use it if they need to know the outcome.
+   - Specified that Abandon and Unbind cannot be abandoned.
+
+C.1.26.  Section 4.12 (Extended Operation)
+
+   - Specified how values of Extended operations defined in terms of
+     ASN.1 are to be encoded.
+   - Added instructions on what Extended operation specifications
+     consist of.
+   - Added a recommendation that servers advertise supported Extended
+     operations.
+
+C.1.27.  Section 5.2 (Transfer Protocols)
+
+   - Moved referral-specific instructions into referral-related
+     sections.
+
+C.1.28.  Section 7 (Security Considerations)
+
+   - Reworded notes regarding SASL not protecting certain aspects of
+     the LDAP Bind messages.
+   - Noted that Servers are encouraged to prevent directory
+     modifications by clients that have authenticated anonymously
+     [RFC4513].
+   - Added a note regarding the possibility of changes to security
+     factors (authentication, authorization, and data confidentiality).
+   - Warned against following referrals that may have been injected in
+     the data stream.
+   - Noted that servers should protect information equally, whether in
+     an error condition or not, and mentioned matchedDN,
+     diagnosticMessage, and resultCodes specifically.
+   - Added a note regarding malformed and long encodings.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 65]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+C.1.29.  Appendix A (Complete ASN.1 Definition)
+
+   - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
+   - Removed AttributeType.  It is not used.
+
+C.2.  Changes Made to RFC 2830
+
+   This section summarizes the substantive changes made to Sections of
+   RFC 2830.  Readers should consult [RFC4513] for summaries of changes
+   to other sections.
+
+C.2.1.  Section 2.3 (Response other than "success")
+
+   - Removed wording indicating that referrals can be returned from
+     StartTLS.
+   - Removed requirement that only a narrow set of result codes can be
+     returned.  Some result codes are required in certain scenarios, but
+     any other may be returned if appropriate.
+   - Removed requirement that the ExtendedResponse.responseName MUST be
+     present.  There are circumstances where this is impossible, and
+     requiring this is at odds with language in Section 4.12.
+
+C.2.1.  Section 4 (Closing a TLS Connection)
+
+   - Reworded most of this section to align with definitions of the
+     LDAP protocol layers.
+   - Removed instructions on abrupt closure as this is covered in other
+     areas of the document (specifically, Section 5.3)
+
+C.3.  Changes Made to RFC 3771
+
+   - Rewrote to fit into this document.  In general, semantics were
+     preserved.  Supporting and background language seen as redundant
+     due to its presence in this document was omitted.
+
+   - Specified that Intermediate responses to a request may be of
+     different types, and one of the response types may be specified to
+     have no response value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 66]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Editor's Address
+
+   Jim Sermersheim
+   Novell, Inc.
+   1800 South Novell Place
+   Provo, Utah 84606, USA
+
+   Phone: +1 801 861-3088
+   EMail: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 67]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 68]
+