r8514: add docs

(This used to be commit 876f0a095b8aa7060c62f91fc5715af1f1432e8b)

1 files changed, 2803 insertions, 0 deletions

diff --git a/source4/ldap_server/devdocs/rfc2251.txt b/source4/ldap_server/devdocs/rfc2251.txt
new file mode 100644
index 0000000000..88844cbf38
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc2251.txt
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wahl
+Request for Comments: 2251                           Critical Angle Inc.
+Category: Standards Track                                       T. Howes
+                                           Netscape Communications Corp.
+                                                                S. Kille
+                                                           Isode Limited
+                                                           December 1997
+
+
+               Lightweight Directory Access Protocol (v3)
+
+1. 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 (1997).  All Rights Reserved.
+
+IESG Note
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 1]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+Table of Contents
+
+   1.  Status of this Memo ....................................  1
+       Copyright Notice .......................................  1
+       IESG Note ..............................................  1
+   2.  Abstract ...............................................  3
+   3.  Models .................................................  4
+   3.1. Protocol Model ........................................  4
+   3.2. Data Model ............................................  5
+   3.2.1. Attributes of Entries ...............................  5
+   3.2.2. Subschema Entries and Subentries ....................  7
+   3.3. Relationship to X.500 .................................  8
+   3.4. Server-specific Data Requirements .....................  8
+   4.  Elements of Protocol ...................................  9
+   4.1. Common Elements .......................................  9
+   4.1.1. Message Envelope ....................................  9
+   4.1.1.1. Message ID ........................................ 11
+   4.1.2. String Types ........................................ 11
+   4.1.3. Distinguished Name and Relative Distinguished Name .. 11
+   4.1.4. Attribute Type ...................................... 12
+   4.1.5. Attribute Description ............................... 13
+   4.1.5.1. Binary Option ..................................... 14
+   4.1.6. Attribute Value ..................................... 14
+   4.1.7. Attribute Value Assertion ........................... 15
+   4.1.8. Attribute ........................................... 15
+   4.1.9. Matching Rule Identifier ............................ 15
+   4.1.10. Result Message ..................................... 16
+   4.1.11. Referral ........................................... 18
+   4.1.12. Controls ........................................... 19
+   4.2. Bind Operation ........................................ 20
+   4.2.1. Sequencing of the Bind Request ...................... 21
+   4.2.2. Authentication and Other Security Services .......... 22
+   4.2.3. Bind Response ....................................... 23
+   4.3. Unbind Operation ...................................... 24
+   4.4. Unsolicited Notification .............................. 24
+   4.4.1. Notice of Disconnection ............................. 24
+   4.5. Search Operation ...................................... 25
+
+
+
+Wahl, et. al.               Standards Track                     [Page 2]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   4.5.1. Search Request ...................................... 25
+   4.5.2. Search Result ....................................... 29
+   4.5.3. Continuation References in the Search Result ........ 31
+   4.5.3.1. Example ........................................... 31
+   4.6. Modify Operation ...................................... 32
+   4.7. Add Operation ......................................... 34
+   4.8. Delete Operation ...................................... 35
+   4.9. Modify DN Operation ................................... 36
+   4.10. Compare Operation .................................... 37
+   4.11. Abandon Operation .................................... 38
+   4.12. Extended Operation ................................... 38
+   5.  Protocol Element Encodings and Transfer ................ 39
+   5.1. Mapping Onto BER-based Transport Services ............. 39
+   5.2. Transfer Protocols .................................... 40
+   5.2.1. Transmission Control Protocol (TCP) ................. 40
+   6.  Implementation Guidelines .............................. 40
+   6.1. Server Implementations ................................ 40
+   6.2. Client Implementations ................................ 40
+   7.  Security Considerations ................................ 41
+   8.  Acknowledgements ....................................... 41
+   9.  Bibliography ........................................... 41
+   10. Authors' Addresses ..................................... 42
+   Appendix A - Complete ASN.1 Definition ..................... 44
+   Full Copyright Statement ................................... 50
+
+2.  Abstract
+
+   The protocol described in this document is designed to provide access
+   to directories supporting the X.500 models, while not incurring the
+   resource requirements of the X.500 Directory Access Protocol (DAP).
+   This protocol is specifically targeted at management applications and
+   browser applications that provide read/write interactive access to
+   directories. When used with a directory supporting the X.500
+   protocols, it is intended to be a complement to the X.500 DAP.
+
+   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 RFC 2119 [10].
+
+   Key aspects of this version of LDAP are:
+
+   - All protocol elements of LDAPv2 (RFC 1777) are supported. The
+     protocol is carried directly over TCP or other transport, bypassing
+     much of the session/presentation overhead of X.500 DAP.
+
+   - Most protocol data elements can be encoded as ordinary strings
+     (e.g., Distinguished Names).
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 3]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   - Referrals to other servers may be returned.
+
+   - SASL mechanisms may be used with LDAP to provide association
+     security services.
+
+   - Attribute values and Distinguished Names have been
+     internationalized through the use of the ISO 10646 character set.
+
+   - The protocol can be extended to support new operations, and
+     controls may be used to extend existing operations.
+
+   - Schema is published in the directory for use by clients.
+
+3.  Models
+
+   Interest in X.500 [1] directory technologies in the Internet has led
+   to efforts to reduce the high cost of entry associated with use of
+   these technologies.  This document continues the efforts to define
+   directory protocol alternatives, updating the LDAP [2] protocol
+   specification.
+
+3.1. 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 the
+   operation(s), the server returns a response containing any results or
+   errors to the requesting client.
+
+   In keeping with the goal of easing the costs associated with use of
+   the directory, it is an objective of this protocol to minimize the
+   complexity of clients so as to facilitate widespread deployment of
+   applications capable of using the directory.
+
+   Note that 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 may be exchanged
+   between a client and server in any order, provided the client
+   eventually receives a response for every request that requires one.
+
+   In LDAP versions 1 and 2, no provision was made for protocol servers
+   returning referrals to clients.  However, for improved performance
+   and distribution this version of the protocol permits servers to
+   return to clients referrals to other servers.  This allows servers to
+   offload the work of contacting other servers to progress operations.
+
+
+
+Wahl, et. al.               Standards Track                     [Page 4]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   Note that the core protocol operations defined in this document can
+   be mapped to a strict subset of the X.500(1997) directory abstract
+   service, so it can be cleanly provided by the DAP.  However there is
+   not a one-to-one mapping between LDAP protocol operations and DAP
+   operations: server implementations acting as a gateway to X.500
+   directories may need to make multiple DAP requests.
+
+3.2. Data Model
+
+   This section provides a brief introduction to the X.500 data model,
+   as used by LDAP.
+
+   The LDAP protocol assumes there are one or more servers which jointly
+   provide access to a Directory Information Tree (DIT).  The tree is
+   made up of entries.  Entries have names: one or more attribute values
+   from the entry form its relative distinguished name (RDN), which MUST
+   be unique among all its siblings.  The concatenation of the relative
+   distinguished names of the sequence of entries from a particular
+   entry to an immediate subordinate of the root of the tree forms that
+   entry's Distinguished Name (DN), which is unique in the tree.  An
+   example of a Distinguished Name is
+
+   CN=Steve Kille, O=Isode Limited, C=GB
+
+   Some servers may hold cache or shadow copies of entries, which can be
+   used to answer search and comparison queries, but will return
+   referrals or contact other servers if modification operations are
+   requested.
+
+   Servers which perform caching or shadowing MUST ensure that they do
+   not violate any access control constraints placed on the data by the
+   originating server.
+
+   The largest collection of entries, starting at an entry that is
+   mastered by a particular server, and including all its subordinates
+   and their subordinates, down to the entries which are mastered by
+   different servers, is termed a naming context.  The root of the DIT
+   is a DSA-specific Entry (DSE) and not part of any naming context:
+   each server has different attribute values in the root DSE.  (DSA is
+   an X.500 term for the directory server).
+
+3.2.1. Attributes of Entries
+
+   Entries consist of a set of attributes.  An attribute is a type with
+   one or more associated values.  The attribute type is identified by a
+   short descriptive name and an OID (object identifier). The attribute
+
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 5]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   type governs whether there can be more than one value of an attribute
+   of that type in an entry, the syntax to which the values must
+   conform, the kinds of matching which can be performed on values of
+   that attribute, and other functions.
+
+   An example of an attribute is "mail". There may be one or more values
+   of this attribute, they must be IA5 (ASCII) strings, and they are
+   case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").
+
+   Schema is the collection of attribute type definitions, object class
+   definitions and other information which a server uses to determine
+   how to match a filter or attribute value assertion (in a compare
+   operation) against the attributes of an entry, and whether to permit
+   add and modify operations.  The definition of schema for use with
+   LDAP is given in [5] and [6].  Additional schema elements may be
+   defined in other documents.
+
+   Each entry MUST have an objectClass attribute.  The objectClass
+   attribute specifies the object classes of an entry, which along with
+   the system and user schema determine the permitted attributes of an
+   entry.  Values of this attribute may be modified by clients, but the
+   objectClass attribute cannot be removed.  Servers may restrict the
+   modifications of this attribute to prevent the basic structural class
+   of the entry from being changed (e.g. one cannot change a person into
+   a country).  When creating an entry or adding an objectClass value to
+   an entry, all superclasses of the named classes are implicitly added
+   as well if not already present, and the client must supply values for
+   any mandatory attributes of new superclasses.
+
+   Some attributes, termed operational attributes, are used by servers
+   for administering the directory system itself.  They are not returned
+   in search results unless explicitly requested by name.  Attributes
+   which are not operational, such as "mail", will have their schema and
+   syntax constraints enforced by servers, but servers will generally
+   not make use of their values.
+
+   Servers MUST NOT permit clients to add attributes to an entry unless
+   those attributes are permitted by the object class definitions, the
+   schema controlling that entry (specified in the subschema - see
+   below), or are operational attributes known to that server and used
+   for administrative purposes.  Note that there is a particular
+   objectClass 'extensibleObject' defined in [5] which permits all user
+   attributes to be present in an entry.
+
+   Entries MAY contain, among others, the following operational
+   attributes, defined in [5]. These attributes are maintained
+   automatically by the server and are not modifiable by clients:
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 6]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   - creatorsName: the Distinguished Name of the user who added this
+     entry to the directory.
+
+   - createTimestamp: the time this entry was added to the directory.
+
+   - modifiersName: the Distinguished Name of the user who last modified
+     this entry.
+
+   - modifyTimestamp: the time this entry was last modified.
+
+   - subschemaSubentry:  the Distinguished Name of the subschema entry
+     (or subentry) which controls the schema for this entry.
+
+3.2.2. Subschema Entries and Subentries
+
+   Subschema entries are used for administering information about the
+   directory schema, in particular the object classes and attribute
+   types supported by directory servers.  A single subschema entry
+   contains all schema definitions used by entries in a particular part
+   of the directory tree.
+
+   Servers which follow X.500(93) models SHOULD implement subschema
+   using the X.500 subschema mechanisms, and so these subschemas are not
+   ordinary entries.  LDAP clients SHOULD NOT assume that servers
+   implement any of the other aspects of X.500 subschema.  A server
+   which masters entries and permits clients to modify these entries
+   MUST implement and provide access to these subschema entries, so that
+   its clients may discover the attributes and object classes which are
+   permitted to be present. It is strongly recommended that all other
+   servers implement this as well.
+
+   The following four attributes MUST be present in all subschema
+   entries:
+
+   - cn: this attribute MUST be used to form the RDN of the subschema
+     entry.
+
+   - objectClass: the attribute MUST have at least the values "top" and
+     "subschema".
+
+   - objectClasses: each value of this attribute specifies an object
+     class known to the server.
+
+   - attributeTypes: each value of this attribute specifies an attribute
+     type known to the server.
+
+   These are defined in [5]. Other attributes MAY be present in
+   subschema entries, to reflect additional supported capabilities.
+
+
+
+Wahl, et. al.               Standards Track                     [Page 7]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   These include matchingRules, matchingRuleUse, dITStructureRules,
+   dITContentRules, nameForms and ldapSyntaxes.
+
+   Servers SHOULD provide the attributes createTimestamp and
+   modifyTimestamp in subschema entries, in order to allow clients to
+   maintain their caches of schema information.
+
+   Clients MUST only retrieve attributes from a subschema entry by
+   requesting a base object search of the entry, where the search filter
+   is "(objectClass=subschema)". (This will allow LDAPv3 servers which
+   gateway to X.500(93) to detect that subentry information is being
+   requested.)
+
+3.3. Relationship to X.500
+
+   This document defines LDAP in terms of X.500 as an X.500 access
+   mechanism.  An LDAP server MUST act in accordance with the
+   X.500(1993) series of ITU recommendations when providing the service.
+   However, it is not required that an LDAP server make use of any X.500
+   protocols in providing this service, e.g. LDAP can be mapped onto any
+   other directory system so long as the X.500 data and service model as
+   used in LDAP is not violated in the LDAP interface.
+
+3.4. Server-specific Data Requirements
+
+   An LDAP server MUST provide information about itself and other
+   information that is specific to each server.  This is represented as
+   a group of attributes located in the root DSE (DSA-Specific Entry),
+   which is named with the zero-length LDAPDN.  These attributes are
+   retrievable if a client performs a base object search of the root
+   with filter "(objectClass=*)", however they are subject to access
+   control restrictions.  The root DSE MUST NOT be included if the
+   client performs a subtree search starting from the root.
+
+   Servers may allow clients to modify these attributes.
+
+   The following attributes of the root DSE are defined in section 5 of
+   [5].  Additional attributes may be defined in other documents.
+
+   - namingContexts: naming contexts held in the server. Naming contexts
+     are defined in section 17 of X.501 [6].
+
+   - subschemaSubentry: subschema entries (or subentries) known by this
+     server.
+
+   - altServer: alternative servers in case this one is later
+     unavailable.
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 8]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   - supportedExtension: list of supported extended operations.
+
+   - supportedControl: list of supported controls.
+
+   - supportedSASLMechanisms: list of supported SASL security features.
+
+   - supportedLDAPVersion: LDAP versions implemented by the server.
+
+   If the server does not master entries and does not know the locations
+   of schema information, the subschemaSubentry attribute is not present
+   in the root DSE.  If the server masters directory entries under one
+   or more schema rules, there may be any number of values of the
+   subschemaSubentry attribute in the root DSE.
+
+4.  Elements of Protocol
+
+   The LDAP protocol is described using Abstract Syntax Notation 1
+   (ASN.1) [3], and is typically transferred using a subset of ASN.1
+   Basic Encoding Rules [11]. In order to support future extensions to
+   this protocol, clients and servers MUST ignore elements of SEQUENCE
+   encodings whose tags they do not recognize.
+
+   Note that unlike X.500, each change to the LDAP protocol other than
+   through the extension mechanisms will have a different version
+   number.  A client will indicate the version it supports as part of
+   the bind request, described in section 4.2.  If a client has not sent
+   a bind, the server MUST assume that version 3 is supported in the
+   client (since version 2 required that the client bind first).
+
+   Clients may determine the protocol version a server supports by
+   reading the supportedLDAPVersion attribute from the root DSE. Servers
+   which implement version 3 or later versions MUST provide this
+   attribute.  Servers which only implement version 2 may not provide
+   this attribute.
+
+4.1. Common Elements
+
+   This section describes the LDAPMessage envelope PDU (Protocol Data
+   Unit) format, as well as data type definitions which are used in the
+   protocol operations.
+
+4.1.1. Message Envelope
+
+   For the purposes of protocol exchanges, all protocol operations are
+   encapsulated in a common envelope, the LDAPMessage, which is defined
+   as follows:
+
+        LDAPMessage ::= SEQUENCE {
+
+
+
+Wahl, et. al.               Standards Track                     [Page 9]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+                messageID       MessageID,
+                protocolOp      CHOICE {
+                        bindRequest     BindRequest,
+                        bindResponse    BindResponse,
+                        unbindRequest   UnbindRequest,
+                        searchRequest   SearchRequest,
+                        searchResEntry  SearchResultEntry,
+                        searchResDone   SearchResultDone,
+                        searchResRef    SearchResultReference,
+                        modifyRequest   ModifyRequest,
+                        modifyResponse  ModifyResponse,
+                        addRequest      AddRequest,
+                        addResponse     AddResponse,
+                        delRequest      DelRequest,
+                        delResponse     DelResponse,
+                        modDNRequest    ModifyDNRequest,
+                        modDNResponse   ModifyDNResponse,
+                        compareRequest  CompareRequest,
+                        compareResponse CompareResponse,
+                        abandonRequest  AbandonRequest,
+                        extendedReq     ExtendedRequest,
+                        extendedResp    ExtendedResponse },
+                 controls       [0] Controls OPTIONAL }
+
+        MessageID ::= INTEGER (0 .. maxInt)
+
+        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+   The function of the LDAPMessage is to provide an envelope containing
+   common fields required in all protocol exchanges. At this time the
+   only common fields are the message ID and the controls.
+
+   If the server receives a PDU from the client in which the LDAPMessage
+   SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
+   the tag of the protocolOp is not recognized as a request, or the
+   encoding structures or lengths of data fields are found to be
+   incorrect, then the server MUST return the notice of disconnection
+   described in section 4.4.1, with resultCode protocolError, and
+   immediately close the connection. In other cases that the server
+   cannot parse the request received by the client, the server MUST
+   return an appropriate response to the request, with the resultCode
+   set to protocolError.
+
+   If the client receives a PDU from the server which cannot be parsed,
+   the client may discard the PDU, or may abruptly close the connection.
+
+   The ASN.1 type Controls is defined in section 4.1.12.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 10]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+4.1.1.1. Message ID
+
+   All LDAPMessage envelopes encapsulating responses contain the
+   messageID value of the corresponding request LDAPMessage.
+
+   The message ID of a request MUST have a value different from the
+   values of any other requests outstanding in the LDAP session of which
+   this message is a part.
+
+   A client MUST NOT send a second request with the same message ID as
+   an earlier request on the same connection if the client has not
+   received the final response from the earlier request.  Otherwise the
+   behavior is undefined.  Typical clients increment a counter for each
+   request.
+
+   A client MUST NOT reuse the message id of an abandonRequest or of the
+   abandoned operation until it has received a response from the server
+   for another request invoked subsequent to the abandonRequest, as the
+   abandonRequest itself does not have a response.
+
+4.1.2. String Types
+
+   The LDAPString is a notational convenience to indicate that, although
+   strings of LDAPString type encode as OCTET STRING types, the ISO
+   10646 [13] character set (a superset of Unicode) is used, encoded
+   following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm
+   characters which are the same as ASCII (0x0000 through 0x007F) are
+   represented as that same ASCII character in a single byte.  The other
+   byte values are used to form a variable-length encoding of an
+   arbitrary character.
+
+        LDAPString ::= OCTET STRING
+
+   The LDAPOID is a notational convenience to indicate that the
+   permitted value of this string is a (UTF-8 encoded) dotted-decimal
+   representation of an OBJECT IDENTIFIER.
+
+        LDAPOID ::= OCTET STRING
+
+   For example,
+
+        1.3.6.1.4.1.1466.1.2.3
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+   An LDAPDN and a RelativeLDAPDN are respectively defined to be the
+   representation of a Distinguished Name and a Relative Distinguished
+   Name after encoding according to the specification in [4], such that
+
+
+
+Wahl, et. al.               Standards Track                    [Page 11]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+        <distinguished-name> ::= <name>
+
+        <relative-distinguished-name> ::= <name-component>
+
+   where <name> and <name-component> are as defined in [4].
+
+        LDAPDN ::= LDAPString
+
+        RelativeLDAPDN ::= LDAPString
+
+   Only Attribute Types can be present in a relative distinguished name
+   component; the options of Attribute Descriptions (next section) MUST
+   NOT be used in specifying distinguished names.
+
+4.1.4. Attribute Type
+
+   An AttributeType takes on as its value the textual string associated
+   with that AttributeType in its specification.
+
+        AttributeType ::= LDAPString
+
+   Each attribute type has a unique OBJECT IDENTIFIER which has been
+   assigned to it.  This identifier may be written as decimal digits
+   with components separated by periods, e.g. "2.5.4.10".
+
+   A specification may also assign one or more textual names for an
+   attribute type.  These names MUST begin with a letter, and only
+   contain ASCII letters, digit characters and hyphens.  They are case
+   insensitive.  (These ASCII characters are identical to ISO 10646
+   characters whose UTF-8 encoding is a single byte between 0x00 and
+   0x7F.)
+
+   If the server has a textual name for an attribute type, it MUST use a
+   textual name for attributes returned in search results.  The dotted-
+   decimal OBJECT IDENTIFIER is only used if there is no textual name
+   for an attribute type.
+
+   Attribute type textual names are non-unique, as two different
+   specifications (neither in standards track RFCs) may choose the same
+   name.
+
+   A server which masters or shadows entries SHOULD list all the
+   attribute types it supports in the subschema entries, using the
+   attributeTypes attribute.  Servers which support an open-ended set of
+   attributes SHOULD include at least the attributeTypes value for the
+   'objectClass' attribute. Clients MAY retrieve the attributeTypes
+   value from subschema entries in order to obtain the OBJECT IDENTIFIER
+   and other information associated with attribute types.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 12]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   Some attribute type names which are used in this version of LDAP are
+   described in [5].  Servers may implement additional attribute types.
+
+4.1.5. Attribute Description
+
+   An AttributeDescription is a superset of the definition of the
+   AttributeType.  It has the same ASN.1 definition, but allows
+   additional options to be specified.  They are also case insensitive.
+
+        AttributeDescription ::= LDAPString
+
+   A value of AttributeDescription is based on the following BNF:
+
+        <AttributeDescription> ::= <AttributeType> [ ";" <options> ]
+
+        <options>  ::= <option> | <option> ";" <options>
+
+        <option>   ::= <opt-char> <opt-char>*
+
+        <opt-char> ::=  ASCII-equivalent letters, numbers and hyphen
+
+   Examples of valid AttributeDescription:
+
+        cn
+        userCertificate;binary
+
+   One option, "binary", is defined in this document.  Additional
+   options may be defined in IETF standards-track and experimental RFCs.
+   Options beginning with "x-" are reserved for private experiments.
+   Any option could be associated with any AttributeType, although not
+   all combinations may be supported by a server.
+
+   An AttributeDescription with one or more options is treated as a
+   subtype of the attribute type without any options.  Options present
+   in an AttributeDescription are never mutually exclusive.
+   Implementations MUST generate the <options> list sorted in ascending
+   order, and servers MUST treat any two AttributeDescription with the
+   same AttributeType and options as equivalent.  A server will treat an
+   AttributeDescription with any options it does not implement as an
+   unrecognized attribute type.
+
+   The data type "AttributeDescriptionList" describes a list of 0 or
+   more attribute types.  (A list of zero elements has special
+   significance in the Search request.)
+
+        AttributeDescriptionList ::= SEQUENCE OF
+                AttributeDescription
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 13]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+4.1.5.1. Binary Option
+
+   If the "binary" option is present in an AttributeDescription, it
+   overrides any string-based encoding representation defined for that
+   attribute in [5]. Instead the attribute is to be transferred as a
+   binary value encoded using the Basic Encoding Rules [11].  The syntax
+   of the binary value is an ASN.1 data type definition which is
+   referenced by the "SYNTAX" part of the attribute type definition.
+
+   The presence or absence of the "binary" option only affects the
+   transfer of attribute values in protocol; servers store any
+   particular attribute in a single format.  If a client requests that a
+   server return an attribute in the binary format, but the server
+   cannot generate that format, the server MUST treat this attribute
+   type as an unrecognized attribute type.  Similarly, clients MUST NOT
+   expect servers to return an attribute in binary format if the client
+   requested that attribute by name without the binary option.
+
+   This option is intended to be used with attributes whose syntax is a
+   complex ASN.1 data type, and the structure of values of that type is
+   needed by clients.  Examples of this kind of syntax are "Certificate"
+   and "CertificateList".
+
+4.1.6. Attribute Value
+
+   A field of type AttributeValue takes on as its value either a string
+   encoding of a AttributeValue data type, or an OCTET STRING containing
+   an encoded binary value, depending on whether the "binary" option is
+   present in the companion AttributeDescription to this AttributeValue.
+
+   The definition of string encodings for different syntaxes and types
+   may be found in other documents, and in particular [5].
+
+        AttributeValue ::= OCTET STRING
+
+   Note that there is no defined limit on the size of this encoding;
+   thus protocol values may include multi-megabyte attributes (e.g.
+   photographs).
+
+   Attributes may be defined which have arbitrary and non-printable
+   syntax.  Implementations MUST NEITHER simply display nor attempt to
+   decode as ASN.1 a value if its syntax is not known.  The
+   implementation may attempt to discover the subschema of the source
+   entry, and retrieve the values of attributeTypes from it.
+
+   Clients MUST NOT send attribute values in a request which are not
+   valid according to the syntax defined for the attributes.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 14]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+4.1.7. Attribute Value Assertion
+
+   The AttributeValueAssertion type definition is similar to the one in
+   the X.500 directory standards.  It contains an attribute description
+   and a matching rule assertion value suitable for that type.
+
+        AttributeValueAssertion ::= SEQUENCE {
+                attributeDesc   AttributeDescription,
+                assertionValue  AssertionValue }
+
+        AssertionValue ::= OCTET STRING
+
+   If the "binary" option is present in attributeDesc, this signals to
+   the server that the assertionValue is a binary encoding of the
+   assertion value.
+
+   For all the string-valued user attributes described in [5], the
+   assertion value syntax is the same as the value syntax.  Clients may
+   use attribute values as assertion values in compare requests and
+   search filters.
+
+   Note however that the assertion syntax may be different from the
+   value syntax for other attributes or for non-equality matching rules.
+   These may have an assertion syntax which contains only part of the
+   value.  See section 20.2.1.8 of X.501 [6] for examples.
+
+4.1.8. Attribute
+
+   An attribute consists of a type and one or more values of that type.
+   (Though attributes MUST have at least one value when stored, due to
+   access control restrictions the set may be empty when transferred in
+   protocol.  This is described in section 4.5.2, concerning the
+   PartialAttributeList type.)
+
+        Attribute ::= SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+   Each attribute value is distinct in the set (no duplicates).  The
+   order of attribute values within the vals set is undefined and
+   implementation-dependent, and MUST NOT be relied upon.
+
+4.1.9. Matching Rule Identifier
+
+   A matching rule is a means of expressing how a server should compare
+   an AssertionValue received in a search filter with an abstract data
+   value.  The matching rule defines the syntax of the assertion value
+   and the process to be performed in the server.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 15]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   An X.501(1993) Matching Rule is identified in the LDAP protocol by
+   the printable representation of its OBJECT IDENTIFIER, either as one
+   of the strings given in [5], or as decimal digits with components
+   separated by periods, e.g. "caseIgnoreIA5Match" or
+   "1.3.6.1.4.1.453.33.33".
+
+        MatchingRuleId ::= LDAPString
+
+   Servers which support matching rules for use in the extensibleMatch
+   search filter MUST list the matching rules they implement in
+   subschema entries, using the matchingRules attributes.  The server
+   SHOULD also list there, using the matchingRuleUse attribute, the
+   attribute types with which each matching rule can be used.  More
+   information is given in section 4.4 of [5].
+
+4.1.10. Result Message
+
+   The LDAPResult is the construct used in this protocol to return
+   success or failure indications from servers to clients. In response
+   to various requests servers will return responses containing fields
+   of type LDAPResult to indicate the final status of a protocol
+   operation request.
+
+        LDAPResult ::= SEQUENCE {
+                resultCode      ENUMERATED {
+                             success                      (0),
+                             operationsError              (1),
+                             protocolError                (2),
+                             timeLimitExceeded            (3),
+                             sizeLimitExceeded            (4),
+                             compareFalse                 (5),
+                             compareTrue                  (6),
+
+                             authMethodNotSupported       (7),
+                             strongAuthRequired           (8),
+                                        -- 9 reserved --
+                             referral                     (10),  -- new
+                             adminLimitExceeded           (11),  -- new
+                             unavailableCriticalExtension (12),  -- new
+                             confidentialityRequired      (13),  -- new
+                             saslBindInProgress           (14),  -- new
+                             noSuchAttribute              (16),
+                             undefinedAttributeType       (17),
+                             inappropriateMatching        (18),
+                             constraintViolation          (19),
+                             attributeOrValueExists       (20),
+                             invalidAttributeSyntax       (21),
+                                        -- 22-31 unused --
+
+
+
+Wahl, et. al.               Standards Track                    [Page 16]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+                             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), -- new
+                                        -- 72-79 unused --
+                             other                        (80) },
+                             -- 81-90 reserved for APIs --
+                matchedDN       LDAPDN,
+                errorMessage    LDAPString,
+                referral        [3] Referral OPTIONAL }
+
+   All the result codes with the exception of success, compareFalse and
+   compareTrue are to be treated as meaning the operation could not be
+   completed in its entirety.
+
+   Most of the result codes are based on problem indications from X.511
+   error data types.  Result codes from 16 to 21 indicate an
+   AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem,
+   codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54
+   indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an
+   UpdateProblem.
+
+   If a client receives a result code which is not listed above, it is
+   to be treated as an unknown error condition.
+
+   The errorMessage field of this construct may, at the server's option,
+   be used to return a string containing a textual, human-readable
+   (terminal control and page formatting characters should be avoided)
+   error diagnostic. As this error diagnostic is not standardized,
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 17]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   implementations MUST NOT rely on the values returned.  If the server
+   chooses not to return a textual diagnostic, the errorMessage field of
+   the LDAPResult type MUST contain a zero length string.
+
+   For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
+   aliasDereferencingProblem, the matchedDN field is set to the name of
+   the lowest entry (object or alias) in the directory that was matched.
+   If no aliases were dereferenced while attempting to locate the entry,
+   this will be a truncated form of the name provided, or if aliases
+   were dereferenced, of the resulting name, as defined in section 12.5
+   of X.511 [8]. The matchedDN field is to be set to a zero length
+   string with all other result codes.
+
+4.1.11. Referral
+
+   The referral error indicates that the contacted server does not hold
+   the target entry of the request.  The referral field is present in an
+   LDAPResult if the LDAPResult.resultCode field value is referral, and
+   absent with all other result codes.  It contains a reference to
+   another server (or set of servers) which 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 URL MUST be present in the Referral.
+
+   The referral is not returned for a singleLevel or wholeSubtree search
+   in which the search scope spans multiple naming contexts, and several
+   different servers would need to be contacted to complete the
+   operation. Instead, continuation references, described in section
+   4.5.3, are returned.
+
+        Referral ::= SEQUENCE OF LDAPURL  -- one or more
+
+        LDAPURL ::= LDAPString -- limited to characters permitted in URLs
+
+   If the client wishes to progress the operation, it MUST follow the
+   referral by contacting any one of servers.  All the URLs MUST be
+   equally capable of being used to progress the operation.  (The
+   mechanisms for how this is achieved by multiple servers are outside
+   the scope of this document.)
+
+   URLs for servers implementing the LDAP protocol are written according
+   to [9].  If an alias was dereferenced, the <dn> part of the URL MUST
+   be present, with the new target object name.  If the <dn> part is
+   present, the client MUST use this name in its next request to
+   progress the operation, and if it is not present the client will use
+   the same name as in the original request.  Some servers (e.g.
+   participating in distributed indexing) may provide a different filter
+   in a referral for a search operation.  If the filter part of the URL
+
+
+
+Wahl, et. al.               Standards Track                    [Page 18]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   is present in an LDAPURL, the client MUST use this filter in its next
+   request to progress this search, and if it is not present the client
+   MUST use the same filter as it used for that search.  Other aspects
+   of the new request may be the same or different as the request which
+   generated the referral.
+
+   Note that UTF-8 characters appearing in a DN or search filter may not
+   be legal for URLs (e.g. spaces) and MUST be escaped using the %
+   method in RFC 1738 [7].
+
+   Other kinds of URLs may be returned, so long as the operation could
+   be performed using that protocol.
+
+4.1.12. Controls
+
+   A control is a way to specify extension information. Controls which
+   are sent as part of a request apply only to that request and are not
+   saved.
+
+        Controls ::= SEQUENCE OF Control
+
+        Control ::= SEQUENCE {
+                controlType             LDAPOID,
+                criticality             BOOLEAN DEFAULT FALSE,
+                controlValue            OCTET STRING OPTIONAL }
+
+   The controlType field MUST be a UTF-8 encoded dotted-decimal
+   representation of an OBJECT IDENTIFIER which uniquely identifies the
+   control.  This prevents conflicts between control names.
+
+   The criticality field is either TRUE or FALSE.
+
+   If the server recognizes the control type and it is appropriate for
+   the operation, the server will make use of the control when
+   performing the operation.
+
+   If the server does not recognize the control type and the criticality
+   field is TRUE, the server MUST NOT perform the operation, and MUST
+   instead return the resultCode unsupportedCriticalExtension.
+
+   If the control is not appropriate for the operation and criticality
+   field is TRUE, the server MUST NOT perform the operation, and MUST
+   instead return the resultCode unsupportedCriticalExtension.
+
+   If the control is unrecognized or inappropriate but the criticality
+   field is FALSE, the server MUST ignore the control.
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 19]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   The controlValue contains any information associated with the
+   control, and its format is defined for the control.  The server 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 which is associated with a control of its type.
+
+   This document does not define any controls.  Controls may be defined
+   in other documents.  The definition of a control consists of:
+
+     - the OBJECT IDENTIFIER assigned to the control,
+
+     - whether the control is always noncritical, always critical, or
+       critical at the client's option,
+
+     - the format of the controlValue contents of the control.
+
+   Servers list the controls which they recognize in the
+   supportedControl attribute in the root DSE.
+
+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 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 }
+
+   Parameters of the Bind Request are:
+
+   - version: A version number indicating the version of the protocol to
+     be used in this protocol session.  This document describes version
+     3 of the LDAP protocol.  Note that there is no version negotiation,
+     and the client just sets this parameter to the version it desires.
+     If the client requests protocol version 2, a server that supports
+     the version 2 protocol as described in [2] will not return any v3-
+
+
+
+Wahl, et. al.               Standards Track                    [Page 20]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+     specific protocol fields.  (Note that not all LDAP servers will
+     support protocol version 2, since they may be unable to generate
+     the attribute syntaxes associated with version 2.)
+
+   - name: 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, when authentication
+     has been performed at a lower layer, or when using SASL credentials
+     with a mechanism that includes the LDAPDN in the credentials.
+
+   - authentication: information used to authenticate the name, if any,
+     provided in the Bind Request.
+
+   Upon receipt of a Bind Request, a protocol server will authenticate
+   the requesting client, if necessary.  The server will then return a
+   Bind Response to the client indicating the status of the
+   authentication.
+
+   Authorization is the use of this authentication information when
+   performing operations.  Authorization MAY be affected by factors
+   outside of the LDAP Bind request, such as lower layer security
+   services.
+
+4.2.1. Sequencing of the Bind Request
+
+   For some SASL authentication mechanisms, it may be necessary for the
+   client to invoke the BindRequest multiple times.  If at any stage the
+   client wishes to abort the bind process it MAY unbind and then drop
+   the underlying connection.  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.
+
+   If the client sends a BindRequest with the sasl mechanism field as an
+   empty string, the server MUST return a BindResponse with
+   authMethodNotSupported as the resultCode.  This will allow clients to
+   abort a negotiation if it wishes to try again with the same SASL
+   mechanism.
+
+   Unlike LDAP v2, the client need not send a Bind Request in the first
+   PDU of the connection.  The client may request any operations and the
+   server MUST treat these as unauthenticated. If the server requires
+   that the client bind before browsing or modifying the directory, the
+   server MAY reject a request other than binding, unbinding or an
+   extended request with the "operationsError" result.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 21]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   If the client did not bind before sending a request and receives an
+   operationsError, it may then send a Bind Request.  If this also fails
+   or the client chooses not to bind on the existing connection, it will
+   close the connection, reopen it and begin again by first sending a
+   PDU with a Bind Request.  This will aid in interoperating with
+   servers implementing other versions of LDAP.
+
+   Clients MAY send multiple bind requests on a connection to change
+   their credentials.  A subsequent bind process has the effect of
+   abandoning all operations outstanding on the connection.  (This
+   simplifies server implementation.)  Authentication from earlier binds
+   are subsequently ignored, and so if the bind fails, the connection
+   will be treated as anonymous. If a SASL transfer encryption or
+   integrity mechanism has been negotiated, and that mechanism does not
+   support the changing of credentials from one identity to another,
+   then the client MUST instead establish a new connection.
+
+4.2.2. Authentication and Other Security Services
+
+   The simple authentication option provides minimal authentication
+   facilities, with the contents of the authentication field consisting
+   only of a cleartext password.  Note that the use of cleartext
+   passwords is not recommended over open networks when there is no
+   authentication or encryption being performed by a lower layer; see
+   the "Security Considerations" section.
+
+   If no authentication is to be performed, then the simple
+   authentication option MUST be chosen, and the password be of zero
+   length.  (This is often done by LDAPv2 clients.)  Typically the DN is
+   also of zero length.
+
+   The sasl choice allows for any mechanism defined for use with SASL
+   [12].  The mechanism field contains the name of the mechanism.  The
+   credentials field contains the arbitrary data used for
+   authentication, inside an OCTET STRING wrapper.  Note that unlike
+   some Internet application protocols where SASL is used, LDAP is not
+   text-based, thus no base64 transformations are performed on the
+   credentials.
+
+   If any SASL-based integrity or confidentiality services are enabled,
+   they take effect following the transmission by the server and
+   reception by the client of the final BindResponse with resultCode
+   success.
+
+   The client can request that the server use authentication information
+   from a lower layer protocol by using the SASL EXTERNAL mechanism.
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 22]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+4.2.3. Bind Response
+
+   The Bind Response is defined as follows.
+
+        BindResponse ::= [APPLICATION 1] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             serverSaslCreds    [7] OCTET STRING OPTIONAL }
+
+    BindResponse consists simply of an indication from the server of he
+   status of the client's request for authentication.
+
+   f the bind was successful, the resultCode will be success, therwise
+   it will be one of:
+
+   - operationsError: server encountered an internal error,
+
+   - protocolError: unrecognized version number or incorrect PDU
+     structure,
+
+   - authMethodNotSupported: unrecognized SASL mechanism name,
+
+   - strongAuthRequired: the server requires authentication be
+     performed with a SASL mechanism,
+
+   - referral: this server cannot accept this bind and the client
+     should try another,
+
+   - saslBindInProgress: the server requires the client to send a
+     new bind request, with the same sasl mechanism, to continue the
+     authentication process,
+
+   - inappropriateAuthentication: the server requires the client
+     which had attempted to bind anonymously or without supplying
+     credentials to provide some form of credentials,
+
+   - invalidCredentials: the wrong password was supplied or the SASL
+     credentials could not be processed,
+
+   - unavailable: the server is shutting down.
+
+   If the server does not support the client's requested protocol
+   version, it MUST set the resultCode to protocolError.
+
+   If the client receives a BindResponse response where the resultCode
+   was protocolError, it MUST close the connection as the server will be
+   unwilling to accept further operations.  (This is for compatibility
+   with earlier versions of LDAP, in which the bind was always the first
+   operation, and there was no negotiation.)
+
+
+
+Wahl, et. al.               Standards Track                    [Page 23]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   The serverSaslCreds are used as part of a SASL-defined bind mechanism
+   to allow the client to authenticate the server to which it is
+   communicating, or to perform "challenge-response" authentication. If
+   the client bound with the password choice, or the SASL mechanism does
+   not require the server to return information to the client, then this
+   field is not to be included in the result.
+
+4.3. Unbind Operation
+
+   The function of the Unbind Operation is to terminate a protocol
+   session.  The Unbind Operation is defined as follows:
+
+        UnbindRequest ::= [APPLICATION 2] NULL
+
+   The Unbind Operation has no response defined. Upon transmission of an
+   UnbindRequest, a protocol client may assume that the protocol session
+   is terminated. Upon receipt of an UnbindRequest, a protocol server
+   may assume that the requesting client has terminated the session and
+   that all outstanding requests may be discarded, and may close the
+   connection.
+
+4.4. Unsolicited Notification
+
+   An unsolicited notification is an LDAPMessage sent from the server to
+   the client which is not in response to any LDAPMessage received by
+   the server. It is used to signal an extraordinary condition in the
+   server or in the connection between the client and the server.  The
+   notification is of an advisory nature, and the server will not expect
+   any response to be returned from the client.
+
+   The unsolicited notification is structured as an LDAPMessage in which
+   the messageID is 0 and protocolOp is of the extendedResp form.  The
+   responseName field of the ExtendedResponse is present. The LDAPOID
+   value MUST be unique for this notification, and not be used in any
+   other situation.
+
+   One unsolicited notification is defined in this document.
+
+4.4.1. Notice of Disconnection
+
+   This notification may be used by the server to advise the client that
+   the server is about to close the connection due to an error
+   condition.  Note that this notification is NOT a response to an
+   unbind requested by the client: the server MUST follow the procedures
+   of section 4.3. This notification is intended to assist clients in
+   distinguishing between an error condition and a transient network
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 24]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   failure.  As with a connection close due to network failure, the
+   client MUST NOT assume that any outstanding requests which modified
+   the directory have succeeded or failed.
+
+   The responseName is 1.3.6.1.4.1.1466.20036, the response field is
+   absent, and the resultCode is used to indicate the reason for the
+   disconnection.
+
+   The following resultCode values are to be used in this notification:
+
+   - protocolError: The server has received data from the client in
+   which
+     the LDAPMessage structure could not be parsed.
+
+   - strongAuthRequired: The server has detected that an established
+     underlying security association protecting communication between
+     the client and server has unexpectedly failed or been compromised.
+
+   - unavailable: This server will stop accepting new connections and
+     operations on all existing connections, and be unavailable for an
+     extended period of time.  The client may make use of an alternative
+     server.
+
+   After sending this notice, the server MUST close the connection.
+   After receiving this notice, the client MUST NOT transmit any further
+   on the connection, and may abruptly close the connection.
+
+4.5. Search Operation
+
+   The Search Operation allows a client to request that a search be
+   performed on its behalf by a server.  This can be used to read
+   attributes from a single entry, from entries immediately below a
+   particular entry, or a whole subtree of entries.
+
+4.5.1. Search Request
+
+   The Search Request is defined as follows:
+
+        SearchRequest ::= [APPLICATION 3] SEQUENCE {
+                baseObject      LDAPDN,
+                scope           ENUMERATED {
+                        baseObject              (0),
+                        singleLevel             (1),
+                        wholeSubtree            (2) },
+                derefAliases    ENUMERATED {
+                        neverDerefAliases       (0),
+                        derefInSearching        (1),
+                        derefFindingBaseObj     (2),
+
+
+
+Wahl, et. al.               Standards Track                    [Page 25]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+                        derefAlways             (3) },
+                sizeLimit       INTEGER (0 .. maxInt),
+                timeLimit       INTEGER (0 .. maxInt),
+                typesOnly       BOOLEAN,
+                filter          Filter,
+                attributes      AttributeDescriptionList }
+
+        Filter ::= CHOICE {
+                and             [0] SET OF Filter,
+                or              [1] SET OF Filter,
+                not             [2] Filter,
+                equalityMatch   [3] AttributeValueAssertion,
+                substrings      [4] SubstringFilter,
+                greaterOrEqual  [5] AttributeValueAssertion,
+                lessOrEqual     [6] AttributeValueAssertion,
+                present         [7] AttributeDescription,
+                approxMatch     [8] AttributeValueAssertion,
+                extensibleMatch [9] MatchingRuleAssertion }
+
+        SubstringFilter ::= SEQUENCE {
+                type            AttributeDescription,
+                -- at least one must be present
+                substrings      SEQUENCE OF CHOICE {
+                        initial [0] LDAPString,
+                        any     [1] LDAPString,
+                        final   [2] LDAPString } }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+                matchingRule    [1] MatchingRuleId OPTIONAL,
+                type            [2] AttributeDescription OPTIONAL,
+                matchValue      [3] AssertionValue,
+                dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+   Parameters of the Search Request are:
+
+   - baseObject: An LDAPDN that is the base object entry relative to
+     which the search is to be performed.
+
+   - scope: An indicator of the scope of the search to be performed. The
+     semantics of the possible values of this field are identical to the
+     semantics of the scope field in the X.511 Search Operation.
+
+   - derefAliases: An indicator as to how alias objects (as defined in
+     X.501) are to be handled in searching.  The semantics of the
+     possible values of this field are:
+
+             neverDerefAliases: do not dereference aliases in searching
+             or in locating the base object of the search;
+
+
+
+Wahl, et. al.               Standards Track                    [Page 26]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+             derefInSearching: dereference aliases in subordinates of
+             the base object in searching, but not in locating the
+             base object of the search;
+
+             derefFindingBaseObj: dereference aliases in locating
+             the base object of the search, but not when searching
+             subordinates of the base object;
+
+             derefAlways: dereference aliases both in searching and in
+             locating the base object of the search.
+
+   - sizelimit: A sizelimit that restricts the maximum number of entries
+     to be returned as a result of the search. A value of 0 in this
+     field indicates that no client-requested sizelimit restrictions are
+     in effect for the search.  Servers may enforce a maximum number of
+     entries to return.
+
+   - timelimit: A timelimit that restricts the maximum time (in seconds)
+     allowed for a search. A value of 0 in this field indicates that no
+     client-requested timelimit restrictions are in effect for the
+     search.
+
+   - typesOnly: An indicator as to whether search results will contain
+     both attribute types and values, or just attribute types.  Setting
+     this field to TRUE causes only attribute types (no values) to be
+     returned.  Setting this field to FALSE causes both attribute types
+     and values to be returned.
+
+   - filter: A filter that defines the conditions that must be fulfilled
+     in order for the search to match a given entry.
+
+     The 'and', 'or' and 'not' choices can be used to form combinations of
+     filters. At least one filter element MUST be present in an 'and' or
+     'or' choice.  The others match against individual attribute values of
+     entries in the scope of the search.  (Implementor's note: the 'not'
+     filter is an example of a tagged choice in an implicitly-tagged
+     module.  In BER this is treated as if the tag was explicit.)
+
+     A server MUST evaluate filters according to the three-valued logic
+     of X.511(93) section 7.8.1.  In summary, a filter is evaluated to
+     either "TRUE", "FALSE" or "Undefined".  If the filter evaluates
+     to TRUE for a particular entry, then the attributes of that entry
+     are returned as part of the search result (subject to any applicable
+     access control restrictions). If the filter evaluates to FALSE or
+     Undefined, then the entry is ignored for the search.
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 27]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+     A filter of the "and" choice is TRUE if all the filters in the SET
+     OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
+     otherwise Undefined.  A filter of the "or" choice is FALSE if all
+     of 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.
+
+     The present match evaluates to TRUE where there is an attribute or
+     subtype of the specified attribute description present in an entry,
+     and FALSE otherwise (including a presence test with an unrecognized
+     attribute description.)
+
+     The extensibleMatch is new in this version of LDAP.  If the
+     matchingRule field is absent, the type field MUST be present, and
+     the equality match is performed for that type.  If the type field is
+     absent and matchingRule is present, the matchValue is compared
+     against all attributes in an entry which support that matchingRule,
+     and the matchingRule determines the syntax for the assertion value
+     (the filter item evaluates to TRUE if it matches with at least
+     one attribute in the entry, FALSE if it does not match any attribute
+     in the entry, and Undefined if the matchingRule is not recognized
+     or the assertionValue cannot be parsed.)  If the type field is
+     present and matchingRule is present, the matchingRule MUST be one
+     permitted for use with that type, otherwise the filter item is
+     undefined.  If the dnAttributes field is set to TRUE, the match is
+     applied against all the attributes in an entry's distinguished name
+     as well, and also evaluates to TRUE if there is at least one
+     attribute in the distinguished name for which the filter item
+     evaluates to TRUE.  (Editors note: The dnAttributes field is present
+     so that there does not need to be multiple versions of generic
+     matching rules such as for word matching, one to apply to entries
+     and another to apply to entries and dn attributes as well).
+
+     A filter item evaluates to Undefined when the server would not
+     be able to determine whether the assertion value matches an
+     entry.  If an attribute description in an equalityMatch, substrings,
+     greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
+     filter is not recognized by the server, a matching rule id in the
+     extensibleMatch is not recognized by the server, the assertion
+     value cannot be parsed, or the type of filtering requested is not
+     implemented, then the filter is Undefined.  Thus for example if a
+     server did not recognize the attribute type shoeSize, a filter of
+     (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12),
+     (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 28]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+     Servers MUST NOT return errors if attribute descriptions or matching
+     rule ids are not recognized, or assertion values cannot be parsed.
+     More details of filter processing are given in section 7.8 of X.511
+     [8].
+
+   - attributes: A list of the attributes to be returned from each entry
+     which matches the search filter. There are two special values which
+     may be used: an empty list with no attributes, and the attribute
+     description string "*".  Both of these signify that all user
+     attributes are to be returned.  (The "*" allows the client to
+     request all user attributes in addition to specific operational
+     attributes).
+
+     Attributes MUST be named at most once in the list, and are returned
+     at most once in an entry.   If there are attribute descriptions in
+     the list which are not recognized, they are ignored by the server.
+
+     If the client does not want any attributes returned, it can specify
+     a list containing only the attribute with OID "1.1".  This OID was
+     chosen arbitrarily and does not correspond to any attribute in use.
+
+     Client implementors should note that even if all user attributes are
+     requested, some attributes of the entry may not be included in
+     search results due to access control or other restrictions.
+     Furthermore, servers will not return operational attributes, such
+     as objectClasses or attributeTypes, unless they are listed by name,
+     since there may be extremely large number of values for certain
+     operational attributes. (A list of operational attributes for use
+     in LDAP is given in [5].)
+
+   Note that an X.500 "list"-like operation can be emulated by the client
+   requesting a one-level LDAP search operation with a filter checking
+   for the existence of the objectClass attribute, and that an X.500
+   "read"-like operation can be emulated by a base object LDAP search
+   operation with the same filter.  A server which 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 must provide the same semantics
+   as the X.500 search operation.
+
+4.5.2. Search Result
+
+   The results of the search attempted by the server upon receipt of a
+   Search Request are returned in Search Responses, which are LDAP
+   messages containing either SearchResultEntry, SearchResultReference,
+   ExtendedResponse or SearchResultDone data types.
+
+        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+                objectName      LDAPDN,
+
+
+
+Wahl, et. al.               Standards Track                    [Page 29]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+                attributes      PartialAttributeList }
+
+        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+        -- implementors should note that the PartialAttributeList may
+        -- have zero elements (if none of the attributes of that entry
+        -- were requested, or could be returned), and that the vals set
+        -- may also have zero elements (if types only was requested, or
+        -- all values were excluded from the result.)
+
+        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+        -- at least one LDAPURL element must be present
+
+        SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+   Upon receipt of a Search Request, a server will perform the necessary
+   search of the DIT.
+
+   If the LDAP session is operating over a connection-oriented transport
+   such as TCP, the server will return to the client a sequence of
+   responses in separate LDAP messages.  There may be zero or more
+   responses containing SearchResultEntry, one for each entry found
+   during the search.  There may also be zero or more responses
+   containing SearchResultReference, one for each area not explored by
+   this server during the search.  The SearchResultEntry and
+   SearchResultReference PDUs may come in any order. Following all the
+   SearchResultReference responses and all SearchResultEntry responses
+   to be returned by the server, the server will return a response
+   containing the SearchResultDone, which contains an indication of
+   success, or detailing any errors that have occurred.
+
+   Each entry returned in a SearchResultEntry will contain all
+   attributes, complete with associated values if necessary, as
+   specified in the attributes field of the Search Request.  Return of
+   attributes is subject to access control and other administrative
+   policy.  Some attributes may be returned in binary format (indicated
+   by the AttributeDescription in the response having the binary option
+   present).
+
+   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 MUST NOT assume that all attributes
+   can be modified, even if permitted by access control.
+
+   LDAPMessage responses of the ExtendedResponse form are reserved for
+   returning information associated with a control requested by the
+   client.  These may be defined in future versions of this document.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 30]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+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 to search all the entries in the scope at
+   and under the baseObject, the server may return one or more
+   SearchResultReference, each containing a reference to another set of
+   servers for continuing the operation.  A server MUST NOT return any
+   SearchResultReference if it has not located the baseObject and
+   thus has not searched any entries; in this case it would return a
+   SearchResultDone containing a referral resultCode.
+
+   In the absence of indexing information provided to a server from
+   servers holding subordinate naming contexts, SearchResultReference
+   responses are not affected by search filters and are always returned
+   when in scope.
+
+   The SearchResultReference is of the same data type as the Referral.
+   URLs for servers implementing the LDAP protocol are written according
+   to [9].  The <dn> part MUST be present in the URL, with the new target
+   object name.  The client MUST use this name in its next request.
+   Some servers (e.g. part of a distributed index exchange system) may
+   provide a different filter in the URLs of the SearchResultReference.
+   If the filter part of the URL is present in an LDAP URL, the client
+   MUST use the new filter in its next request to progress the search,
+   and if the filter part is absent the client will use again the same
+   filter.  Other aspects of the new search request may be the same or
+   different as the search which generated the continuation references.
+
+   Other kinds of URLs may be returned so long as the operation could be
+   performed using that protocol.
+
+   The name of an unexplored subtree in a SearchResultReference need not
+   be subordinate to the base object.
+
+   In order to complete the search, the client MUST issue a new search
+   operation for each SearchResultReference that is returned.  Note that
+   the abandon operation described in section 4.11 applies only to a
+   particular operation sent on a connection between a client and server,
+   and if the client has multiple outstanding search operations to
+   different servers, it MUST abandon each operation individually.
+
+4.5.3.1. Example
+
+   For example, suppose the contacted server (hosta) holds the entry
+   "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW".  It knows that
+   either LDAP-capable servers (hostb) or (hostc) hold
+   "OU=People,O=MNN,C=WW" (one is the master and the other server a
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 31]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   shadow), and that LDAP-capable server (hostd) holds the subtree
+   "OU=Roles,O=MNN,C=WW".  If a subtree search of "O=MNN,C=WW" is
+   requested to the contacted server, it may return the following:
+
+     SearchResultEntry for O=MNN,C=WW
+     SearchResultEntry for CN=Manager,O=MNN,C=WW
+     SearchResultReference {
+       ldap://hostb/OU=People,O=MNN,C=WW
+       ldap://hostc/OU=People,O=MNN,C=WW
+     }
+     SearchResultReference {
+       ldap://hostd/OU=Roles,O=MNN,C=WW
+     }
+     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 for the subtree
+   "OU=People,O=MNN,C=WW", the server might respond as follows:
+
+     SearchResultEntry for OU=People,O=MNN,C=WW
+     SearchResultReference {
+      ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
+     }
+     SearchResultReference {
+      ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
+     }
+     SearchResultDone (success)
+
+   If the contacted server does not hold the base object for the search,
+   then it will return a referral to the client.  For example, if the
+   client requests a subtree search of "O=XYZ,C=US" to hosta, the server
+   may return only a SearchResultDone containing a referral.
+
+     SearchResultDone (referral) {
+       ldap://hostg/
+     }
+
+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,
+                modification    SEQUENCE OF SEQUENCE {
+
+
+
+Wahl, et. al.               Standards Track                    [Page 32]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+                        operation       ENUMERATED {
+                                                add     (0),
+                                                delete  (1),
+                                                replace (2) },
+                        modification    AttributeTypeAndValues } }
+
+        AttributeTypeAndValues ::= SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+   Parameters of the Modify Request are:
+
+   - object: The object to be modified. The value of this field contains
+     the DN of the entry to be modified.  The server will not perform
+     any alias dereferencing in determining the object to be modified.
+
+   - modification: A list of modifications to be performed on the entry.
+     The entire list of entry modifications MUST be performed
+     in the order they are listed, as a single atomic operation.  While
+     individual modifications may violate the directory schema, the
+     resulting entry after the entire list of modifications is performed
+     MUST conform to the requirements of the directory schema. The
+     values that may be taken on by the 'operation' field in each
+     modification construct have the following semantics respectively:
+
+             add: add values listed to the given attribute, creating
+             the attribute if necessary;
+
+             delete: delete values listed from the given attribute,
+             removing the entire attribute if no values are listed, or
+             if all current values of the attribute are listed for
+             deletion;
+
+             replace: replace all existing values of the given 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 is ignored if the
+             attribute does not exist.
+
+   The result of the modify attempted by the server upon receipt of a
+   Modify Request is returned in a Modify Response, defined as follows:
+
+        ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+   Upon receipt of a Modify Request, a server will perform the necessary
+   modifications to the DIT.
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 33]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   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. Note that 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.  If the connection fails, whether the
+   modification occurred or not is indeterminate.
+
+   The Modify Operation cannot be used to remove from an entry any of
+   its distinguished values, those values which form the entry's
+   relative distinguished name.  An attempt to do so will result in the
+   server returning the error notAllowedOnRDN.  The Modify DN Operation
+   described in section 4.9 is used to rename an entry.
+
+   If an equality match filter has not been defined for an attribute type,
+   clients MUST NOT attempt to delete individual values of that attribute
+   from an entry using the "delete" form of a modification, and MUST
+   instead use the "replace" form.
+
+   Note that due to the simplifications made in LDAP, there is not a
+   direct mapping of the modifications in an LDAP ModifyRequest onto the
+   EntryModifications of a DAP ModifyEntry operation, and different
+   implementations 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 SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+   Parameters of the Add Request are:
+
+   - entry: the Distinguished Name of the entry to be added. Note that
+     the server will not dereference any aliases in locating the entry
+     to be added.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 34]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   - attributes: the list of attributes that make up the content of the
+     entry being added.  Clients MUST include distinguished values
+     (those forming the entry's own RDN) in this list, the objectClass
+     attribute, and values of any mandatory attributes of the listed
+     object classes.  Clients MUST NOT supply the createTimestamp or
+     creatorsName attributes, since these will be generated
+     automatically by the server.
+
+   The entry named in the entry field of the AddRequest MUST NOT exist
+   for the AddRequest to succeed.  The parent of the entry to be added
+   MUST exist.  For example, if the client attempted to add
+   "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the
+   "C=US" entry did exist, then the server would return the error
+   noSuchObject with the matchedDN field containing "C=US".  If the
+   parent entry exists but is not in a naming context held by the
+   server, the server SHOULD return a referral to the server holding the
+   parent entry.
+
+   Servers implementations SHOULD NOT restrict where entries can be
+   located in the directory.  Some servers MAY allow the administrator
+   to restrict the classes of entries which can be added to the
+   directory.
+
+   Upon receipt of an Add Request, a server will attempt to perform the
+   add requested.  The result of the add attempt will be returned to the
+   client in the Add Response, defined as follows:
+
+        AddResponse ::= [APPLICATION 9] LDAPResult
+
+   A response of success indicates that the new entry is present in 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 Distinguished Name of the entry to
+   be deleted. Note that the server will not dereference aliases while
+   resolving the name of the target entry to be removed, and that only
+   leaf entries (those with no subordinate entries) can be deleted with
+   this operation.
+
+   The result of the delete attempted by the server upon receipt of a
+   Delete Request is returned in the Delete Response, defined as
+   follows:
+
+
+
+Wahl, et. al.               Standards Track                    [Page 35]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+        DelResponse ::= [APPLICATION 11] LDAPResult
+
+   Upon receipt of a Delete Request, a server will attempt to perform
+   the entry removal requested. The result of the delete attempt will be
+   returned to the client in the Delete Response.
+
+4.9. Modify DN Operation
+
+   The Modify DN Operation allows a client to change the leftmost (least
+   significant) component of the name of an entry in the directory, 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 }
+
+   Parameters of the Modify DN Request are:
+
+   - entry: the Distinguished Name of the entry to be changed.  This
+     entry may or may not have subordinate entries.
+
+   - newrdn: the RDN that will form the leftmost component of the new
+     name of the entry.
+
+   - deleteoldrdn: a boolean parameter 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 Distinguished Name of the entry
+     which becomes the immediate superior of the existing entry.
+
+   The result of the name change attempted by the server upon receipt of
+   a Modify DN Request is returned in the Modify DN Response, defined
+   as follows:
+
+        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+   Upon receipt of a ModifyDNRequest, a server will attempt to
+   perform the name change. The result of the name change attempt will
+   be returned to the client in the Modify DN Response.
+
+   For example, if the entry named in the "entry" parameter was
+   "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith",
+   and the newSuperior parameter was absent, then this operation would
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 36]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   attempt to rename the entry to be "cn=John Cougar Smith,c=US".  If
+   there was already an entry with that name, the operation would fail
+   with error code entryAlreadyExists.
+
+   If the deleteoldrdn parameter is TRUE, the values forming the old
+   RDN are deleted from the entry.  If the deleteoldrdn parameter is
+   FALSE, the values forming the old RDN will be retained as
+   non-distinguished attribute values of the entry.  The server may
+   not perform the operation and return an error code if the setting of
+   the deleteoldrdn parameter would cause a schema inconsistency in the
+   entry.
+
+   Note that X.500 restricts the ModifyDN operation to only affect
+   entries that are contained within a single server.  If the LDAP
+   server is mapped onto DAP, then this restriction will apply, and the
+   resultCode affectsMultipleDSAs 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.
+
+4.10. Compare Operation
+
+   The Compare Operation allows a client to compare an assertion
+   provided with an entry in the directory. The Compare Request is
+   defined as follows:
+
+        CompareRequest ::= [APPLICATION 14] SEQUENCE {
+                entry           LDAPDN,
+                ava             AttributeValueAssertion }
+
+   Parameters of the Compare Request are:
+
+   - entry: the name of the entry to be compared with.
+
+   - ava: the assertion with which an attribute in the entry is to be
+     compared.
+
+   The result of the compare attempted by the server upon receipt of a
+   Compare Request is returned in the Compare Response, defined as
+   follows:
+
+        CompareResponse ::= [APPLICATION 15] LDAPResult
+
+   Upon receipt of a Compare Request, a server will attempt to perform
+   the requested comparison. The result of the comparison will be
+   returned to the client in the Compare Response. Note that errors and
+   the result of comparison are all returned in the same construct.
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 37]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   Note that some directory systems may establish access controls which
+   permit the values of certain attributes (such as userPassword) to be
+   compared but not read.  In a search result, it may be that an
+   attribute of that type would be returned, but with an empty set of
+   values.
+
+4.11. Abandon Operation
+
+   The function of the Abandon Operation is to allow a client to request
+   that the server abandon an outstanding operation.  The Abandon
+   Request is defined as follows:
+
+        AbandonRequest ::= [APPLICATION 16] MessageID
+
+   The MessageID MUST be that of a an operation which was requested
+   earlier in this connection.
+
+   (The abandon request itself has its own message id.  This is distinct
+    from the id of the earlier operation being abandoned.)
+
+   There is no response defined in the Abandon Operation. Upon
+   transmission of an Abandon Operation, a client may expect that the
+   operation identified by the Message ID in the Abandon Request has
+   been 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 MUST NOT send the
+   SearchResponseDone.  Of course, the server MUST ensure that only
+   properly encoded LDAPMessage PDUs are transmitted.
+
+   Clients MUST NOT send abandon requests for the same operation
+   multiple times, and MUST also be prepared to receive results from
+   operations it has abandoned (since these may have been in transit
+   when the abandon was requested).
+
+   Servers MUST discard abandon requests for message IDs they do not
+   recognize, for operations which cannot be abandoned, and for
+   operations which have already been abandoned.
+
+4.12. Extended Operation
+
+   An extension mechanism has been added in this version of LDAP, in
+   order to allow additional operations to be defined for services not
+   available elsewhere in this protocol, for instance digitally signed
+   operations and results.
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 38]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   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
+   request MUST have a unique OBJECT IDENTIFIER assigned to it.
+
+        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+                requestName      [0] LDAPOID,
+                requestValue     [1] OCTET STRING OPTIONAL }
+
+   The requestName is a dotted-decimal representation of the 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 the
+   ExtendedResponse.
+
+        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+                COMPONENTS OF LDAPResult,
+                responseName     [10] LDAPOID OPTIONAL,
+                response         [11] OCTET STRING OPTIONAL }
+
+   If the server does not recognize the request name, it MUST return
+   only the response fields from LDAPResult, containing the
+   protocolError result code.
+
+5.  Protocol Element Encodings and Transfer
+
+   One underlying service is defined here.  Clients and servers SHOULD
+   implement the mapping of LDAP over TCP described in 5.2.1.
+
+5.1. Mapping Onto BER-based Transport Services
+
+   The protocol elements of LDAP are encoded for exchange using the
+   Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
+   high overhead involved in using certain elements of the BER, the
+   following additional restrictions are placed on BER-encodings of LDAP
+   protocol elements:
+
+   (1) Only the definite form of length encoding will be used.
+
+   (2) OCTET STRING values will be encoded in the primitive form only.
+
+   (3) If the value of a BOOLEAN type is true, the encoding MUST have
+       its contents octets set to hex "FF".
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 39]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   (4) If a value of a type is its default value, it MUST be absent.
+       Only some BOOLEAN and INTEGER types have default values in this
+       protocol definition.
+
+   These restrictions do not apply to ASN.1 types encapsulated inside of
+   OCTET STRING values, such as attribute values, unless otherwise
+   noted.
+
+5.2. Transfer Protocols
+
+   This protocol is designed to run over connection-oriented, reliable
+   transports, with all 8 bits in an octet being significant in the data
+   stream.
+
+5.2.1. Transmission Control Protocol (TCP)
+
+   The LDAPMessage PDUs are mapped directly onto the TCP bytestream.  It
+   is recommended that server implementations running over the TCP MAY
+   provide a protocol listener on the assigned port, 389.  Servers may
+   instead provide a listener on a different port number. Clients MUST
+   support contacting servers on any valid TCP port.
+
+6.  Implementation Guidelines
+
+   This document describes an Internet protocol.
+
+6.1. Server Implementations
+
+   The server MUST be capable of recognizing all the mandatory attribute
+   type names and implement the syntaxes specified in [5].  Servers MAY
+   also recognize additional attribute type names.
+
+6.2. Client Implementations
+
+   Clients which request 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 target entry name, scope and filter.
+   Some clients may be using a counter that is incremented each time
+   referral handling occurs for an operation, and these kinds of clients
+   MUST be able to handle a DIT with at least ten layers of naming
+   contexts between the root and a leaf entry.
+
+   In the absence of prior agreements with servers, clients SHOULD NOT
+   assume that servers support any particular schemas beyond those
+   referenced in section 6.1. Different schemas can have different
+   attribute types with the same names.  The client can retrieve the
+   subschema entries referenced by the subschemaSubentry attribute in
+   the server's root DSE or in entries held by the server.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 40]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+7.  Security Considerations
+
+   When used with a connection-oriented transport, this version of the
+   protocol provides facilities for the LDAP v2 authentication
+   mechanism, simple authentication using a cleartext password, as well
+   as any SASL mechanism [12].  SASL allows for integrity and privacy
+   services to be negotiated.
+
+   It is also permitted that the server can return its credentials to
+   the client, if it chooses to do so.
+
+   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.
+
+   When used with SASL, it should be noted that the name field of the
+   BindRequest is not protected against modification.  Thus if the
+   distinguished name of the client (an LDAPDN) is agreed through the
+   negotiation of the credentials, it takes precedence over any value in
+   the unprotected name field.
+
+   Implementations which 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 which 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 cache.
+
+8.  Acknowledgements
+
+   This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes,
+   and Steve Kille.  Design ideas included in this document are based on
+   those discussed in ASID and other IETF Working Groups.  The
+   contributions of individuals in these working groups is gratefully
+   acknowledged.
+
+9.  Bibliography
+
+   [1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
+       and Service",  1993.
+
+   [2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
+       Protocol", RFC 1777, March 1995.
+
+   [3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
+       Specification of Basic Notation", 1994.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 41]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   [4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access
+       Protocol (v3): UTF-8 String Representation of Distinguished
+       Names", RFC 2253, December 1997.
+
+   [5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+       Directory Access Protocol (v3): Attribute Syntax Definitions",
+       RFC 2252, December 1997.
+
+   [6] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+   [7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+       Resource  Locators (URL)", RFC 1738, December 1994.
+
+   [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
+       1993.
+
+   [9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
+       December 1997.
+
+   [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, March 1997.
+
+   [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
+        Canonical, and Distinguished Encoding Rules", 1994.
+
+   [12] Meyers, J., "Simple Authentication and Security Layer",
+        RFC 2222, October 1997.
+
+   [13] Universal Multiple-Octet Coded Character Set (UCS) -
+        Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
+        1993.
+
+   [14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+        10646", RFC 2044, October 1996.
+
+10. Authors' Addresses
+
+   Mark Wahl
+   Critical Angle Inc.
+   4815 W Braker Lane #502-385
+   Austin, TX 78759
+   USA
+
+   Phone:  +1 512 372-3160
+   EMail:  M.Wahl@critical-angle.com
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 42]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Rd., MS MV068
+   Mountain View, CA 94043
+   USA
+
+   Phone:  +1 650 937-3419
+   EMail:   howes@netscape.com
+
+   Steve Kille
+   Isode Limited
+   The Dome, The Square
+   Richmond
+   TW9 1DT
+   UK
+
+   Phone:  +44-181-332-9091
+   EMail:  S.Kille@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 43]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+Appendix A - Complete ASN.1 Definition
+
+        Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
+        IMPLICIT TAGS ::=
+
+        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 },
+                 controls       [0] Controls OPTIONAL }
+
+        MessageID ::= INTEGER (0 .. maxInt)
+
+        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+        LDAPString ::= OCTET STRING
+
+        LDAPOID ::= OCTET STRING
+
+        LDAPDN ::= LDAPString
+
+        RelativeLDAPDN ::= LDAPString
+
+        AttributeType ::= LDAPString
+
+        AttributeDescription ::= LDAPString
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 44]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+        AttributeDescriptionList ::= SEQUENCE OF
+                AttributeDescription
+
+        AttributeValue ::= OCTET STRING
+
+        AttributeValueAssertion ::= SEQUENCE {
+                attributeDesc   AttributeDescription,
+                assertionValue  AssertionValue }
+
+        AssertionValue ::= OCTET STRING
+
+        Attribute ::= SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+        MatchingRuleId ::= LDAPString
+
+        LDAPResult ::= SEQUENCE {
+                resultCode      ENUMERATED {
+                             success                      (0),
+                             operationsError              (1),
+                             protocolError                (2),
+                             timeLimitExceeded            (3),
+                             sizeLimitExceeded            (4),
+                             compareFalse                 (5),
+                             compareTrue                  (6),
+                             authMethodNotSupported       (7),
+                             strongAuthRequired           (8),
+                                        -- 9 reserved --
+                             referral                     (10),  -- new
+                             adminLimitExceeded           (11),  -- new
+                             unavailableCriticalExtension (12),  -- new
+                             confidentialityRequired      (13),  -- new
+                             saslBindInProgress           (14),  -- new
+                             noSuchAttribute              (16),
+                             undefinedAttributeType       (17),
+                             inappropriateMatching        (18),
+                             constraintViolation          (19),
+                             attributeOrValueExists       (20),
+                             invalidAttributeSyntax       (21),
+                                        -- 22-31 unused --
+                             noSuchObject                 (32),
+                             aliasProblem                 (33),
+                             invalidDNSyntax              (34),
+                             -- 35 reserved for undefined isLeaf --
+                             aliasDereferencingProblem    (36),
+                                        -- 37-47 unused --
+                             inappropriateAuthentication  (48),
+
+
+
+Wahl, et. al.               Standards Track                    [Page 45]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+                             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), -- new
+                                        -- 72-79 unused --
+                             other                        (80) },
+                             -- 81-90 reserved for APIs --
+                matchedDN       LDAPDN,
+                errorMessage    LDAPString,
+                referral        [3] Referral OPTIONAL }
+
+        Referral ::= SEQUENCE OF LDAPURL
+
+        LDAPURL ::= LDAPString -- limited to characters permitted in URLs
+
+        Controls ::= SEQUENCE OF Control
+
+        Control ::= SEQUENCE {
+                controlType             LDAPOID,
+                criticality             BOOLEAN DEFAULT FALSE,
+                controlValue            OCTET STRING OPTIONAL }
+
+        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 {
+
+
+
+Wahl, et. al.               Standards Track                    [Page 46]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+             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      AttributeDescriptionList }
+
+        Filter ::= CHOICE {
+                and             [0] SET OF Filter,
+                or              [1] SET OF Filter,
+                not             [2] Filter,
+                equalityMatch   [3] AttributeValueAssertion,
+                substrings      [4] SubstringFilter,
+                greaterOrEqual  [5] AttributeValueAssertion,
+                lessOrEqual     [6] AttributeValueAssertion,
+                present         [7] AttributeDescription,
+                approxMatch     [8] AttributeValueAssertion,
+                extensibleMatch [9] MatchingRuleAssertion }
+
+        SubstringFilter ::= SEQUENCE {
+                type            AttributeDescription,
+                -- at least one must be present
+                substrings      SEQUENCE OF CHOICE {
+                        initial [0] LDAPString,
+                        any     [1] LDAPString,
+                        final   [2] LDAPString } }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+                matchingRule    [1] MatchingRuleId OPTIONAL,
+                type            [2] AttributeDescription OPTIONAL,
+                matchValue      [3] AssertionValue,
+                dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 47]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+                objectName      LDAPDN,
+                attributes      PartialAttributeList }
+
+        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+
+        SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+                object          LDAPDN,
+                modification    SEQUENCE OF SEQUENCE {
+                        operation       ENUMERATED {
+                                                add     (0),
+                                                delete  (1),
+                                                replace (2) },
+                        modification    AttributeTypeAndValues } }
+
+        AttributeTypeAndValues ::= SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+        ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+        AddRequest ::= [APPLICATION 8] SEQUENCE {
+                entry           LDAPDN,
+                attributes      AttributeList }
+
+        AttributeList ::= SEQUENCE OF SEQUENCE {
+                type    AttributeDescription,
+                vals    SET OF AttributeValue }
+
+        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
+
+
+
+Wahl, et. al.               Standards Track                    [Page 48]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+        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,
+                response         [11] OCTET STRING OPTIONAL }
+
+        END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 49]
+
+RFC 2251                         LDAPv3                    December 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 50]
+