WDIFF

draft-ietf-ldapbis-protocol-06.txt --> draft-ietf-ldapbis-protocol-07.txt

Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc
Document: draft-ietf-ldapbis-protocol-06.txt January draft-ietf-ldapbis-protocol-07.txt March 2002
Obsoletes: RFC 2251

Lightweight Directory Access

LDAP: The Protocol (v3)

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
(LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please send
editorial comments directly to the editor <jimse@novell.com>.

Abstract

This document describes the protocol elements, along with their
semantics and encodings, for the Lightweight Directory Access
Protocol (LDAP). LDAP provides access to distributed directory
services that act in accordance with X.500 data and service models.
These protocol elements are based on those described in the X.500
Directory Access Protocol (DAP).

Table of Contents

1. Status of this Memo..............................................1 Introduction.....................................................2
2. Abstract.........................................................2 Conventions......................................................3
3. Models...........................................................3
3.1. Protocol Model.................................................3
3.2. Data Model.....................................................4
3.2.1. Attributes of Entries........................................4
3.2.2. Subschema Entries and Subentries.............................6
3.3. Relationship to X.500..........................................7
3.4. Server-specific Data Requirements..............................7 Model...................................................3
4. Elements of Protocol.............................................8 Protocol.............................................3
4.1. Common Elements................................................8 Elements................................................4
4.1.1. Message Envelope.............................................8 Envelope.............................................4
4.1.1.1. Message ID.................................................9 ID.................................................5
4.1.2. String Types.................................................9
4.1.3. Distinguished Name and Relative Distinguished Name..........10
4.1.4. Attribute Type..............................................10
4.1.5. Attribute Description.......................................11
4.1.5.1. Binary Option.............................................13
4.1.6. Attribute Value.............................................13 Types.................................................6

Sermersheim Internet-Draft - Expires July Sep 2002 Page 1
Lightweight Directory Access Protocol Version 3

4.1.3. Distinguished Name and Relative Distinguished Name...........6
4.1.5. Attribute Description........................................6
4.1.5.1. Binary Transfer Option.....................................7
4.1.6. Attribute Value..............................................8
4.1.7. Attribute Value Assertion...................................14 Assertion....................................8
4.1.8. Attribute...................................................14 Attribute....................................................9
4.1.9. Matching Rule Identifier....................................15 Identifier.....................................9
4.1.10. Result Message.............................................15 Message.............................................10
4.1.11. Referral...................................................17 Referral...................................................11
4.1.12. Controls...................................................18 Controls...................................................12
4.2. Bind Operation................................................19 Operation................................................13
4.2.1. Sequencing of the Bind Request..............................20
4.2.2. Authentication and Other Security Services..................21 Request..............................14
4.2.3. Bind Response...............................................21 Response...............................................15
4.3. Unbind Operation..............................................22 Operation..............................................16
4.4. Unsolicited Notification......................................22 Notification......................................16
4.4.1. Notice of Disconnection.....................................23 Disconnection.....................................17
4.5. Search Operation..............................................23 Operation..............................................17
4.5.1. Search Request..............................................24 Request..............................................17
4.5.2. Search Result...............................................27 Result...............................................21
4.5.3. Continuation References in the Search Result................28 Result................22
4.6. Modify Operation..............................................30 Operation..............................................24
4.7. Add Operation.................................................31 Operation.................................................25
4.8. Delete Operation..............................................32 Operation..............................................26
4.9. Modify DN Operation...........................................33 Operation...........................................27
4.10. Compare Operation............................................34 Operation............................................28
4.11. Abandon Operation............................................35 Operation............................................29
4.12. Extended Operation...........................................35 Operation...........................................29
5. Protocol Element Encodings and Transfer.........................36 Transfer.........................30
5.1. Protocol Encoding.............................................36 Encoding.............................................30
5.2. Transfer Protocols............................................36 Protocols............................................30
5.2.1. Transmission Control Protocol (TCP).........................36 (TCP).........................31
6. Implementation Guidelines.......................................37 Guidelines.......................................31
6.1. Server Implementations........................................37 Implementations........................................31
6.2. Client Implementations........................................37 Implementations........................................31
7. Security Considerations.........................................37 Considerations.........................................31
8. Acknowledgements................................................38 Acknowledgements................................................32
9. Bibliography....................................................38 Normative References............................................32
10. Editor's Address...............................................39 Address...............................................33
Appendix A - Complete ASN.1 Definition.............................40 LDAP Result Codes.....................................34
A.1 Non-Error Result Codes.........................................34
A.2 Error Result Codes.............................................34
A.3 Classes and Precedence of Error Result Codes...................34
Appendix B C - Change History........................................45
B.1
C.1 Changes made to RFC 2251:......................................45
B.2
C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:............45
B.3
C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:............46
B.4
C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:............46
B.5
C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:............48
B.6
C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:............50
B.7
C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:............50
Appendix C D - Outstanding Work Items................................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 Items................................54

1. Introduction

Sermersheim Internet-Draft - Expires July Sep 2002 Page 2
Lightweight Directory Access Protocol Version 3

directories. When used with a directory supporting the X.500
protocols, it

The Directory is intended "a collection of open systems cooperating to provide
directory services" [X.500]. A Directory user, which may be a complement to human
or other entity, accesses the X.500 DAP. Directory through a client (or
Directory User Agent (DUA)). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in [RFC2119].

Key aspects of this version client, on behalf of LDAP are:

- All the directory
user, interacts with one or more servers (or Directory System Agents
(DSA)). Clients interact with servers using a directory access
protocol.

This document details the protocol elements of LDAPv2 [RFC1777] are supported. The
protocol is carried directly over TCP or other transport,
bypassing much of Lightweight Directory
Access Protocol, along with their semantic meanings. Following the session/presentation overhead
description of X.500 DAP.

- Most protocol data elements can be encoded as ordinary strings
(e.g., Distinguished Names).

- 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 elements, it describes the use of way in which the ISO 10646 character set.

- The
protocol can be extended to support new operations, is encoded and
controls may be used to extend existing operations.

- Schema transferred.

This document is published in an integral part of the directory LDAP Technical Specification
[Roadmap].

This document replaces RFC 2251. Appendix C holds a detailed log of
changes to RFC 2251. At publication time, this appendix will be used by clients.

3. Models

Interest in X.500 directory technologies in the Internet has led to
efforts
distilled to reduce the high cost of entry associated with use a summary of these
technologies. This changes to RFC 2251.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document continues the efforts
are to define directory
protocol alternatives, updating the LDAPv2 protocol specification.

3.1. be interpreted as described in [RFC2119].

3. Protocol Model

The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, a
client transmits a protocol request describing the operation to be
performed to a server. The server is then responsible for performing
the necessary operation(s) in the directory. Upon completion of 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.

Sermersheim Internet-Draft - Expires July 2002 Page 3
Lightweight Directory Access Protocol Version 3
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

Note that the core protocol servers
returning referrals to clients. However, for improved performance and
distribution, operations defined in 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.

Note that the core protocol operations defined in this document can
be mapped to a strict subset 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.
service. However there is not a one-to-one mapping between LDAP
protocol operations and DAP
operations: server 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.

4. Elements of Protocol

Sermersheim Internet-Draft - Expires Sep 2002 Page 3
Lightweight Directory Access Protocol Version 3

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 described using Abstract Syntax Notation 1
(ASN.1) [X.680], and is transferred using a particular
entry to an immediate subordinate of the root subset of ASN.1 Basic
Encoding Rules [X.690]. Section 5.1 specifies how the tree forms that
entry's Distinguished Name (DN), which protocol is unique
encoded and transferred.

In order to support future extensions to this protocol, extensibility
is implied where it is allowed (per ASN.1). In addition, ellipses
(...) have been supplied 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 ASN.1 types that are explicitly
extensible as discussed in [LDAPIANA]. Because of entries, which can be
used to answer search the implied
extensibility, clients and comparison queries, but will return
referrals or contact other servers if modification operations are
requested.

Servers that perform caching or shadowing MUST ensure that ignore trailing SEQUENCE
elements whose tags 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 recognize.

Changes to the entries which are mastered by LDAP protocol other than those described in [LDAPIANA]
require a different servers, version number. A client indicates the version it
is termed a naming context. The root using as part of the DIT is bind request, described in section 4.2. If a DSA-specific Entry (DSE) and
client has not part of any naming context: each sent a bind, the server has different MUST assume the client is
using version 3 or later.

Clients may determine the protocol versions a server supports by
reading the supportedLDAPVersion attribute values in from the root DSE. (DSA is an
X.500 term for DSE
[Models]. Servers which implement version 3 or later versions MUST
provide this attribute.

4.1. Common Elements

This section describes the directory server).

3.2.1. Attributes 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 Entries protocol exchanges, all protocol operations are
encapsulated in a common envelope, the LDAPMessage, which is defined
as follows:

Sermersheim Internet-Draft - Expires July Sep 2002 Page 4
Lightweight Directory Access Protocol Version 3

Entries consist of a set

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 attributes. An attribute is a description
(a type and zero or more options) with one or more associated values.
The attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used LDAPMessage is to construct and compare
values of that attribute, and other functions. Options indicate modes
of transfer and other functions.

An example of provide an attribute is "mail". There may be one or more values
of envelope containing
common fields required in all protocol exchanges. At this attribute, they must be IA5 (ASCII) strings, and they time the
only common fields are
case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").

Schema is the collection of attribute type definitions, object class
definitions message ID and other information which a the controls.

If the server uses to determine
how to match a filter or attribute value assertion (in receives a compare
operation) against PDU from the attributes of an entry, and whether to permit
add and modify operations. The definition of schema for use with LDAP
is given in [RFC2252] and [X.501]. Additional schema elements may be
defined client 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 LDAPMessage
SEQUENCE tag cannot be modified by clients, but recognized, the
objectClass attribute messageID cannot be removed. Servers may restrict the
modifications of this attribute to prevent parsed,
the basic structural class tag of the entry from being changed (e.g. one cannot change a person into protocolOp is not recognized as a country). When creating an entry request, 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 (as defined in Section
12.4.1
encoding structures or lengths of [X.501]), are used by servers for administering the
directory system itself. They are not returned in search results
unless explicitly requested by name. Attributes which data fields 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 found to an entry unless
those attributes are permitted by be
incorrect, then the object class definitions, server MUST return the
schema controlling that entry (specified notice of disconnection
described in the subschema � see
below), or are operational attributes known to that server section 4.4.1, with resultCode protocolError, and used
for administrative purposes. Note that there is a particular
objectClass 'extensibleObject' defined in [RFC2252] which permits all
user attributes to be present in an entry.

Entries MAY contain, among others,
immediately close the following operational
attributes, defined in [RFC2252]. These attributes are maintained
automatically by connection. In other cases that the server and are not modifiable
cannot parse the request received by clients:

- creatorsName: the Distinguished Name of client, the user who added this
entry server MUST
return an appropriate response to the directory.

Sermersheim Internet-Draft - Expires July 2002 Page 5
Lightweight Directory Access Protocol Version 3

- createTimestamp: request, with the time this entry was added resultCode
set to protocolError.

If the directory.

- modifiersName: the Distinguished Name of client receives a PDU from the user who last
modified this entry.

- modifyTimestamp: server, which cannot be parsed,
the time this entry was last modified.

- subschemaSubentry: client may discard the Distinguished Name of PDU, or may abruptly close 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, connection.

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

4.1.1.1. Message ID

All LDAPMessage envelopes encapsulating responses contain 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
messageID value 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 corresponding request LDAPMessage.

The message ID of a request MUST have a non-zero value different from
the other aspects values 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 any other requests outstanding in the attributes and object classes LDAP session of
which are
permitted to be present. It is strongly recommended that all other
servers implement this as well. message is a part. The following four attributes MUST be present in all subschema
entries:

- cn: this attribute zero value is reserved for the
unsolicited notification message.

A client MUST be used to form NOT send a second request with the RDN of same message ID as
an earlier request on the subschema
entry.

- objectClass: same connection if the attribute MUST have at least client has not
received the values "top" and
"subschema".

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

- attributeTypes: earlier request. Otherwise the
behavior is undefined. Typical clients increment a counter for each value
request.

A client MUST NOT reuse the message id of this attribute specifies an
attribute type known to abandonRequest or of the server.

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

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

Servers SHOULD provide
abandoned operation until it has received a response from the attributes createTimestamp and
modifyTimestamp in subschema entries, in order to allow clients server
for another request invoked subsequent to
maintain their caches of schema information. the abandonRequest, as the
abandonRequest itself does not have a response.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 6 5
Lightweight Directory Access Protocol Version 3

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

4.1.2. String Types

The LDAPString is being
requested.

3.3. Relationship a notational convenience to X.500

This document defines LDAP in terms indicate that, although
strings of X.500 LDAPString type encode as an X.500 access
mechanism. An LDAP server MUST act in accordance with OCTET STRING types, the X.500(1993)
series
[ISO10646] character set (a superset of ITU recommendations when providing the service. However, it Unicode) is not required used, encoded
following the UTF-8 algorithm [RFC2044]. Note 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 UTF-8
algorithm characters which are 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 same as ASCII (0x0000 through
0x007F) are represented as that same ASCII character in a
group single
byte. The other byte values are used to form a variable-length
encoding of attributes located in the root DSE (DSA-Specific Entry),
which an arbitrary character.

LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- ISO 10646 characters

The LDAPOID is named with the zero-length LDAPDN. These attributes are
retrievable if a client performs notational convenience to indicate that the
permitted value of this string is a base object search (UTF-8 encoded) dotted-decimal
representation of an OBJECT IDENTIFIER. Although an LDAPOID is
encoded as an OCTET STRING, values are limited to the root
with filter "(objectClass=*)", however they definition of
numericoid given in Section 1.3 of [Models].

LDAPOID ::= OCTET STRING -- Constrained to numericoid [Models]

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 subject respectively defined to access
control restrictions. The root DSE MUST NOT be included if the client
performs
representation of a subtree search starting from distinguished-name and a relative-distinguished-
name after encoding according to the root.

Servers may allow clients specification in [LDAPDN].

LDAPDN ::= LDAPString
-- Constrained to modify these attributes. distinguishedName [LDAPDN]

RelativeLDAPDN ::= LDAPString
-- Constrained to name-component [LDAPDN]

4.1.5. Attribute Descriptions

The following attributes of the root DSE definition and encoding rules for attribute descriptions are
defined in section 5 Section 2.5 of
[RFC2252]. Additional attributes may be defined in other documents. [Models]. Briefly, an attribute description
is an attribute type and zero or more options.

AttributeDescription ::= LDAPString
-- Constrained to attributedescription
-- [Models]

Examples of valid AttributeDescription:

Sermersheim Internet-Draft - namingContexts: naming contexts Expires Sep 2002 Page 6
Lightweight Directory Access Protocol Version 3

cn
userCertificate;binary

Not all options can be associated with attributes held in the server. Naming
contexts are defined
directory. A server will treat an AttributeDescription with any
options it does not implement or support as unrecognized. The order
in section 17 of [X.501].

- subschemaSubentry: subschema entry (or subentry) holding the
schema for the root DSE.

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

- supportedExtension: the list of supported extended operations.

- supportedControl: MUST NOT be used to impart any
semantic meaning. Servers MUST treat any two AttributeDescription
with the same AttributeType and options as equivalent.

AttributeDescriptionList describes a list of supported controls.

- supportedSASLMechanisms: 0 or more attribute
descriptions. (A 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, zero elements has special significance in
the subschemaSubentry attribute is Search request.)

AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription

4.1.5.1 Transfer Options

Transfer options are not present held in the root DSE. If directory, they only affect the server masters directory entries under one or
more schema rules,
encoding used to transfer values. The absence of a transfer option
implies the schema native encoding.

Transfer options are mutually exclusive. Specifying a transfer option
when requesting attributes to be returned in a SearchRequest causes
that encoding to be used for each entry is found by reading that attribute and its subtypes. That
is, requesting name;binary requests the
subschemaSubentry attribute for that entry.

Sermersheim Internet-Draft - Expires July 2002 Page 7
Lightweight Directory Access Protocol Version 3

4. Elements of Protocol

The LDAP protocol is described using Abstract Syntax Notation 1
(ASN.1) [X.680], name and is transferred its
subtypes (e.g., cn, sn, cn;lang_en, etc.) be returned using binary
transfer.

When specifying return attributes for a subset SearchRequest, clients SHOULD
avoid requesting the return of ASN.1 Basic
Encoding Rules [X.690]. In order to support future extensions attributes related to this
protocol, clients each other in
the attribute subtyping hierarchy with different transfer encodings.
For example, requesting name;lang_en;binary and servers MUST ignore elements of SEQUENCE
encodings whose tags they do not recognize. Section 5.1 specifies cn should be avoided
as it ambiguous as to how cn;lang_en is to be transferred. In such
cases, the protocol server's behavior is encoded undefined (the server can return the
values in either, neither, or both encodings).

One transfer option, "binary", is defined in this document.
Additional options may be defined in IETF standards-track and transferred.

Note
experimental RFCs. Options beginning with "x-" are reserved for
private experiments.

4.1.5.2. Binary Transfer Option

If the "binary" option is present in an AttributeDescription, it
specifies that unlike X.500, each change to data within the LDAP AttributeValue(s) of the attribute be
transferred in protocol other than
through as BER encoded data according to the extension mechanisms will have a different version
number. A client will indicate ASN.1
data type corresponding to the version it supports as attribute's LDAP syntax. The LDAP
syntax is indicated by the "SYNTAX" part of the
bind request, described
AttributeTypeDescription.

Sermersheim Internet-Draft - Expires Sep 2002 Page 7
Lightweight Directory Access Protocol Version 3

The presence or absence of the "binary" option only affects the
transfer of attribute values in section 4.2. protocol; servers store any
particular attribute in a server-defined format. If a client has not sent requests
that a
bind, the server MUST assume that version 3 or later is supported return an attribute in the client (since version 2 required that "binary" format, but the client bind first).

Clients may determine
server cannot generate that format, the protocol versions a server supports by
reading MUST treat 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 {
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,

Sermersheim Internet-Draft - Expires July 2002 Page 8
Lightweight Directory Access Protocol Version 3

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 unrecognized. Similarly, clients MUST NOT expect
servers to provide return 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 attribute with the server receives a PDU from "binary" option if the client in which the LDAPMessage
SEQUENCE tag cannot be recognized,
requested that attribute by name without the messageID cannot "binary" option.

This option is intended to be parsed,
the tag of the protocolOp used with attributes whose syntax is not recognized as a request, or the
encoding structures or lengths of
complex ASN.1 data fields are found to type, but may be
incorrect, then the server MUST return the notice of disconnection
described in section 4.4.1, associated 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 any attribute
whose ASN.1 type is known.

4.1.6. Attribute Value

A field of type AttributeValue is an appropriate response OCTET STRING containing an
encoded value of an AttributeValue data type. The value is encoded
according to its native encoding definition, unless an option
specifying the request, with transfer encoding is present in the resultCode
set companion
AttributeDescription to protocolError.

If the client receives a PDU from the server, which cannot be parsed,
the client may discard the PDU, or AttributeValue (e.g. "binary").

The native encoding definitions for different syntaxes and attribute
types may abruptly close be found in other documents, and in particular [Syntaxes].

At the connection.

The ASN.1 type Controls time of this writing, there is defined only one AttributeDescription
option used to specify transfer encoding--"binary", described in
section 4.1.12.

4.1.1.1. Message ID

All LDAPMessage envelopes encapsulating responses contain the
messageID value of 4.1.5.2.

AttributeValue ::= OCTET STRING

Note that there is no defined limit on the corresponding request LDAPMessage.

The message ID size of a request MUST 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 NOT display nor attempt to decode as
ASN.1, a value different from if its syntax is not known. The implementation may
attempt to discover the
values subschema of any other requests outstanding in the LDAP session source entry, and retrieve
the values of which
this message is a part.

A client attributeTypes from it.

Clients MUST NOT send attribute values in a second request with the same message ID as
an earlier request on the same connection if the client has that are 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
valid according to the abandonRequest, as syntax defined for the
abandonRequest itself does not have a response.

4.1.2. String Types attributes.

4.1.7. Attribute Value Assertion

The LDAPString AttributeValueAssertion type definition is a notational convenience similar to indicate that, although
strings of LDAPString type encode as OCTET STRING types, 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 {

Sermersheim Internet-Draft - Expires July Sep 2002 Page 9 8
Lightweight Directory Access Protocol Version 3

[ISO10646] character set (a superset of Unicode)

attributeDesc AttributeDescription,
assertionValue AssertionValue }

AssertionValue ::= OCTET STRING

If a transfer option is present in attributeDesc, the assertionValue
is used, encoded
following as specified by the UTF-8 algorithm [RFC2044]. Note that option. For example, if the "binary"
option is present in the UTF-8
algorithm characters which are attributeDesc, the AssertionValue is BER
encoded.

For all the string-valued user attributes described in [Syntaxes],
the assertion value syntax is the same as ASCII (0x0000 through
0x007F) are represented the value syntax. Clients
may use attribute values as that same ASCII character in a single
byte. The other byte assertion values are used to form a variable-length
encoding of an arbitrary character.

LDAPString ::= OCTET STRING

The LDAPOID is a notational convenience to indicate in compare requests and
search filters.

Note however that the
permitted assertion syntax may be different from the
value of this string is a (UTF-8 encoded) dotted-decimal
representation of syntax for other attributes or for non-equality matching rules.
These may have an OBJECT IDENTIFIER.

LDAPOID ::= OCTET STRING

A value assertion syntax which contains only part of LDAPOID is defined by the following ABNF [RFC2234]:

ldapOID = number *( DOT number )

number = ( LDIGIT *DIGIT ) / DIGIT

DOT = %x2E ; "."

LDIGIT = %x31-39 ; 1-9

DIGIT = %x30 / LDIGIT ; 0-9

For example,

1.3.6.1.4.1.1466.1.2.3

4.1.3. Distinguished Name and Relative Distinguished Name
value. See section 20.2.1.8 of [X.501] for examples.

4.1.8. Attribute

An LDAPDN attribute consists of an attribute description and a RelativeLDAPDN are respectively defined one or more
values of that attribute description. (Though attributes MUST have at
least one value when stored, due to access control restrictions the
set may be empty when transferred from the
representation of a Distinguished Name and a Relative Distinguished
Name after encoding according server to the specification in [RFC2253], such
that:

distinguished-name = name

relative-distinguished-name = name-component

where name and name-component are as defined client. This
is described in [RFC2253].

LDAPDN ::= LDAPString

RelativeLDAPDN ::= LDAPString

Only section 4.5.2, concerning the PartialAttributeList
type.)

Attribute Types can be present ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }

Each attribute value is distinct in a relative distinguished name
component--the options the set (no duplicates). The set
of Attribute Descriptions (next section) attribute values is unordered. Implementations MUST NOT be used reply upon
any apparent ordering being repeatable.

4.1.9. Matching Rule Identifier

A matching rule is a means of expressing how a server should compare
an AssertionValue received in specifying distinguished names.

4.1.4. Attribute Type

Sermersheim Internet-Draft - Expires July 2002 Page 10
Lightweight Directory Access Protocol Version 3

An AttributeType takes on as its a search filter with an abstract data
value. The matching rule defines the syntax of the assertion value
and the textual string associated
with that AttributeType process to be performed in the server.

An X.501 (1993) Matching Rule is identified in the LDAP protocol by
the printable representation of its specification.

AttributeType ::= LDAPString

Each attribute type has a unique OBJECT IDENTIFIER which has been
assigned to it. This identifier may be written IDENTIFIER, either as defined by ldapOID
in section 4.1.2.

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
of the server has a textual name for an attribute type, it MUST use a
textual name for attributes returned strings given in search results. The dotted- [Syntaxes], or as decimal OBJECT IDENTIFIER is only used if there is no textual name digits with
components separated by periods, e.g. "caseIgnoreIA5Match" or
"1.3.6.1.4.1.453.33.33".

MatchingRuleId ::= LDAPString

Sermersheim Internet-Draft - Expires Sep 2002 Page 9
Lightweight Directory Access Protocol Version 3

Servers which support matching rules for an attribute type.

Attribute type textual names are non-unique, as two different
specifications (neither use in standards track RFCs) may choose the same
name.

A server which masters or shadows entries SHOULD extensibleMatch
search filter MUST list all the
attribute types it supports matching rules they implement in the
subschema entries, using the
attributeTypes attribute. Servers which support an open-ended set of
attributes matchingRules attributes. The server
SHOULD include at least the attributeTypes value for the
'objectClass' attribute. Clients MAY retrieve also list there, using the attributeTypes
value from subschema entries in order to obtain matchingRuleUse attribute, the OBJECT IDENTIFIER
and other information associated with attribute types.

Some
attribute type names types with which are used each matching rule can be used. More
information is given in this version section 4.5 of LDAP are
described in [RFC2252]. Servers may implement additional attribute
types.

4.1.5. Attribute Description

An AttributeDescription [Syntaxes].

4.1.10. Result Message

The LDAPResult is a superset of the definition construct used in this protocol to return
success or failure indications from servers to clients. To various
requests, servers will return responses of LDAPResult or responses
containing the
AttributeType. It has the same ASN.1 definition, but allows
additional options to be specified. The entire AttributeDescription
is case insensitive.

AttributeDescription ::= LDAPString

A value components of AttributeDescription is based on LDAPResponse to indicate the following ABNF:

attributeDescription = attributeType options

attributeType = AttributeType
; as described in Section 4.1.4

options = *( SEMICOLON options ) 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),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --

Sermersheim Internet-Draft - Expires July Sep 2002 Page 11 10
Lightweight Directory Access Protocol Version 3

option = 1*opt-char

opt-char = ALPHA / DIGIT / HYPHEN

SEMICOLON = %x3B ; ";"

ALPHA = %x41-5A / %x61-7A ; A-Z / a-z

HYPHEN = %x2D ; "-"

Examples of valid AttributeDescription:

cn
userCertificate;binary

Not all options can be associated with attributes held in the
directory. A server will treat an AttributeDescription with any
options it does not implement as unrecognized.

namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }

The order in which
options appear in the list MUST NOT be used to impart any semantic
meaning. Servers MUST treat any two AttributeDescription with the
same AttributeType and options as equivalent.

An attribute description that contains mutually exclusive options
shall be treated as unrecognized. That is, "cn;binary;gser" (where
"binary" and "gser" are mutually exclusive) result codes enumeration is to be treated extensible as an
unrecognized attribute.

There are multiple kinds defined in Section 3.5
of attribute description options. [LDAPIANA]. The LDAP
technical specification details two kinds: tagging options (such as
language tag options) and transfer options (such as ;binary). Other
documents may detail other kinds.

Tagging options can be held in meanings of the directory and result codes are never mutually
exclusive. An attribute with N tagging options is considered a direct
subtype of all attributes given in Appendix
A.

The errorMessage field of this construct may, at the same type server's option,
be used to return a string containing a textual, human-readable
(terminal control and all but one of page formatting characters should be avoided)
error diagnostic. As this error diagnostic is not standardized,
implementations MUST NOT rely on the N
options. values returned. If the type has a supertype, then the attribute is also
considered server
chooses not to return a direct subtype of textual diagnostic, the attribute errorMessage field of
the supertype and the
N tagging options. That is, cn;lang_de;lang_en is considered LDAPResult type MUST contain a direct
subtype zero length string.

For result codes of cn;lang_de, cn;lang_en, noSuchObject, aliasProblem, invalidDNSyntax and name;lang_de;lang_en (cn
aliasDereferencingProblem, the matchedDN field is a
subtype set to the name of name).

Transfer options are not held in
the directory, they only affect lowest entry (object or alias) in the
encoding used directory that was matched.
If no aliases were dereferenced while attempting to transfer values. The absence of locate the entry,
this will be a transfer option
implies truncated form of the native encoding. Transfer options are mutually exclusive.
Specifying name provided, or if aliases
were dereferenced, of the resulting name, as defined in section 12.5
of [X.511]. The matchedDN field contains a transfer option when requesting attributes zero length string with
all other result codes.

4.1.11. Referral

The referral result code 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 one or
more references to one or more servers or services that may be
accessed via LDAP or other protocols. Referrals can be returned in a SearchRequest causes that encoding
response to be used for that
attribute and its subtypes. That is, requesting name;binary requests
the attribute name any operation request (except unbind and its subtypes (e.g., cn, sn, cn;lang_en, etc.) abandon which do
not have responses). At least one URL MUST be present in the
Referral.

The referral is not returned using binary transfer.

When specifying return attributes for a SearchRequest, clients SHOULD
avoid requesting singleLevel or wholeSubtree search
in which the return of attributes related search scope spans multiple naming contexts, and several
different servers would need to each other in be contacted to complete the attribute subtyping hierarchy with different transfer encodings.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 12 11
Lightweight Directory Access Protocol Version 3

For example, requesting name;lang_en;binary and cn should be avoided
as

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 ambiguous as MUST follow the
referral by contacting one of the servers. If multiple URLs are
present, the client assumes that any URL may be used to how cn;lang_en is progress the
operation.

URLs for servers implementing the LDAP protocol are written according
to [LDAPDN]. If an alias was dereferenced, the <dn> part of the URL
MUST be transferred. In such
cases, present, with the server's behavior new target object name. If the <dn> part is undefined (the server can return
present, the
values client MUST use this name in either, neither, or both encodings).

Other documents may specify other kinds of options. These documents
must detail how new kinds of options relate its next request to tagging
progress the operation, and transfer
options. In particular, if it is not present the document must describe how client will use
the options
relation to same name as in the attribute subtyping hierarchy.

One transfer option, "binary", is defined original request. Some servers (e.g.
participating in this document.
Additional options distributed indexing) may be defined provide a different filter
in IETF standards-track and
experimental RFCs. Options beginning with "x-" are reserved a referral for
private experiments.

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

4.1.5.1. Binary Option search operation. If the "binary" option filter part of the URL
is present in an AttributeDescription, LDAPURL, the client MUST use this filter in its next
request to progress this search, and if it
overrides is not present the native encoding representation defined client
MUST use the same filter as it used for that
attribute in [RFC2252]. Instead search. Other aspects of
the attribute is to new request may be transferred the same or different as the request which
generated the referral.

Note that UTF-8 characters appearing in a binary value encoded DN or search filter may not
be legal for URLs (e.g. spaces) and MUST be escaped using the Basic Encoding Rules [X.690]. The
syntax %
method in [RFC2396].

Other kinds of URLs may be returned, so long as the binary value operation could
be performed using that protocol.

4.1.12. Controls

A control is an ASN.1 data type definition, a way to specify extension information. Controls which is
referenced by the "SYNTAX"
are sent as 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 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
server return UTF-8 encoded dotted-decimal
representation of an attribute in the binary format, but OBJECT IDENTIFIER which uniquely identifies 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.
control. 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 prevents conflicts between control names.

The criticality field is
needed by clients. Examples of this kind of syntax are "Certificate" either TRUE or FALSE and "CertificateList".

4.1.6. Attribute Value

A field of type AttributeValue is an OCTET STRING containing an
encoded value only used when a
control accompanies one of an AttributeValue data type. The value is encoded
according to its native encoding definition, unless an option
specifying the transfer encoding is present in the companion
AttributeDescription to the AttributeValue (e.g. "binary"). following requests: bindRequest,

Sermersheim Internet-Draft - Expires July Sep 2002 Page 13 12
Lightweight Directory Access Protocol Version 3

searchRequest, modifyRequest, addRequest, delRequest, modDNRequest,
compareRequest, or extendedReq. The native encoding definitions use of the criticality field for different syntaxes and attribute
types may be found in
a control that is part of any other documents, operation is ignored and in particular [RFC2252].

At treated
as FALSE.

If the time of this writing, there is only one AttributeDescription
option used to specify transfer encoding--"binary", described in
section 4.1.5.1.

AttributeValue ::= OCTET STRING

Note that there server recognizes the control type and it is no defined limit on appropriate for
the size operation, the server will make use 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 NOT 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 control when
performing the source entry, and retrieve operation.

If the values of attributeTypes from it.

Clients MUST NOT send attribute values in a request that are server does not
valid according to the syntax defined for recognize the attributes.

4.1.7. Attribute Value Assertion

The AttributeValueAssertion control type definition or it is similar to the one in
the X.500 directory standards. It contains an attribute description
and a matching rule assertion value suitable not
appropriate for that type.

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

AssertionValue ::= OCTET STRING

If an option specifying the transfer encoding is present in
attributeDesc, operation, and the assertionValue criticality field is encoded as specified by TRUE, the
option. For example, if
server MUST NOT perform the "binary" option is present in operation, and MUST instead return the
attributeDesc,
resultCode unavailableCriticalExtension.

If the AssertionValue control is BER encoded.

For all the string-valued user attributes described in [RFC2252], unrecognized or inappropriate but the
assertion value syntax criticality
field is FALSE, the same as server MUST ignore the value syntax. Clients may
use attribute values as assertion values in compare requests control.

The controlValue contains any information associated with the
control, and
search filters.

Note however that its format is defined for the assertion syntax may control. Implementations
MUST be different from prepared to handle arbitrary contents of the controlValue
octet string, including zero bytes. It is absent only if there is no
value syntax for other attributes or for non-equality matching rules.
These may have an assertion syntax information which contains only part of the
value. See section 20.2.1.8 of [X.501] for examples.

4.1.8. Attribute

An attribute consists of is associated with a type and one or more values control of that its type.
(Though attributes MUST have at least one value when stored, due to
access control restrictions the set

This document does not define any controls. Controls may be empty when transferred

Sermersheim Internet-Draft defined
in other documents. The definition of a control consists of:

- Expires July 2002 Page 14
Lightweight Directory Access Protocol Version 3

from the server OBJECT IDENTIFIER assigned to the client. This control,

- whether the control is described always noncritical, always critical, or
critical at the client's option,

- the format of the controlValue contents of the control.

Servers list the controlType of all recognized controls in section 4.5.2,
concerning the PartialAttributeList type.)

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

Each
supportedControl attribute value is distinct in the set (no duplicates). root DSE.

4.2. Bind Operation

The
order function of attribute values within the vals set Bind Operation is undefined and
implementation-dependent, and MUST NOT to allow authentication
information to 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 exchanged between the assertion value client and the process server. Prior to be performed in
the server.

An X.501 (1993) Matching Rule is identified in BindRequest, the LDAP protocol by implied identity is anonymous. Refer to
[AuthMeth] for the printable representation authentication-related semantics of its OBJECT IDENTIFIER, either this
operation.

The Bind Request is defined as one
of the strings given in [RFC2252], 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.5 of [RFC2252].

4.1.10. Result Message

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

LDAPResult follows:

BindRequest ::= [APPLICATION 0] SEQUENCE {
resultCode ENUMERATED
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }

AuthenticationChoice ::= CHOICE {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10),
simple [0] OCTET STRING,

Sermersheim Internet-Draft - Expires July Sep 2002 Page 15 13
Lightweight Directory Access Protocol Version 3

adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),

-- 70 1 and 2 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral
sasl [3] Referral SaslCredentials,
... }

SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }

All

Parameters of the result codes with Bind Request are:

- version: A version number indicating the exception version of success, compareFalse and
compareTrue are to be treated as meaning the operation could not protocol
to be
completed used in its entirety.

Most this protocol session. This document describes
version 3 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 LDAP protocol. Note that there is no version
negotiation, and 71 indicates an
UpdateProblem.

If a the client receives a result code which is not listed above, it is
to be treated as an unknown error condition.

Sermersheim Internet-Draft - Expires July 2002 Page 16
Lightweight Directory Access Protocol Version 3

The errorMessage field of just sets this construct may, at the server's option,
be used parameter 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,
implementations MUST NOT rely on the values returned.
version it desires. If the server
chooses does not to return a textual diagnostic, the errorMessage field of support the LDAPResult type MUST contain a zero length string.

For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
aliasDereferencingProblem, specified
version, it responds with protocolError in the matchedDN resultCode field is set to of
the BindResponse.

- name: The name of the lowest entry (object or alias) in the directory object 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]. The matchedDN field is to be set client wishes to
bind as. This field may take on a null value (a zero length string
string) for the purposes of anonymous binds, when authentication
has been performed at a lower layer, or when using SASL
credentials with all other result codes.

4.1.11. Referral

The referral result code indicates a mechanism that includes the contacted server does not
hold the target entry of name in the request. The referral field
credentials. Server behavior is present
in an LDAPResult if undefined when the LDAPResult.resultCode field value name is
referral, a null
value, simple authentication is used, and absent with all other result codes. It contains one or
more references to one or more servers or services a password is specified.
Note that may be
accessed via LDAP or other protocols. Referrals can be returned the server SHOULD NOT perform any alias dereferencing in
response
determining the object to any operation request (except unbind and abandon which do
not have responses). At least one URL MUST be present bind as.

- authentication: information used to authenticate the name, if any,
provided in the
Referral.

The referral Bind Request. This type is extensible as defined
in Section 3.6 of [LDAPIANA]. Servers that do not returned for support a singleLevel or wholeSubtree search choice
supplied by a client will return authMethodNotSupported in which the search scope spans multiple naming contexts, and several
different servers would need to be contacted to complete
result code of the
operation. Instead, continuation references, described in section
4.5.3, are returned.

Referral ::= SEQUENCE OF LDAPURL -- one or more

LDAPURL ::= LDAPString -- limited BindResponse.

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 characters permitted in
-- URLs

If the client wishes to progress indicating the operation, it MUST follow status of the
referral
authentication.

Authorization is the use of this authentication information when
performing operations. Authorization MAY be affected by contacting one factors
outside of the servers. If multiple URLs are
present, LDAP Bind request, such as lower layer security
services.

4.2.1. Sequencing of the client assumes that any URL Bind Request

For some SASL authentication mechanisms, it may be used to progress the
operation.

URLs necessary for servers implementing the LDAP protocol are written according
client to [RFC2255]. If an alias was dereferenced, the <dn> part of the URL
MUST be present, with invoke the new target object name. BindRequest multiple times. If the <dn> part is
present, at any stage the
client MUST use this name in its next request wishes to
progress abort the operation, and if bind process it is not present the client will use MAY unbind and then drop
the same name underlying connection. Clients MUST NOT invoke operations between
two Bind requests made 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
is present in an LDAPURL, the client MUST use this filter in its next a multi-stage bind.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 17 14
Lightweight Directory Access Protocol Version 3

request to progress this search, and if it is not present

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
MUST use sends a BindRequest with the same filter sasl mechanism field as it used for that search. Other aspects of an
empty string, the new request may be 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 or different as SASL
mechanism.

If the client did not bind before sending a request which
generated the referral.

Note that UTF-8 characters appearing in and receives an
operationsError, it may then send a DN Bind Request. If this also fails
or search filter may the client chooses not
be legal for URLs (e.g. spaces) and MUST be escaped using to bind on the %
method 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 [RFC2396].

Other kinds interoperating with servers
implementing other versions of URLs may be returned, so long as the operation could
be performed using that protocol.

4.1.12. Controls

A control LDAP.

4.2.3. Bind Response

The Bind Response is a way to specify extension information. Controls which
are sent defined as part of a request apply only to that request and are not
saved.

Controls ::= SEQUENCE OF Control

Control follows.

BindResponse ::= [APPLICATION 1] SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }

The controlType field MUST be a UTF-8 encoded dotted-decimal
representation

BindResponse consists simply of an OBJECT IDENTIFIER which uniquely identifies indication from the
control. This prevents conflicts between control names.

The criticality field is either TRUE or FALSE and is only used when a
control accompanies one server of the following requests: bindRequest,
searchRequest, modifyRequest, addRequest, delRequest, modDNRequest,
compareRequest, or extendedReq. The use
status of the criticality field client's request for
a control that is part of any other operation is ignored and treated
as FALSE. authentication.

If the bind was successful, the resultCode will be success, otherwise
it will be one of:

- operationsError: server recognizes encountered an internal error.

- protocolError: unrecognized version number or incorrect PDU
structure.

- authMethodNotSupported: unrecognized SASL mechanism name.

- strongAuthRequired: the control type server requires authentication be
performed with a SASL mechanism.

- referral: this server cannot accept this bind and it is appropriate for the operation, client
should try another.

- saslBindInProgress: the server will make use of requires the control when
performing client to send a new
bind request, with the operation.

If same sasl mechanism, to continue the
authentication process.

- inappropriateAuthentication: the server does not recognize requires the control type client which
had attempted to bind anonymously or it is not
appropriate for without supplying credentials
to provide some form of credentials.

Sermersheim Internet-Draft - Expires Sep 2002 Page 15
Lightweight Directory Access Protocol Version 3

- invalidCredentials: the operation, and wrong password was supplied or the criticality field SASL
credentials could not be processed.

- unavailable: the server is TRUE, shutting down.

If the server MUST NOT perform does not support the operation, and client's requested protocol
version, it MUST instead return set the resultCode unavailableCriticalExtension. to protocolError.

If the control is unrecognized or inappropriate but the criticality
field is FALSE, client receives a BindResponse response where the server resultCode
was protocolError, it MUST ignore the control.

The controlValue contains any information associated with close the
control, and its format is defined for connection as the control. Implementations
MUST server will be prepared
unwilling to handle arbitrary contents of the controlValue
octet string, including zero bytes. It is absent only if there is no
value information which accept further operations. (This is associated for compatibility
with a control earlier versions of its type.

Sermersheim Internet-Draft - Expires July 2002 Page 18
Lightweight Directory Access Protocol Version 3

This document does not define any controls. Controls may be defined LDAP, in other documents. which the bind was always the first
operation, and there was no negotiation.)

The definition serverSaslCreds are used as part of a control consists of:

- the OBJECT IDENTIFIER assigned SASL-defined bind mechanism
to allow the control,

- whether client to authenticate the control server to which it is always noncritical, always critical,
communicating, or
critical at the client's option,

- to perform "challenge-response" authentication. If
the format of client bound with the controlValue contents of password choice, or the control.

Servers list SASL mechanism does
not require the controls which they recognize in server to return information to the
supportedControl attribute client, then this
field is not to be included in the root DSE.

4.2. Bind result.

4.3. Unbind Operation

The function of the Bind Unbind Operation is to allow authentication
information to be exchanged between the client and server. terminate a protocol
session. The Bind Request Unbind Operation is defined as follows:

BindRequest

UnbindRequest ::= [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 2] NULL

The Unbind Operation has no response defined. Upon transmission of the protocol
to be used in this an
UnbindRequest, a 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 may assume that the client requests protocol version 2, session
is terminated. Upon receipt of an UnbindRequest, a protocol server
may assume that supports the version 2 protocol as described in
[RFC1777] will not return any v3-specific protocol fields. (Note requesting client has terminated the session and
that not all LDAP servers will support protocol version 2, since
they outstanding requests may be unable to generate discarded, and may close the attribute syntaxes associated
with version 2.)

- name: The name of
connection.

4.4. Unsolicited Notification

An unsolicited notification is an LDAPMessage sent from the directory object that server to
the client wishes which is not in response to
bind as. This field may take on a null value (a zero length
string) for any LDAPMessage received by
the purposes of anonymous binds, when authentication
has been performed at a lower layer, or when using SASL
credentials with a mechanism that includes server. It is used to signal an extraordinary condition in the name
server or in the
credentials. Server behavior is undefined when connection between the name client and the server. The
notification is a null
value, simple authentication of an advisory nature, and the server will not expect
any response to be returned from the client.

The unsolicited notification is used, structured as an LDAPMessage in which
the messageID is 0 and a password protocolOp is specified. 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 (Notice of Disconnection) is defined in
this document.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 19 16
Lightweight Directory Access Protocol Version 3

Note

4.4.1. Notice of Disconnection

This notification may be used by the server to advise the client that
the server SHOULD NOT perform any alias dereferencing in
determining is about to close the object connection due to bind as.

- authentication: information used an error
condition. Note that this notification is NOT a response to authenticate an unbind
requested by the name, if any,
provided in client: the Bind Request.

Upon receipt of a Bind Request, a protocol server will authenticate MUST follow the requesting client, if necessary. The server will then return procedures of
section 4.3. This notification is intended to assist clients in
distinguishing between an error condition and a
Bind Response transient network
failure. As with a connection close due to network failure, the
client indicating MUST NOT assume that any outstanding requests which modified
the status of directory have succeeded or failed.

The responseName is 1.3.6.1.4.1.1466.20036, the
authentication.

Authorization response field is
absent, and the use of this authentication information when
performing operations. Authorization MAY be affected by factors
outside of resultCode is used to indicate the LDAP Bind request, such as lower layer security
services.

4.2.1. Sequencing of reason for the Bind Request

For some SASL authentication mechanisms, it may
disconnection.

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

- protocolError: The server has received data from the client to invoke in
which the BindRequest multiple times. If at any stage LDAPMessage structure could not be parsed.

- strongAuthRequired: The server has detected that an established
underlying security association protecting communication between
the client wishes to abort the bind process it MAY unbind and then drop
the underlying connection. Clients MUST NOT invoke server has unexpectedly failed or been compromised.

- unavailable: This server will stop accepting new connections and
operations between
two Bind requests made as part on all existing connections, and be unavailable for an
extended period of a multi-stage bind.

A time. The client may abort a SASL bind negotiation by sending a BindRequest
with a different value in the mechanism field make use of SaslCredentials, or
an AuthenticationChoice other than sasl.

If the client sends a BindRequest with the sasl mechanism field as an
empty string, alternative
server.

After sending this notice, 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 close the same SASL
mechanism.

Unlike LDAP v2, connection.
After receiving this notice, the client need not send a Bind Request in MUST NOT transmit any further
on the first
PDU of connection, and may abruptly close the connection.

4.5. Search Operation

The Search Operation allows a client may to request any operations and the
server MUST treat these as anonymous. 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.

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 search be
performed on the existing connection, it will
close the connection, reopen it and begin again its behalf by first sending a
PDU with a Bind Request. server. This will aid in interoperating with servers
implementing other versions of LDAP.

Clients MAY send multiple bind requests on a connection can be used to change
their credentials. A subsequent bind process has the effect of
abandoning all operations outstanding on the connection. (This
simplifies server implementation.) Authentication read
attributes from earlier binds
are subsequently ignored, and so if the bind fails, the connection
will be treated as anonymous. If a SASL transfer encryption 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),

Sermersheim Internet-Draft - Expires July Sep 2002 Page 20 17
Lightweight Directory Access Protocol Version 3

integrity mechanism has been negotiated,

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 that mechanism does [0] SET SIZE (1..MAX) OF Filter,
or [1] SET SIZE (1..MAX) OF Filter,
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 [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,
-- initial and final can occur at most once
substrings SEQUENCE OF CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }

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

Parameters of the authentication field consisting
only of a cleartext password. Note Search Request are:

- baseObject: An LDAPDN that the use of cleartext
passwords is not recommended over open networks when the underlying
transport service cannot guarantee confidentiality; see base object entry relative to
which the "Security
Considerations" section.

If anonymous authentication search is to be performed, then performed.

- scope: An indicator of the simple
authentication option MUST be chosen, and scope of the password search to be performed.
The semantics of zero
length. (This is often done by LDAPv2 clients.) Typically the name is
also possible values of zero length.

The sasl choice allows for any mechanism defined for use with SASL
[RFC2222]. The mechanism this field contains are identical
to the name semantics of the mechanism.
The credentials scope field contains in 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 X.511 Search Operation.

- derefAliases: An indicator as to how alias objects (as defined in
X.501) are performed on to be handled in searching. The semantics of the
credentials.

If any SASL-based integrity
possible values of this field are:

neverDerefAliases: do not dereference aliases in searching
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.

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 in locating the
status base object of the client's request for authentication.

If the bind was successful, the resultCode will be success, otherwise
it will be one of:

- operationsError: server encountered an internal error.

- protocolError: unrecognized version number or incorrect PDU
structure.

- authMethodNotSupported: unrecognized SASL mechanism name. search;

Sermersheim Internet-Draft - Expires July Sep 2002 Page 21 18
Lightweight Directory Access Protocol Version 3

- strongAuthRequired:

derefInSearching: dereference aliases in subordinates of
the server requires authentication be
performed with a SASL mechanism.

- referral: this server cannot accept this bind and base object in searching, but not in locating the client
should try another.

- saslBindInProgress: base
object of the server requires search;

derefFindingBaseObj: dereference aliases in locating the client to send a new
bind request, with
base object of the same sasl mechanism, to continue search, but not when searching
subordinates of the
authentication process.

- inappropriateAuthentication: base object;

derefAlways: dereference aliases both in searching and in
locating the server requires base object of the client which
had attempted to bind anonymously or without supplying credentials search.

- sizeLimit: A size limit that restricts the maximum number of
entries to provide some form be returned as a result 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 search. A value of 0 in
this field indicates that no client-requested size limit
restrictions are in effect for the client receives search. Servers may enforce a BindResponse response where the resultCode
was protocolError, it MUST close the connection as the server will be
unwilling
maximum number of entries to accept further operations. (This is return.

- timeLimit: A time limit that restricts the maximum time (in
seconds) allowed for compatibility
with earlier versions a search. A value of LDAP, 0 in which the bind was always the first
operation, and there was this field
indicates that no negotiation.)

The serverSaslCreds client-requested time limit restrictions are used as part of a SASL-defined bind mechanism
to allow the client to authenticate in
effect for the server to which it is
communicating, or search.

- typesOnly: An indicator as to perform "challenge-response" authentication. If
the client bound with the password choice, whether search results will contain
both attribute types and values, or the SASL mechanism does
not require the server just attribute types. Setting
this field to return information TRUE causes only attribute types (no values) to the client, then be
returned. Setting this field is not to FALSE causes both attribute types
and values to be included in returned.

- filter: A filter that defines the result.

4.3. Unbind Operation

The function of conditions that must be
fulfilled in order for the Unbind Operation is search to terminate match a protocol
session. The Unbind Operation is defined as follows:

UnbindRequest ::= [APPLICATION 2] NULL given entry.

The Unbind Operation has no response defined. Upon transmission 'and', 'or' and 'not' choices can be used to form combinations
of filters. At least one filter element MUST be present in an
UnbindRequest, a protocol client may assume that the protocol session
is terminated. Upon receipt
'and' or 'or' choice. The others match against individual
attribute values of an UnbindRequest, a protocol server
may assume that entries in the requesting client has terminated scope of the session and
that all outstanding requests may be discarded, and may close search.
(Implementor's note: the
connection.

4.4. Unsolicited Notification

An unsolicited notification 'not' filter is an LDAPMessage sent from 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 client which is not in response to any LDAPMessage received by

Sermersheim Internet-Draft - Expires July 2002 Page 22
Lightweight Directory Access Protocol Version 3

the server. It three-valued logic
of X.511 (1993) section 7.8.1. In summary, a filter is used evaluated
to signal an extraordinary condition in the
server either "TRUE", "FALSE" or in the connection between "Undefined". If the client and filter evaluates
to TRUE for a particular entry, then the server. The
notification is attributes of that entry
are returned as part of an advisory nature, and the server will not expect search result (subject to any response
applicable access control restrictions). If the filter evaluates
to be returned from FALSE or Undefined, then the client.

The unsolicited notification entry is structured as an LDAPMessage in which ignored for the messageID is 0 and protocolOp is search.

A filter of the extendedResp form. The
responseName field of "and" choice is TRUE if all the ExtendedResponse filters in the SET
OF evaluate to TRUE, FALSE if at least one filter is present. The LDAPOID
value MUST be unique for this notification, FALSE, and not be used in any
other situation.

One unsolicited notification (Notice
otherwise Undefined. A filter of Disconnection) the "or" choice is defined in
this document.

4.4.1. Notice FALSE if all
of Disconnection

This notification may be used by the server to advise filters in the client that SET OF evaluate to FALSE, TRUE if at least
one filter is TRUE, and Undefined otherwise. A filter of the server "not"
choice is about to close TRUE if the connection due to an error
condition. Note that this notification filter being negated is NOT a response FALSE, FALSE if it

Sermersheim Internet-Draft - Expires Sep 2002 Page 19
Lightweight Directory Access Protocol Version 3

is TRUE, and Undefined if it is Undefined.

The present match evaluates to TRUE where there is an unbind
requested by the client: the server MUST follow the procedures attribute or
subtype of
section 4.3. This notification is intended to assist clients the specified attribute description present in
distinguishing between an error condition
entry, and FALSE otherwise (including a transient network
failure. As presence test 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. an
unrecognized attribute description.)

The responseName extensibleMatch is 1.3.6.1.4.1.1466.20036, new in this version of LDAP. If the response
matchingRule field is absent, the type field MUST be present, and
the resultCode equality match is used to indicate performed for that type. If the reason 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
disconnection.

The following resultCode values are
assertion value (the filter item evaluates to be used TRUE if it matches
with at least one attribute in this notification:

- protocolError: The server has received data from the client entry, FALSE if it does not
match any attribute in
which the LDAPMessage structure could entry, and Undefined if the
matchingRule is not recognized or the assertionValue cannot be parsed.

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

- unavailable: This server will stop accepting new connections and
operations on all existing connections, type field is present and matchingRule is present,
the matchingRule MUST be unavailable one permitted for an
extended period of time. The client may make use of an alternative
server.

After sending this notice, with that type,
otherwise the server MUST close filter item is undefined. If the connection.
After receiving this notice, dnAttributes field
is set to TRUE, the client MUST NOT transmit any further
on match is applied against all the connection, attributes in
an entry's distinguished name as well, and may abruptly close also evaluates to TRUE
if there is at least one attribute in the connection.

4.5. Search Operation

The Search Operation allows a client distinguished name for
which the filter item evaluates to request TRUE. (Editors note: The
dnAttributes field is present so that a search be
performed on its behalf by a server. This can there does not need to be used
multiple versions of generic matching rules such as for word
matching, one to apply to read
attributes from a single entry, from entries immediately below a
particular entry, 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 whole subtree matching rule id in the
extensibleMatch is not recognized by the server, the assertion
value cannot be parsed, or the type of entries.

Sermersheim Internet-Draft - Expires July 2002 Page 23
Lightweight Directory Access Protocol Version 3

4.5.1. Search Request

The Search Request filtering requested is defined as follows:

SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN, not
implemented, then the filter Filter,
attributes AttributeDescriptionList }

Filter ::= CHOICE { is Undefined. Thus for example if a
server did not recognize the attribute type shoeSize, a filter of
(shoeSize=*) would evaluate to FALSE, and [0] SET SIZE (1..MAX) OF Filter, the filters
(shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to
Undefined.

Servers MUST NOT return errors if attribute descriptions or [1] SET SIZE (1..MAX) OF Filter,
matching rule ids are 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 recognized, or assertion values cannot
be present,
-- initial and final can occur at most once
substrings SEQUENCE OF CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }

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

Parameters parsed. More details of the Search Request are: filter processing are given in section
7.8 of [X.511].

- baseObject: An LDAPDN that is attributes: A list of the base object entry relative attributes to be returned from each
entry which matches the search is 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 performed. returned. (The "*" allows the client
to request all user attributes in addition to any specified
operational attributes).

Sermersheim Internet-Draft - Expires July Sep 2002 Page 24 20
Lightweight Directory Access Protocol Version 3

- scope: An indicator of the scope of the search to

Attributes MUST be performed.
The semantics of the possible values of this field are identical
to the semantics of the scope field named at most once in the X.511 Search Operation.

- derefAliases: An indicator as to how alias objects (as defined list, and are
returned at most once in
X.501) an entry. If there are to be handled attribute
descriptions in searching. The semantics of the
possible values of this field are:

neverDerefAliases: do list which are not dereference aliases in searching
or in locating recognized, they are
ignored by the base object of server.

If the search;

derefInSearching: dereference aliases 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 subordinates use.

Client implementors should note that even if all user attributes
are requested, some attributes of the base object in searching, but entry may not be included in locating the base
object
search results due to access controls or other restrictions.
Furthermore, servers will not return operational attributes, such
as objectClasses or attributeTypes, unless they are listed by
name, since there may be extremely large number of the search;

derefFindingBaseObj: dereference aliases values for
certain operational attributes. (A list of operational attributes
for use in locating LDAP is given in [Syntaxes].)

Note that an X.500 "list"-like operation can be emulated by the
base object of
client requesting a one-level LDAP search operation with a filter
checking for the search, but not when searching
subordinates presence of the base object;

derefAlways: dereference aliases both in searching objectClass attribute, and in
locating the that an
X.500 "read"-like operation can be emulated by a base object of LDAP
search operation with the search.

- sizeLimit: same filter. A size limit that restricts server which provides a
gateway to X.500 is not required to use the maximum number of
entries Read or List operations,
although it may choose to be returned do so, and if it does, it must provide the
same semantics as a result the X.500 search operation.

4.5.2. Search Result

The results of the search. A value search attempted by the server upon receipt of 0 in
this field indicates that no client-requested size limit
restrictions a
Search Request are returned in effect for Search Responses, which are LDAP
messages containing either SearchResultEntry, SearchResultReference,
or SearchResultDone data types.

SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }

PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the search. Servers PartialAttributeList may enforce a
maximum number
-- have zero elements (if none of entries to return.

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

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

- filter: A filter that defines the conditions that must be
fulfilled in order for vals set
-- may also have zero elements (if types only was requested, or
-- all values were excluded from the search to match a given entry.

The 'and', 'or' and 'not' choices can be used to form combinations
of filters. At result.)

SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one filter LDAPURL element MUST 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 (1993) 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

SearchResultDone ::= [APPLICATION 5] LDAPResult

Sermersheim Internet-Draft - Expires July Sep 2002 Page 25 21
Lightweight Directory Access Protocol Version 3

are returned as part

Upon receipt of a Search Request, a server will perform the necessary
search result (subject to any
applicable access control restrictions). of the DIT.

If the filter evaluates LDAP session is operating over a connection-oriented transport
such as TCP, the server will return to FALSE or Undefined, then the entry is ignored 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.

A filter of the "and" choice is TRUE if all There may also be zero or more responses
containing SearchResultReference, one for each area not explored by
this server during the filters search. The SearchResultEntry and
SearchResultReference PDUs may come in any order. Following all the SET
OF evaluate to TRUE, FALSE if at least one filter is FALSE,
SearchResultReference responses and
otherwise Undefined. A filter of the "or" choice is FALSE if all
of the filters in the SET OF evaluate SearchResultEntry responses
to FALSE, TRUE if at least
one filter is TRUE, and Undefined otherwise. A filter of be returned by the "not"
choice is TRUE if server, 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 server will return a response
containing the SearchResultDone, which contains an attribute or
subtype indication of the specified attribute description present
success, or detailing any errors that have occurred.

Each entry returned in an
entry, and FALSE otherwise (including a presence test SearchResultEntry will contain all
attributes, complete with an
unrecognized attribute description.)

The extensibleMatch is new associated values if necessary, as
specified in this version of LDAP. If the
matchingRule attributes field is absent, of the type field MUST be present, 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 equality match is performed for that type. If AttributeDescription in the type field
is absent and matchingRule is present, response having the matchValue is compared
against all "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 which support entry. Clients MUST NOT assume that
matchingRule, and all attributes
can be modified, even if permitted by access control.

4.5.3. Continuation References in the matchingRule determines Search Result

If the syntax for server was able to locate the
assertion value (the filter item evaluates entry referred to TRUE if it matches
with at least one attribute in by the entry, FALSE if it does not
match any attribute
baseObject but was unable to search all the entries in the entry, scope at
and Undefined if under the
matchingRule is not recognized or baseObject, the assertionValue cannot be
parsed.) If server may return one or more
SearchResultReference entries, each containing a reference to another
set of servers for continuing the type field is present operation. A server MUST NOT return
any SearchResultReference if it has not located the baseObject and matchingRule
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 present, of the matchingRule same data type as the Referral.
URLs for servers implementing the LDAP protocol are written according
to [LDAPDN]. The <dn> part MUST be one permitted for use present in the URL, with that type,
otherwise 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 item is undefined. in the URLs of the
SearchResultReference. If the dnAttributes field
is set to TRUE, filter part of the match URL is applied against all the attributes present in an entry's distinguished name as well, and also evaluates to TRUE
if there is at least one attribute in

Sermersheim Internet-Draft - Expires Sep 2002 Page 22
Lightweight Directory Access Protocol Version 3

LDAP URL, the distinguished name for
which client MUST use the new filter item evaluates in its next request to TRUE. (Editors note: The
dnAttributes field
progress the search, and if the filter part 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 absent the server would not be
able to determine whether client will
use again the assertion value matches an entry. same filter. 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 originating search scope was
singleLevel, the
extensibleMatch is not recognized by scope part of the server, URL will be baseObject. Other
aspects of the assertion
value cannot new search request may be parsed, the same or different as the type
search which generated the continuation references.
Other kinds of filtering requested is not
implemented, then URLs may be returned so long as the filter is Undefined. Thus for example if operation could be
performed using that protocol.

The name of an unexplored subtree in a
server did SearchResultReference need not recognize the attribute type shoeSize, a filter of
(shoeSize=*) would evaluate
be subordinate to FALSE, and the filters
(shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate base object.

In order to
Undefined.

Servers complete the search, the client MUST NOT return errors if attribute descriptions or
matching rule ids are not recognized, or assertion values cannot

Sermersheim Internet-Draft - Expires July 2002 Page 26
Lightweight Directory Access Protocol Version 3

be parsed. More details of filter processing are given issue a new search
operation for each SearchResultReference that is returned. Note that
the abandon operation described in section
7.8 of [X.511].

- attributes: A list of the attributes 4.11 applies only to be returned from each
entry which matches a
particular operation sent on a connection between a client and
server, and if the client has multiple outstanding search filter. There are two special
values which may be used: an empty list with no attributes, operations,
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 attribute description string "*". Both of these signify entry "CN=Manager,O=MNN,C=WW". It knows 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
either LDAP-capable servers (hostb) or (hostc) hold
"OU=People,O=MNN,C=WW" (one is the list, master 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 other server a
shadow), and that LDAP-capable server (hostd) holds the server. subtree
"OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is
requested to the client does not want any attributes returned, contacted server, it can
specify a list containing only may return the attribute with OID "1.1". This
OID was chosen arbitrarily and does not correspond to any
attribute in use. 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 even if all user attributes
are requested, some attributes of the entry when following a
SearchResultReference, additional SearchResultReference may not be included in
generated. Continuing the example, if the client contacted the server
(hostb) and issued the search results due to access controls or other restrictions.
Furthermore, servers will not return operational attributes, such
as objectClasses or attributeTypes, unless they are listed by
name, 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 [RFC2252].)

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

Sermersheim Internet-Draft - Expires Sep 2002 Page 23
Lightweight Directory Access Protocol Version 3

SearchResultDone (success)

If the presence of contacted server does not hold the objectClass attribute, and that an
X.500 "read"-like operation can be emulated by a base object LDAP
search operation with for the same filter. A server which provides search,
then it will return a
gateway to X.500 is not required referral to use the Read or List operations,
although it may choose to do so, and client. For example, if it does, it must provide the
same semantics as the X.500
client requests a subtree search operation.

4.5.2. Search Result

The results of the search attempted by "O=XYZ,C=US" to hosta, the server upon receipt of
may return only a
Search Request are returned in Search Responses, which are LDAP
messages SearchResultDone containing either SearchResultEntry, SearchResultReference,
or a referral.

SearchResultDone data types.

SearchResultEntry (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 4] 6] SEQUENCE {
objectName
object LDAPDN,
attributes PartialAttributeList }

PartialAttributeList ::=
modification SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }

AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that

Parameters of the PartialAttributeList may

Sermersheim Internet-Draft Modify Request are:

- Expires July 2002 Page 27
Lightweight Directory Access Protocol Version 3

-- have zero elements (if none object: The object to be modified. The value of this field
contains the attributes DN 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 entry to be present

SearchResultDone ::= [APPLICATION 5] LDAPResult

Upon receipt of a Search Request, a modified. The server will not
perform any alias dereferencing in determining the necessary
search object to be
modified.

- modification: A list of modifications to be performed on the DIT.

If
entry. The entire list of entry modifications MUST be performed in
the LDAP session is operating over a connection-oriented transport
such order they are listed, as TCP, a single atomic operation. While
individual modifications may violate the server will return directory schema, the
resulting entry after the entire list of modifications is
performed MUST conform to the client a sequence requirements of
responses in separate LDAP messages. There may be zero or more
responses containing SearchResultEntry, one for each entry found
during the search. There directory
schema. The values that may also be zero or more responses
containing SearchResultReference, one for each area not explored taken on by
this server during the search. The SearchResultEntry and
SearchResultReference PDUs may come 'operation' field
in any order. Following all each modification construct have the
SearchResultReference responses and all SearchResultEntry responses following semantics
respectively:

add: add values listed to be returned by the server, given attribute, creating the server will return a response
containing
attribute if necessary;

delete: delete values listed from the SearchResultDone, which contains an indication of
success, given attribute,
removing the entire attribute if no values are listed, or detailing any errors that have occurred.

Each entry returned in a SearchResultEntry will contain

Sermersheim Internet-Draft - Expires Sep 2002 Page 24
Lightweight Directory Access Protocol Version 3

if all
attributes, complete with associated current values if necessary, as
specified in the attributes field of the Search Request. Return attribute are listed for
deletion;

replace: replace all existing values of
attributes is subject to access control and other administrative
policy. Some attributes may be returned in binary format (indicated
by the AttributeDescription in given attribute
with the response having new values listed, creating the "binary"
option present).

Some attributes may be constructed by attribute if it
did not already exist. A replace with no value will delete
the server entire attribute if it exists, and appear in a
SearchResultEntry is ignored if the
attribute list, although they are does not stored
attributes exist.

The result of an entry. Clients MUST NOT assume that all attributes
can be modified, even if permitted by access control.

4.5.3. Continuation References in the Search Result

If the server was able to locate the entry referred to modify attempted 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 entries, each containing a reference to another
set upon receipt 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
Modify Request is returned in a referral resultCode.

In the absence Modify Response, defined as follows:

ModifyResponse ::= [APPLICATION 7] LDAPResult

Upon receipt of indexing information provided to a Modify Request, a server from
servers holding subordinate naming contexts, SearchResultReference
responses are not affected by search filters and are always returned
when in scope.

Sermersheim Internet-Draft - Expires July 2002 Page 28
Lightweight Directory Access Protocol Version 3

The SearchResultReference is of the same data type as the Referral.
URLs for servers implementing will perform the LDAP protocol are written according necessary
modifications to [RFC2255]. The <dn> part MUST be present in the URL, with the new
target object name. DIT.

The server will return to 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 single Modify Response
indicating either the URLs successful completion of the
SearchResultReference. If the filter part of DIT modification,
or the URL is present in an
LDAP URL, reason that the client MUST use modification failed. Note that due to the new filter
requirement for atomicity in its next request to
progress applying the search, and if list of modifications in
the filter part is absent Modify Request, the client will
use again the same filter. Other aspects of the new search request may be expect that no modifications of
the same or different as the search which generated DIT have been performed if the
continuation references.
Other kinds Modify Response received indicates
any sort of URLs may be returned so long as the operation could be
performed using error, and that protocol.

The name all requested modifications have been
performed if the Modify Response indicates successful completion of an unexplored subtree in a SearchResultReference need
the Modify Operation. If the connection fails, whether the
modification occurred or not is indeterminate.

The Modify Operation cannot be subordinate used to remove from an entry any of
its distinguished values, those values which form the base object.

In order entry's
relative distinguished name. An attempt to complete the search, do so will result in the client MUST issue a new search
operation for each SearchResultReference that is returned. Note that
server returning the abandon operation error notAllowedOnRDN. The Modify DN Operation
described in section 4.11 applies only 4.9 is used to a
particular operation sent on a connection between a client and
server, and if the client rename an entry.

If an equality match filter has multiple outstanding search operations,
it not been defined for an attribute
type, clients MUST abandon each operation individually.

4.5.3.1. Example

For example, suppose the contacted server (hosta) holds the NOT attempt to add or delete individual values of
that attribute from an entry
"O=MNN,C=WW" and using the entry "CN=Manager,O=MNN,C=WW". It knows that
either LDAP-capable servers (hostb) "add" or (hostc) hold
"OU=People,O=MNN,C=WW" (one is the master and the other server "delete" form of a
shadow),
modification, and MUST instead use the "replace" form.

Note that LDAP-capable server (hostd) holds due to the subtree
"OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" simplifications made in LDAP, there is
requested to the contacted server, it may return the following:

Client implementors should note that when following not a
SearchResultReference, additional SearchResultReference may be
generated. Continuing the example, if
direct mapping of the client contacted modifications in an LDAP ModifyRequest onto the server
(hostb)
EntryModifications of a DAP ModifyEntry operation, and issued the search for the subtree "OU=People,O=MNN,C=WW", different
implementations of LDAP-DAP gateways may use different means of
representing the server might respond as follows:

SearchResultEntry for OU=People,O=MNN,C=WW

Sermersheim Internet-Draft - Expires July 2002 Page 29
Lightweight Directory Access Protocol Version 3

SearchResultReference {
ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
}
SearchResultDone (success) change. If successful, 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 final effect of "O=XYZ,C=US" to hosta, the server
may return only a SearchResultDone containing a referral.

SearchResultDone (referral) {
ldap://hostg/
}

4.6. Modify
operations on the entry MUST be identical.

4.7. Add Operation

The Modify Add Operation allows a client to request that a modification the addition of an entry be performed on its behalf by a server.
into the directory. The Modify Add Request is defined as follows:

ModifyRequest

AddRequest ::= [APPLICATION 6] 8] SEQUENCE {
object
entry LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues }

Sermersheim Internet-Draft - Expires Sep 2002 Page 25
Lightweight Directory Access Protocol Version 3

attributes AttributeList }

AttributeTypeAndValues

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

Parameters of the Modify Add Request are:

- object: The object entry: the Distinguished Name of the entry to be modified. The value of this field
contains the DN of added. Note that
the entry to be modified. The server will not
perform dereference any alias dereferencing aliases in determining locating the object entry
to be
modified. added.

- modification: A attributes: the list of modifications to be performed on attributes that make up the
entry. The entire list content of the
entry modifications being added. Clients MUST be performed include distinguished values
(those forming the entry's own RDN) in this list, the order they are listed, objectClass
attribute, and values of any mandatory attributes of the listed
object classes. Clients MUST NOT supply NO-USER-MODIFICATION
attributes such as a single atomic operation. While
individual modifications may violate the directory schema, createTimestamp or creatorsName attributes,
since the
resulting server maintains these automatically.

The entry after named in the entire list entry field of modifications is
performed the AddRequest MUST conform to NOT exist
for the requirements AddRequest to succeed. The parent of the directory
schema. The values that may entry to be taken on by the 'operation' field
in each modification construct have added
MUST exist. For example, if the following semantics
respectively:

Sermersheim Internet-Draft - Expires July 2002 Page 30
Lightweight Directory Access Protocol Version 3

add: add values listed client attempted to add
"CN=JS,O=Foo,C=US", the given attribute, creating the
attribute if necessary;

delete: delete values listed from the given attribute,
removing "O=Foo,C=US" entry did not exist, and the entire attribute if no values are listed, or
if all current values of
"C=US" entry did exist, then the attribute are listed for
deletion;

replace: replace all existing values of server would return the given attribute error
noSuchObject with the new values listed, creating matchedDN field containing "C=US". If the attribute if it
did not already exist. A replace with no value
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 delete attempt to perform the entire attribute if it exists, and
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 ignored if present in the
attribute does
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 exist. dereference aliases while
resolving the name of the target entry to be removed, and that only

Sermersheim Internet-Draft - Expires Sep 2002 Page 26
Lightweight Directory Access Protocol Version 3

leaf entries (those with no subordinate entries) can be deleted with
this operation.

The result of the modify delete attempted by the server upon receipt of a
Modify
Delete Request is returned in a Modify the Delete Response, defined as
follows:

ModifyResponse

DelResponse ::= [APPLICATION 7] 11] LDAPResult

Upon receipt of a Modify Delete Request, a server will perform the necessary
modifications attempt to perform
the DIT. entry removal requested. The server result of the delete attempt will return be
returned to the client a single Modify Response
indicating either in the successful completion of Delete Response.

4.9. Modify DN Operation

The Modify DN Operation allows a client to change the DIT modification,
or leftmost (least
significant) component of the reason that name of an entry in the modification failed. Note that due directory, or
to the
requirement for atomicity move a subtree of entries to a new location in applying the list 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 modifications in the Modify Request, DN Request are:

- entry: the client may expect that no modifications Distinguished Name of the DIT entry to be changed. This
entry may or may not have been performed if subordinate entries. Note that the Modify Response received indicates
server will not dereference any sort of error, and aliases in locating the entry to
be changed.

- newrdn: the RDN that all requested modifications have been
performed if will form the Modify Response indicates successful completion leftmost component of the Modify Operation. If new
name of the connection fails, entry.

- deleteoldrdn: a boolean parameter that controls whether the
modification occurred or not is indeterminate.

The Modify Operation cannot be used old
RDN attribute values are to remove be retained as attributes of the
entry, or deleted from an entry any the entry.

- newSuperior: if present, this is the Distinguished Name of
its distinguished values, those values the
entry which form becomes the entry's
relative distinguished name. An attempt to do so will immediate superior of the existing entry.

The result in of the
server returning name change attempted by the error notAllowedOnRDN. The server upon receipt of
a Modify DN Operation
described in section 4.9 Request is used to rename an entry.

If an equality match filter has not been returned in the Modify DN Response, defined for an attribute
type, clients MUST NOT as
follows:

ModifyDNResponse ::= [APPLICATION 13] LDAPResult

Upon receipt of a ModifyDNRequest, a server will attempt to add or delete individual values of
that attribute from an entry using perform
the "add" or "delete" form name change. The result of a
modification, and MUST instead use the "replace" form.

Note that due name change attempt will be
returned to the simplifications made in LDAP, there is not a
direct mapping of the modifications client 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 Modify DN Response.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 31 27
Lightweight Directory Access Protocol Version 3

The Add Operation allows a client to request

For example, if the addition of an entry
into named in 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 "entry" parameter was "cn=John
Smith,c=US", the Add Request are:

- entry: newrdn parameter was "cn=John Cougar Smith", and the Distinguished Name of
newSuperior parameter was absent, then this operation would attempt
to rename the entry to be added. Note "cn=John Cougar Smith,c=US". If there was
already an entry with that name, the server will not dereference any aliases in locating operation would fail with error
code entryAlreadyExists.

If the entry
to be added.

- attributes: deleteoldrdn parameter is TRUE, the list of attributes that make up values forming the content of old RDN
are deleted from the entry. If the deleteoldrdn parameter is FALSE,
the
entry being added. Clients MUST include distinguished values
(those forming the entry's own RDN) in this list, the objectClass
attribute, and old RDN will be retained as non-distinguished
attribute values of any mandatory attributes the entry. The server may not perform the
operation and return an error code if the setting of the listed
object classes. Clients MUST NOT supply NO-USER-MODIFICATION
attributes such as deleteoldrdn
parameter would cause a schema inconsistency in the createTimestamp or creatorsName attributes,
since entry.

Note that X.500 restricts the ModifyDN operation to only affect
entries that are contained within a single server. If the LDAP server maintains these automatically.
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 named in the directory. The Compare Request is
defined as follows:

CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry field LDAPDN,
ava AttributeValueAssertion }

Parameters of the AddRequest MUST NOT exist
for Compare Request are:

- entry: the AddRequest to succeed. The parent name of the entry to be added
MUST exist. For example, if compared with. Note that the client attempted to add
"CN=JS,O=Foo,C=US",
server SHOULD NOT dereference any aliases in locating the "O=Foo,C=US" entry did not exist, and to
be compared with.

- ava: the
"C=US" entry did exist, then the server would return the error
noSuchObject assertion 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.

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

Sermersheim Internet-Draft - Expires July 2002 Page 32
Lightweight Directory Access Protocol Version 3

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

The result of the delete compare attempted by the server upon receipt of a
Delete
Compare Request is returned in the Delete Compare Response, defined as
follows:

DelResponse

CompareResponse ::= [APPLICATION 11] 15] LDAPResult

Upon receipt of a Delete Compare Request, a server will attempt to perform
the entry removal requested. requested comparison. The result of the delete attempt comparison will be
returned to the client in the Delete Compare Response.

4.9. Modify DN Operation

The Modify DN Operation allows a client to change Note that errors and
the leftmost (least
significant) component of the name result of an entry comparison are all returned in the directory, or same construct.

Note that some directory systems may establish access controls which
permit the values of certain attributes (such as userPassword) to move be

Sermersheim Internet-Draft - Expires Sep 2002 Page 28
Lightweight Directory Access Protocol Version 3

compared but not read. In a subtree search result, it may be that an
attribute of entries 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 new location in client to request
that the directory. server abandon an outstanding operation. The
Modify DN Abandon Request
is defined as follows:

ModifyDNRequest

AbandonRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }

Parameters 16] MessageID

The MessageID MUST be that of an operation which was requested
earlier in this connection.

(The abandon request itself has its own message id. This is distinct
from the Modify DN Request are:

- entry: the Distinguished Name id of the entry to be changed. This
entry may or earlier operation being abandoned.)

There is no response defined in the Abandon Operation. Upon
transmission of an Abandon Operation, a client may not have subordinate entries. Note expect that the
server will not dereference any aliases
operation identified by the Message ID in locating the entry to Abandon Request will be changed.

- newrdn:
abandoned. In the RDN event that will form the leftmost component of a server receives an Abandon Request on
a Search Operation in the new
name midst of transmitting responses to the entry.

- deleteoldrdn: a boolean parameter
search, that controls whether the old
RDN attribute values are server MUST cease transmitting entry responses 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
abandoned request immediately, and MUST NOT send the immediate superior of
SearchResponseDone. Of course, the existing entry.

The result of server MUST ensure that only
properly encoded LDAPMessage PDUs are transmitted.

Clients MUST NOT send abandon requests for the name change attempted by 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 server upon receipt 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
a Modify DN Request is returned LDAP, in the Modify DN Response,
order to allow additional operations to be defined as
follows:

ModifyDNResponse for services not
available elsewhere in this protocol, for instance digitally signed
operations and results.

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 13] LDAPResult 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }

Sermersheim Internet-Draft - Expires July Sep 2002 Page 33 29
Lightweight Directory Access Protocol Version 3

Upon receipt of a ModifyDNRequest,

The requestName is a server will attempt dotted-decimal representation of the OBJECT
IDENTIFIER corresponding to perform the name change. request. The result of the name change attempt requestValue is
information in a form defined by that request, encapsulated inside an
OCTET STRING.

The server will be
returned respond 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 attempt
to rename the entry to be "cn=John Cougar Smith,c=US". If there was
already an entry with that name, an LDAPMessage containing the operation would fail with error
code entryAlreadyExists.
ExtendedResponse.

ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }

If the deleteoldrdn parameter is TRUE, server does not recognize the values forming request name, it MUST return
only the old RDN
are deleted response fields from LDAPResult, containing the entry. If the deleteoldrdn parameter
protocolError result code.

5. Protocol Element Encodings and Transfer

One underlying service is FALSE,
the values forming defined here. Clients and servers SHOULD
implement the old RDN will be retained as non-distinguished
attribute values mapping of the entry. LDAP over TCP described in 5.2.1.

5.1. Protocol Encoding

The server may not perform the
operation and return an error code if protocol elements of LDAP are encoded for exchange using the setting
Basic Encoding Rules (BER) [X.690] of ASN.1 [X.680]. However, due to
the deleteoldrdn
parameter would cause a schema inconsistency high overhead involved in using certain elements of the entry.

Note that X.500 restricts BER, the ModifyDN operation to only affect
entries that
following additional restrictions are contained within a single server. If the placed on BER-encodings of LDAP server
is mapped onto DAP, then this restriction will apply, and
protocol elements:

(1) Only the
resultCode affectsMultipleDSAs definite form of length encoding will be returned if this error
occurred. In general clients MUST NOT expect to used.

(2) OCTET STRING values will 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 encoded 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: primitive form only.

(3) If the name value of a BOOLEAN type is true, the entry encoding MUST have
its contents octets set to hex "FF".

(4) If a value of a type is its default value, it MUST be compared with. Note that the
server SHOULD NOT dereference any aliases absent.
Only some BOOLEAN and INTEGER types have default values in locating the entry this
protocol definition.

These restrictions do not apply to
be compared with.

- ava: the assertion 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 which all 8 bits in an attribute octet being significant in the entry is to be
compared. data
stream.

Sermersheim Internet-Draft - Expires Sep 2002 Page 30
Lightweight Directory Access Protocol Version 3

5.2.1. Transmission Control Protocol (TCP)

The result of the compare attempted by encoded LDAPMessage PDUs are mapped directly onto the server upon receipt of a
Compare Request TCP
bytestream. It is returned in recommended that server implementations running
over the Compare Response, defined as
follows:

CompareResponse ::= [APPLICATION 15] LDAPResult

Upon receipt of a Compare Request, TCP MAY provide a server will attempt to perform protocol listener on the requested comparison. 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 result server MUST be capable of recognizing all the comparison will be
returned to mandatory attribute
type names and implement the client syntaxes specified in the Compare Response. Note [Syntaxes].
Servers MAY also recognize additional attribute type names.

6.2. Client Implementations

Clients which request referrals MUST ensure that errors and they do not loop
between servers. They MUST NOT repeatedly contact the result of comparison are all returned in same server for
the same construct.

Sermersheim Internet-Draft - Expires July 2002 Page 34
Lightweight Directory Access Protocol Version 3

Note that some directory systems may establish access controls which
permit request with the values of certain attributes (such as userPassword) to be
compared but not read. In a search result, it same target entry name, scope and filter.
Some clients may be using a counter that is incremented each time
referral handling occurs for an
attribute operation, and these kinds of that type would clients
MUST be returned, but able to handle a DIT with an empty set of
values.

4.11. Abandon Operation

The function at least ten layers of naming
contexts between the Abandon Operation is to allow root and a client to request
that leaf entry.

In the server abandon an outstanding operation. The Abandon Request
is defined as follows:

AbandonRequest ::= [APPLICATION 16] MessageID

The MessageID MUST be that of an operation which was requested
earlier in this connection.

(The abandon request itself has its own message id. This is distinct
from the id absence of the earlier operation being abandoned.)

There is no response defined 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 Abandon Operation. Upon
transmission of an Abandon Operation, a same names. The client may expect that can retrieve the
operation identified
subschema entries referenced by the Message ID subschemaSubentry attribute in
the Abandon Request will be
abandoned. In the event that a server receives an Abandon Request on
a Search Operation server's root DSE or in entries held by the midst server.

7. Security Considerations

When used with a connection-oriented transport, this version of transmitting responses to the
search,
protocol provides facilities for simple authentication using a
cleartext password, as well as any SASL mechanism [RFC2222]. SASL
allows for integrity and privacy services to be negotiated.

It is also permitted that the server MUST cease transmitting entry responses can return its credentials to
the
abandoned request immediately, and MUST NOT send client, if it chooses to do so.

Sermersheim Internet-Draft - Expires Sep 2002 Page 31
Lightweight Directory Access Protocol Version 3

Use of cleartext password is strongly discouraged where the
SearchResponseDone. Of course,
underlying transport service cannot guarantee confidentiality and may
result in disclosure of the server MUST ensure password to unauthorized parties.

When used with SASL, it should be noted that only
properly encoded LDAPMessage PDUs are transmitted.

Clients MUST NOT send abandon requests for the same operation
multiple times, 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 also ensure that access controls are maintained if that information
is to be prepared provided to receive results from
operations it has abandoned (since these multiple clients, since servers 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 access
control policies which have already been abandoned.

4.12. Extended Operation

An extension mechanism has been added in this version prevent the return of LDAP, entries or attributes in
order
search results except to allow additional operations particular authenticated clients. For
example, caches could serve result information only to the client
whose request caused it to be defined for services not
available elsewhere in this protocol, for instance digitally signed
operations and results.

The extended operation allows clients the cache.

8. Acknowledgements

This document is an update to make requests RFC 2251, by Mark Wahl, Tim Howes, and receive
responses
Steve Kille. Their work along with predefined syntaxes the input of individuals of the
IETF LDAPEXT, LDUP, LDAPBIS, 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, other Working Groups is gratefully
acknowledged.

9. Normative References

[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.

[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation

[X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules:
Basic, Canonical, and Distinguished Encoding Rules", 1994.

[LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf-
ldapbis-xx.txt (a work in progress).

[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.

[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode
and ISO 10646", RFC 2044, October 1996.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 35 32
Lightweight Directory Access Protocol Version 3

requestValue [1] OCTET STRING OPTIONAL }

The requestName is a dotted-decimal representation of the OBJECT
IDENTIFIER corresponding to the request.

[Models] K. Zeilenga, "LDAP: The requestValue is
information Models", draft-ietf-ldapbis-
models-xx.txt (a work 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 progress).

[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of LDAP over TCP described
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
work in 5.2.1.

5.1. Protocol Encoding

The protocol elements of LDAP are encoded for exchange using the
Basic Encoding Rules (BER) [X.690] of ASN.1 [X.680]. 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 progress).

[Syntaxes] K. Dally (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx.txt, (a work 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".

(4) If a value of a type is its default value, it MUST be absent.
Only some BOOLEAN progress).

[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.

[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.

[RFC2396] Berners-Lee, T., Fielding, R., 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 L. Masinter Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, (a work in the data
stream.

5.2.1. Transmission Control Protocol (TCP) progress).

[RFC2222] Meyers, J., "Simple Authentication and Security Layer",
RFC 2222, October 1997.

10. Editor's Address

Jim Sermersheim
Novell, Inc.
1800 South Novell Place
Provo, Utah 84606, USA
jimse@novell.com
+1 801 861-3088

Sermersheim Internet-Draft - Expires July Sep 2002 Page 36 33
Lightweight Directory Access Protocol Version 3

The encoded 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

Appendix A - LDAP Result Codes

This document describes an Internet protocol.

6.1. Server Implementations

The server MUST be capable of recognizing all the mandatory attribute
type names normative appendix details additional considerations regarding
LDAP result codes and implement the syntaxes specified provides a brief, general description of each
LDAP result code enumerated in [RFC2252]. Servers Section 4.1.10.

Additional result codes MAY also recognize additional attribute type names.

6.2. be defined for use with extensions.
Client Implementations

Clients implementations SHALL treat any result code 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
recognize as an operation, unknown error condition.

A.1 Non-Error Result Codes
These result codes (called "non-error" result codes) do not indicate
an error condition:
success(0),
compareTrue(6),
compareFalse(7),
referral(10), and these kinds of clients
MUST be able
saslBindInProgress(14).

The success(0), compareTrue(6), and compare(7) result codes indicate
successful completion (and, hence, are called to handle a DIT with at least ten layers of naming
contexts between the root as "successful"
result codes).

The referral(10) and a leaf entry.

In saslBindInProgress(14) indicate the absence client is
required to take additional action to complete the operation

A.2 Error Result Codes

A.3 Classes and Precedence of prior agreements with servers, clients SHOULD NOT
assume Error Result Codes

Result codes that servers support any particular schemas beyond those
referenced in section 6.1. Different schemas can have different
attribute types with the same names. indicate error conditions (and, hence, are called
"error" result codes) fall into 6 classes. The client can retrieve the
subschema entries referenced by following list
specifies the subschemaSubentry attribute in
the server's root DSE or in entries held by the server.

7. Security Considerations

When used with a connection-oriented transport, this version precedence of the
protocol provides facilities for the LDAP v2 authentication
mechanism, simple authentication using a cleartext password, as well
as any SASL mechanism [RFC2222]. SASL allows for integrity and
privacy services error classes to be negotiated.

It used when more than
one error is also permitted that the server can return its credentials detected [X511]:
1) Name Errors (codes 32 - 34, 36)
- a problem related to
the client, if it chooses a name (DN or RDN),
2) Update Errors (codes 64 - 69, 71)
- a problem related to an update operation,
3) Attribute Errors (codes 16 - 21)
- a problem related to a supplied attribute,
4) Security Errors (codes 8, 13, 48 - 50)
- a security related problem,
5) Service Problem (codes 3, 4, 7, 11, 12, 51 - 54, 80)
- a problem related to do so.

Use of cleartext password is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and may
result in disclosure provision of the password service, and
6) Protocol Problem (codes 1, 2)
- a problem related to unauthorized parties.

When used with SASL, protocol structure or semantics.

Server implementations SHALL NOT continue processing an operation
after it should be noted has determined that the name field of the
BindRequest an error is not protected against modification. Thus if to be reported. If the
distinguished name of
server detects multiple errors simultaneously, the client (an LDAPDN) is agreed through server SHOULD
report the error with the highest precedence.

Existing LDAP result codes are described as follows:

Sermersheim Internet-Draft - Expires July Sep 2002 Page 37 34
Lightweight Directory Access Protocol Version 3

negotiation

success (0)

Indicates successful completion of an operation.

This result code is normally not returned by the credentials, it takes precedence over any value in
the unprotected name field.

Implementations which cache attributes compare
operation, see compareFalse (5) and entries obtained via LDAP
MUST ensure that access controls are maintained if compareTrue (6).

operationsError (1)

Indicates that information the operation is not properly sequenced with
relation to be provided to multiple clients, since servers may have access
control policies which prevent the return of entries other operations (of same or attributes in
search results except to particular authenticated clients. different type).

For example, caches could serve result information only to this code is returned if the client
whose request caused it attempts to be in
Start TLS [RFC2830] while there are other operations
outstanding or if TLS was already established.

For the cache.

8. Acknowledgements

This document is bind operation only, the code indicates the server
encountered an update internal error.

protocolError (2)

Indicates the server received data which has incorrect
structure.

For bind operation only, the code may be resulted to RFC 2251, indicate
the server does not support the requested protocol version.

timeLimitExceeded (3)

Indicates that the time limit specified by Mark Wahl, Tim Howes, and
Steve Kille. Their work along with the input of individuals of client was
exceeded before the
IETF LDAPEXT, LDUP, LDAPBIS, operation could be completed.

sizeLimitExceeded (4)

Indicates that the size limit specified by the client was
exceeded before the operation could be completed.

compareFalse (5)

Indicates that the operation successfully completes and other Working Groups the
assertion has evaluated to TRUE.

This result code is gratefully
acknowledged.

9. Bibliography

[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) normally only returned by the compare
operation.

compareTrue (6)

Sermersheim Internet-Draft -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.

[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models Expires Sep 2002 Page 35
Lightweight Directory Access Protocol Version 3

Indicates that the operation successfully completes and Service", 1993.

[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.

[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.

[X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 1994.

[X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules:
Basic, Canonical, and Distinguished Encoding Rules", 1994.

[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.

[RFC1823] Howes, T., and M. Smith, "The LDAP Application Program
Interface", RFC 1823, August 1995.

[RFC2044] Yergeau, F., "UTF-8, the
assertion has evaluated to FALSE.

This result code is normally only returned by the compare
operation.

authMethodNotSupported (7)

Indicates that authentication method or mechanism is not
supported.

strongAuthRequired (8)

Except when returned in a transformation format Notice of Unicode
and ISO 10646", RFC 2044, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs Disconnect (see section
4.4.1), this indicates that the server requires the client to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC2222] Meyers, J., "Simple Authentication and Security Layer",
RFC 2222, October 1997.
authentication using a strong(er) mechanism.

referral (10)

Indicates that a referral needs to be chased to complete the
operation (see section 4.1.11).

adminLimitExceeded (11)

Indicates that an admnistrative limit has been exceeded.

unavailableCriticalExtension (12)

Indicates that server cannot perform a critical extension
(see section 4.1.12).

confidentialityRequired (13)

Indicates that data confidentiality protections are required.

saslBindInProgress (14)

Indicates the server requires the client to send a new bind
request, with the same sasl mechanism, to continue the
authentication process (see section 4.2).

noSuchAttribute (16)

Indicates that the named entry does not contain the specified
attribute or attribute value.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 38 36
Lightweight Directory Access Protocol Version 3

[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.

[RFC2253] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.

[RFC2255] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.

[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000

[RFC2830] Hodges, J., Morgan, R., and M. Wahl "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000

10. Editor's Address

Jim Sermersheim
Novell, Inc.
1800 South Novell Place
Provo, Utah 84606, USA
jimse@novell.com
+1 801 861-3088

undefinedAttributeType (17)

Indicates that a request field contains an undefined
attribute type.

inappropriateMatching (18)

Indicates that a request cannot be completed due to an
inappropriate matching.

constraintViolation (19)

Indicates that the client supplied an attribute value which
does not conform to constraints placed upon it by the data
model.

For example, this code is returned when the multiple values
are supplied to an attribute which has a SINGLE-VALUE
constraint.

attributeOrValueExists (20)

Indicates that the client supplied an attribute or value to
be added to an entry already exists.

invalidAttributeSyntax (21)

Indicates that a purported attribute value does not conform
to the syntax of the attribute.

noSuchObject (32)

Indicates that the object does not exist in the DIT.

aliasProblem (33)

Indicates that an alias problem has occurred.

invalidDNSyntax (34)

Indicates that a LDAPDN or RelativeLDAPDN field (e.g. search
base, target entry, ModifyDN newrdn, etc.) of a request does
not conform to the required syntax or contains attribute
values which do not conform to the syntax of the attribute's
type.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 39 37
Lightweight Directory Access Protocol Version 3

Appendix A - Complete ASN.1 Definition

Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS ::=

BEGIN

MessageID ::= INTEGER (0 .. maxInt)

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

aliasDereferencingProblem (36)

Indicates that a problem in dereferencing an alias.

inappropriateAuthentication (48)

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

invalidCredentials (49)

Indicates the supplied credentials are invalid.

insufficientAccessRights (50)

Indicates that the client does not have sufficient access
rights to perform the operation.

busy (51)

Indicates that the server is busy.

unavailable (52)

Indicates that the server is shutting down or a subsystem
necessary to complete the operation is offline.

unwillingToPerform (53)

Indicates that the server is unwilling to perform the
operation.

loopDetect (54)

Indicates that the server has detected an internal loop.

namingViolation (64)

Indicates that the entry name violates naming restrictions.

objectClassViolation (65)

Indicates that the entry violates object class restrictions.

Sermersheim Internet-Draft - 1) --

LDAPString ::= OCTET STRING

LDAPOID ::= OCTET STRING

LDAPDN ::= LDAPString

RelativeLDAPDN ::= LDAPString

AttributeType ::= LDAPString

AttributeDescription ::= LDAPString

AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription

AttributeValue ::= OCTET STRING

AttributeValueAssertion ::= SEQUENCE { Expires Sep 2002 Page 38
Lightweight Directory Access Protocol Version 3

notAllowedOnNonLeaf (66)

Indicates that operation is inappropriately acting upon a
non-leaf entry.

notAllowedOnRDN (67)

Indicates that the operation is inappropriately attempting to
remove a value which forms the entry's relative distinguished
name.

entryAlreadyExists (68)

Indicates that the request cannot be added fulfilled as the
entry already exists.

objectClassModsProhibited (69)

Indicates that the attempt to modify the object class(es) of
an entry objectClass attribute is prohibited.

For example, this code is returned when a when a client
attempts to modify the structural object class of an entry.

affectsMultipleDSAs (71)

Indicates that the operation cannot be completed as it
affects multiple servers (DSAs).

other (80)

Indicates the server has encountered an internal error.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 40 39
Lightweight Directory Access Protocol Version 3

attributeDesc AttributeDescription,

Appendix B - Complete ASN.1 Definition

This appendix is normative.

Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS
EXTENSIBILITY IMPLIED ::=

BEGIN

MessageID ::= INTEGER (0 .. maxInt)

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

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

LDAPOID ::= OCTET STRING -- Constrained to numericoid [Models]

LDAPDN ::= LDAPString

RelativeLDAPDN ::= LDAPString

AttributeDescription ::= LDAPString
-- Constrained to attributedescription
-- [Models]

AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription

Sermersheim Internet-Draft - Expires Sep 2002 Page 40
Lightweight Directory Access Protocol Version 3

AttributeValue ::= OCTET STRING

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

AssertionValue ::= OCTET STRING

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

MatchingRuleId ::= LDAPString

Sermersheim Internet-Draft - Expires July Sep 2002 Page 41
Lightweight Directory Access Protocol Version 3

objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80) (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,
... }

SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }

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

UnbindRequest ::= [APPLICATION 2] NULL

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

Sermersheim Internet-Draft - Expires Sep 2002 Page 42
Lightweight Directory Access Protocol Version 3

derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),

Sermersheim Internet-Draft - Expires July 2002 Page 42
Lightweight Directory Access Protocol Version 3
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }

Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF Filter,
or [1] SET SIZE (1..MAX) 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 }

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

SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }

PartialAttributeList ::= SEQUENCE OF 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 {

Sermersheim Internet-Draft - Expires Sep 2002 Page 43
Lightweight Directory Access Protocol Version 3

add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }

AttributeTypeAndValues ::= SEQUENCE {

Sermersheim Internet-Draft - Expires July 2002 Page 43
Lightweight Directory Access Protocol Version 3
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

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 ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }

END

Sermersheim Internet-Draft - Expires Sep 2002 Page 44
Lightweight Directory Access Protocol Version 3

Appendix C - Change History

C.1 Changes made to RFC 2251:

C.1.1 Editorial

- Bibliography References: Changed all bibliography references to
use a long name form for readability.
- Changed occurrences of "unsupportedCriticalExtension"
"unavailableCriticalExtension"
- Fixed a small number of misspellings (mostly dropped letters).

C.1.2 Section 1

- Removed IESG note.

C.1.3 Section 9

- Added references to RFCs 1823, 2234, 2829 and 2830.

C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:

C.2.1 Section 4.1.6

- In the first paragraph, clarified what the contents of an
AttributeValue are. There was confusion regarding whether or not
an AttributeValue that is BER encoded (due to the "binary" option)
is to be wrapped in an extra OCTET STRING.
- To the first paragraph, added wording that doesn't restrict other
transfer encoding specifiers from being used. The previous wording
only allowed for the string encoding and the ;binary encoding.
- To the first paragraph, added a statement restricting multiple
options that specify transfer encoding from being present. This
was never specified in the previous version and was seen as a
potential interoperability problem.
- Added a third paragraph stating that the ;binary option is
currently the only option defined that specifies the transfer
encoding. This is for completeness.

C.2.2 Section 4.1.7

- Generalized the second paragraph to read "If an option specifying
the transfer encoding is present in attributeDesc, the
AssertionValue is encoded as specified by the option...".
Previously, only the ;binary option was mentioned.

C.2.3 Sections 4.2, 4.9, 4.10

- Added alias dereferencing specifications. In the case of modDN,
followed precedent set on other update operations (... alias is
not dereferenced...) In the case of bind and compare stated that
servers SHOULD NOT dereference aliases. Specifications were added
because they were missing from the previous version and caused

Sermersheim Internet-Draft - Expires Sep 2002 Page 45
Lightweight Directory Access Protocol Version 3

interoperability problems. Concessions were made for bind and
compare (neither should have ever allowed alias dereferencing) by
using SHOULD NOT language, due to the behavior of some existing
implementations.

C.2.4 Sections 4.5 and Appendix A

- Changed SubstringFilter.substrings.initial, any, and all from
LDAPString to AssertionValue. This was causing an incompatibility
with X.500 and confusion among other TS RFCs.

C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:

C.3.1 Section 3.4

- Reworded text surrounding subschemaSubentry to reflect that it is
a single-valued attribute that holds the schema for the root DSE.
Also noted that if the server masters entries that use differing
schema, each entry's subschemaSubentry attribute must be
interrogated. This may change as further fine-tuning is done to
the data model.

C.3.2 Section 4.1.12

- Specified that the criticality field is only used for requests and
not for unbind or abandon. Noted that it is ignored for all other
operations.

C.3.3 Section 4.2

- Noted that Server behavior is undefined when the name is a null
value, simple authentication is used, and a password is specified.

C.3.4 Section 4.2.(various)

- Changed "unauthenticated" to "anonymous" and "DN" and "LDAPDN" to
"name"

C.3.5 Section 4.2.2

- Changed "there is no authentication or encryption being performed
by a lower layer" to "the underlying transport service cannot
guarantee confidentiality"

C.3.6 Section 4.5.2

- Removed all mention of ExtendedResponse due to lack of
implementation.

C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:

C.4.1 Section 4

Sermersheim Internet-Draft - Expires July Sep 2002 Page 44 46
Lightweight Directory Access Protocol Version 3

Appendix B

- Change History

B.1 Changes made to RFC 2251:

B.1.1 Editorial Removed "typically" from "and is typically transferred" in the
first paragraph. We know of no (and can conceive of no) case where
this isn't true.
- Bibliography References: Changed all bibliography references to
use a long name form Added "Section 5.1 specifies how the LDAP protocol is encoded." To
the first paragraph. Added this cross reference for readability.
- Changed occurrences of "unsupportedCriticalExtension"
"unavailableCriticalExtension"
- Fixed a small number of misspellings (mostly dropped letters).

B.1.2 Section 1

- Removed IESG note.

B.1.3 Section 9

- Added references "version 3 " to RFCs 1823, 2234, 2829 and 2830.

B.2 Changes made "version 3 or later" in the second
paragraph. This was added to draft-ietf-ldapbis-protocol-00.txt:

B.2.1 Section 4.1.6 clarify the original intent.
- In Changed "protocol version" to "protocol versions" in the first paragraph, clarified what third
paragraph. This attribute is multi-valued with the contents intent of an
AttributeValue are. There was confusion regarding whether or
holding all supported versions, not
an AttributeValue that is BER encoded (due just one.

C.4.2 Section 4.1.8

- Changed "when transferred in protocol" to "when transferred from
the "binary" option)
is server to be wrapped the client" in an extra OCTET STRING.
- To the first paragraph, added wording that doesn't restrict other
transfer encoding specifiers from being used. The previous wording paragraph. This is to
clarify that this behavior only allowed for the string encoding and happens when attributes are being
sent from the ;binary encoding. server.

C.4.3 Section 4.1.10

- To Changed "servers will return responses containing fields of type
LDAPResult" to "servers will return responses of LDAPResult or
responses containing the first paragraph, added a components of LDAPResponse". This
statement restricting multiple
options that specify transfer encoding was incorrect and at odds with the ASN.1. The fix here
reflects the original intent.
- Dropped '--new' from being present. result codes ASN.1. This
was never specified simplification in the previous version and was seen as a
potential interoperability problem.
comments just reduces unneeded verbiage.

C.4.4 Section 4.1.11

- Added Changed "It contains a third paragraph stating that reference to another server (or set of
servers)" to "It contains one or more references to one or more
servers or services" in the ;binary option is
currently first paragraph. This reflects the only option defined
original intent and clarifies that specifies the transfer
encoding. This is for completeness.

B.2.2 URL may point to non-LDAP
services.

C.4.5 Section 4.1.7 4.1.12

- Generalized Changed "The server MUST be prepared" to "Implementations MUST be
prepared" in the second eighth paragraph to read "If an option specifying
the transfer encoding reflect that both client and
server implementations must be able to handle this (as both parse
controls).

C.4.6 Section 4.4

- Changed "One unsolicited notification is present in attributeDesc, the
AssertionValue defined" to "One
unsolicited notification (Notice of Disconnection) is encoded as specified by the option...".
Previously, only defined" in
the ;binary option was mentioned.

B.2.3 Sections 4.2, 4.9, 4.10 third paragraph. For clarity and readability.

C.4.7 Section 4.5.1

- Added alias dereferencing specifications. In Changed "checking for the case existence of modDN,
followed precedent set on other update operations (... alias is
not dereferenced...) In the case objectClass attribute"
to "checking for the presence of bind and compare stated that
servers SHOULD NOT dereference aliases. Specifications were added
because they were missing from the previous version and caused objectClass attribute" in the
last paragraph. This was done as a measure of consistency (we use

Sermersheim Internet-Draft - Expires July Sep 2002 Page 45 47
Lightweight Directory Access Protocol Version 3

interoperability problems. Concessions were made for bind

the terms present and
compare (neither should have ever allowed alias dereferencing) by
using SHOULD presence rather than exists and existence in
search filters).

C.4.8 Section 4.5.3

- Changed "outstanding search operations to different servers," to
"outstanding search operations" in the fifth paragraph as they may
be to the same server. This is a point of clarification.

C.4.9 Section 4.6

- Changed "clients MUST NOT language, due attempt to delete" to "clients MUST NOT
attempt to add or delete" in the behavior second to last paragraph.
- Change "using the "delete" form" to "using the "add" or "delete"
form" in the second to last paragraph.

C.4.10 Section 4.7

- Changed "Clients MUST NOT supply the createTimestamp or
creatorsName attributes, since these will be generated
automatically by the server." to "Clients MUST NOT supply NO-USER-
MODIFICATION attributes such as createTimestamp or creatorsName
attributes, since these are provided by the server." in the
definition of some existing
implementations.

B.2.4 Sections 4.5 the attributes field. This tightens the language to
reflect the original intent and Appendix A to not leave a hole in which one
could interpret the two attributes mentioned as the only non-
writable attributes.

C.4.11 Section 4.11

- Changed SubstringFilter.substrings.initial, any, and all from
LDAPString "has been" to AssertionValue. "will be" in the fourth paragraph. This was causing an incompatibility
with X.500 and confusion among other TS RFCs.

B.3
clarifies that the server will (not has) abandon the operation.

C.5 Changes made to draft-ietf-ldapbis-protocol-01.txt:

B.3.1 draft-ietf-ldapbis-protocol-03.txt:

C.5.1 Section 3.4 3.2.1

- Reworded text surrounding subschemaSubentry to reflect that it Changed "An attribute is a single-valued type with one or more associated
values. The attribute type is identified by a short descriptive
name and an OID (object identifier). The attribute type governs
whether there can be more than one value of an attribute of that holds the schema for
type in an entry, the root DSE.
Also noted that if syntax to which the server masters entries that use differing
schema, each entry's subschemaSubentry attribute values must be
interrogated. This may change as further fine-tuning is done to conform, the data model.

B.3.2 Section 4.1.12

- Specified
kinds of matching which can be performed on values of that the criticality field is only used for requests
attribute, and
not for unbind or abandon. Noted that it is ignored for all other
operations.

B.3.3 Section 4.2

- Noted that Server behavior is undefined when the name is a null
value, simple authentication functions." to " An attribute is used, and a password is specified.

B.3.4 Section 4.2.(various)

- Changed "unauthenticated" to "anonymous" and "DN"
description (a type and "LDAPDN" to
"name"

B.3.5 Section 4.2.2

- Changed "there is no authentication zero or encryption being performed
by a lower layer" more options) with one or more
associated values. The attribute type governs whether the
attribute can have multiple values, the syntax and matching rules
used to "the underlying transport service cannot
guarantee confidentiality"

B.3.6 Section 4.5.2

- Removed all mention construct and compare values of ExtendedResponse due to lack that attribute, and other
functions. Options indicate modes of
implementation.

B.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:

B.4.1 transfer and other
functions.". This points out that an attribute consists of both
the type and options.

C.5.2 Section 4

Sermersheim Internet-Draft - Expires July Sep 2002 Page 46 48
Lightweight Directory Access Protocol Version 3

- Removed "typically" from "and is typically transferred" in the
first paragraph. We know of no (and can conceive of no) case where
this isn't true.
- Added Changed "Section 5.1 specifies how the LDAP protocol is encoded." To the first paragraph. Added this cross reference encoding rules for readability.
- Changed "version 3 " to "version 3 or later" in the second
paragraph. This was added to clarify the original intent.
- Changed "protocol version" to "protocol versions" in the third
paragraph. This attribute is multi-valued with the intent of
holding all supported versions, not just one.

B.4.2 Section 4.1.8

- Changed "when transferred in LDAP
protocol" to "when transferred from
the server to the client" in "Section 5.1 specifies how the first paragraph. This protocol is to
clarify that this behavior only happens when attributes are being
sent from the server.

B.4.3 encoded
and transferred."

C.5.3 Section 4.1.10 4.1.2

- Changed "servers will return responses containing fields of type
LDAPResult" to "servers will return responses of LDAPResult or
responses containing Added ABNF for the components textual representation of LDAPResponse". This
statement LDAPOID. Previously,
there was incorrect and at odds with the ASN.1. The fix here
reflects the original intent.
- Dropped '--new' from result codes ASN.1. This simplification in
comments just reduces unneeded verbiage.

B.4.4 no formal BNF for this construct.

C.5.4 Section 4.1.11 4.1.4

- Changed "It contains a reference to another server (or set of
servers)" to "It contains one or more references "This identifier may be written as decimal digits with
components separated by periods, e.g. "2.5.4.10"" to one or more
servers or services" "may be
written as defined by ldapOID in section 4.1.2" in the first second
paragraph. This reflects was done because we now have a formal BNF
definition of an oid.

C.5.5 Section 4.1.5

- Changed the
original intent BNF for AttributeDescription to ABNF. This was done
for readability and clarifies consistency (no functional changes involved).
- Changed "Options present in an AttributeDescription are never
mutually exclusive." to "Options MAY be mutually exclusive. An
AttributeDescription with mutually exclusive options is treated as
an undefined attribute type." for clarity. It is generally
understood that this is the URL may point to non-LDAP
services.

B.4.5 Section 4.1.12 original intent, but the wording could
be easily misinterpreted.
- Changed "The server MUST "Any option could be prepared" associated with any AttributeType,
although not all combinations may be supported by a server." to "Implementations MUST
"Though any option or set of options could be
prepared" in associated with any
AttributeType, the eighth paragraph to reflect that both client and server implementations must support for certain combinations may be able
restricted by attribute type, syntaxes, or other factors.". This
is to handle this (as clarify the meaning of 'combination' (it applies both parse
controls).

B.4.6 Section 4.4

- Changed "One unsolicited notification is defined" to "One
unsolicited notification (Notice
combination of Disconnection) is defined" in
the third paragraph. For clarity attribute type and readability.

B.4.7 options, and combination of
options). It also gives examples of *why* they might be
unsupported.

C.5.6 Section 4.5.1 4.1.11

- Changed "checking for the existence of the objectClass attribute" wording regarding 'equally capable' referrals to "checking for "If
multiple URLs are present, the presence of client assumes that any URL may be
used to progress the objectClass attribute" in operation.". The previous language implied
that the
last paragraph. This server MUST enforce rules that it was done as a measure practically
incapable of. The new language highlights the original intent--
that is, that any of consistency (we use the referrals may be used to progress the
operation, there is no inherent 'weighting' mechanism.

C.5.7 Section 4.5.1 and Appendix A

- Added the comment "-- initial and final can occur at most once",
to clarify this restriction.

C.5.8 Section 5.1

Sermersheim Internet-Draft - Expires July Sep 2002 Page 47 49
Lightweight Directory Access Protocol Version 3

- Changed heading from "Mapping Onto BER-based Transport Services"
to "Protocol Encoding".

C.5.9 Section 5.2.1

- Changed "The LDAPMessage PDUs" to "The encoded LDAPMessage PDUs"
to point out that the terms present and presence rather than exists and existence in
search filters).

B.4.8 PDUs are encoded before being streamed to
TCP.

C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:

C.6.1 Section 4.5.3 4.5.1 and Appendix A

- Changed "outstanding search operations the ASN.1 for the and and or choices of Filter to different servers," have a
lower range of 1. This was an omission in the original ASN.1

C.6.2 Various

- Fixed various typo's

C.7 Changes made to
"outstanding search operations" draft-ietf-ldapbis-protocol-05.txt:

C.7.1 Section 3.2.1

- Added "(as defined in Section 12.4.1 of [X.501])" to the fifth
paragraph as they may
be when talking about "operational attributes". This is
because the term "operational attributes" is never defined.
Alternately, we could drag a definition into the spec, for now,
I'm just pointing to the same server. This is a point of clarification.

B.4.9 reference in X.501.

C.7.2 Section 4.6 4.1.5

- Changed "clients MUST NOT attempt to delete" "And is also case insensitive" to "clients MUST NOT
attempt "The entire
AttributeDescription is case insensitive". This is to add clarify
whether we're talking about the entire attribute description, or delete" in
just the second to last paragraph. options.

- Change "using the "delete" form" to "using Expounded on the "add" or "delete"
form" in definition of attribute description options. This
doc now specifies a difference between transfer and tagging
options and describes the second semantics of each, and how and when
subtyping rules apply. Now allow options to last paragraph.

B.4.10 Section 4.7

- Changed "Clients MUST NOT supply the createTimestamp or
creatorsName attributes, since these will be generated
automatically by the server." transmitted in any
order but disallow any ordering semantics to "Clients MUST NOT supply NO-USER-
MODIFICATION attributes such as createTimestamp or creatorsName
attributes, since these be implied. These
changes are provided by the server." in the
definition result of the attributes field. This tightens the language ongoing input from an engineering team
designed to
reflect the original intent deal with ambiguity issues surrounding attribute
options.

C.7.3 Sections 4.1.5.1 and 4.1.6

- Refer to not leave a hole in which one
could interpret the two attributes mentioned non "binary" transfer encodings as the only non-
writable attributes.

B.4.11 Section 4.11 "native encoding"
rather than "string" encoding to clarify and avoid confusion.

C.8 Changes made to draft-ietf-ldapbis-protocol-05.txt:

Sermersheim Internet-Draft - Expires Sep 2002 Page 50
Lightweight Directory Access Protocol Version 3

C.8.1 Title

- Changed to "LDAP: The Protocol" to be consisted with other working
group documents

C.8.2 Abstract

- Changed "has been" Moved above TOC to "will be" in the fourth paragraph. This
clarifies that the server will (not has) abandon the operation.

B.5 Changes made conform to draft-ietf-ldapbis-protocol-03.txt:

B.5.1 Section 3.2.1 new guidelines

- Changed "An attribute is a type Reworded to make consistent with one or more associated
values. The attribute type other WG documents.

- Moved 2119 conventions to "Conventions" section

C.8.3 Introduction

- Created to conform to new guidelines

C.8.4 Models

- Removed section. There is identified by a short descriptive
name and an OID (object identifier). The attribute type governs
whether there can be more than only one value of an attribute of that
type model in an entry, the syntax to which this document
(Protocol Model)

C.8.5 Protocol Model

- Removed antiquated paragraph: "In keeping with the values must conform, goal of easing
the
kinds costs associated with use of matching which can be performed on values the directory, it is an objective
of that
attribute, and other functions." this protocol to " An attribute is a
description (a type and zero or more options) with one or more
associated values. The attribute type governs whether minimize the
attribute can have multiple values, complexity of clients so as to
facilitate widespread deployment of applications capable of using
the syntax directory."

- Removed antiquated paragraph concerning LDAP v1 and matching rules
used to construct v2 and compare values of that attribute,
referrals.

C.8.6 Data Model

- Removed Section 3.2 and other
functions. Options indicate modes subsections. These have been moved to
[Models]

C.8.7 Relationship to X.500

- Removed section. It has been moved to [Roadmap]

C.8.8 Server Specific Data Requirements

- Removed section. It has been moved to [Models]

C.8.9 Elements of transfer and other
functions.". This points out that an attribute consists Protocol

- Added "Section 5.1 specifies how the protocol is encoded and
transferred." to the end of both the type first paragraph for reference.

- Reworded notes about extensibility, and options.

B.5.2 Section 4 now talk about implied
extensibility and the use of ellipses in the ASN.1

Sermersheim Internet-Draft - Expires July Sep 2002 Page 48 51
Lightweight Directory Access Protocol Version 3

- Changed "Section 5.1 specifies the encoding rules for the LDAP
protocol" Removed references to "Section 5.1 specifies how the protocol is encoded LDAPv2 in third and transferred."

B.5.3 Section 4.1.2

- Added ABNF for the textual representation of LDAPOID. Previously,
there was no formal BNF for this construct.

B.5.4 Section 4.1.4 fourth paragraphs.

C.8.10 Message ID

- Changed "This identifier may be written as decimal digits with
components separated by periods, e.g. "2.5.4.10"" to "may be
written as defined by ldapOID in section 4.1.2" in the Reworded second
paragraph. This was done because we now paragraph to "The message ID of a request MUST
have a formal BNF
definition of an oid.

B.5.5 Section 4.1.5

- Changed non-zero value different from the BNF for AttributeDescription to ABNF. This was done
for readability and consistency (no functional changes involved).
- Changed "Options present values of any other
requests outstanding in an AttributeDescription are never
mutually exclusive." to "Options MAY be mutually exclusive. An
AttributeDescription with mutually exclusive options is treated as
an undefined attribute type." for clarity. It is generally
understood that the LDAP session of which this message is the original intent, but the wording could
be easily misinterpreted.
- Changed "Any option could be associated with any AttributeType,
although not all combinations may be supported by
a server." to
"Though any option or set of options could be associated with any
AttributeType, part. The zero value is reserved for the unsolicited
notification message." (Added notes about non-zero and the server support zero
value).

C.8.11 String Types

- Removed ABNF for certain combinations may be
restricted by attribute type, syntaxes, or other factors.". This LDAPOID and added "Although an LDAPOID is encoded
as an OCTET STRING, values are limited to clarify the meaning definition of 'combination' (it applies both to
combination
numericoid given in Section 1.3 of attribute type [Models]."

C.8.12 Distinguished Name and options, Relative Distinguished Name

- Removed ABNF and combination of
options). It also gives examples of *why* they might be
unsupported.

B.5.6 Section 4.1.11 referred to [Models] and [LDAPDN] where this is
defined.

C.8.13 Attribute Type

- Changed Removed sections. It's now in the wording [Models] doc.

C.8.14 Attribute Description

- Removed ABNF and aligned section with [Models]

- Moved AttributeDescriptionList here.

C.8.15 Transfer Options

- Added section and consumed much of old options language (while
aligning with [Models]

C.8.16 Binary Transfer Option

- Clarified intent regarding 'equally capable' referrals exactly what is to "If
multiple URLs are present, the client assumes that any URL may be
used to progress the operation.". The previous language implied
that the server MUST enforce rules BER encoded.

- Clarified that clients must not expect ;binary when not asking for
it was practically
incapable of. The new language highlights the original intent--
that is, that any of the referrals may be used (;binary, as opposed to progress ber encoded data).

C.8.17 Attribute

- Use the
operation, there is no inherent 'weighting' mechanism.

B.5.7 Section 4.5.1 and Appendix A term "attribute description" in lieu of "type"

- Added Clarified the comment "-- initial and final can occur at most once",
to clarify this restriction.

B.5.8 Section 5.1 fact that clients cannot rely on any apparent
ordering of attribute values.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 49 52
Lightweight Directory Access Protocol Version 3

C.8.18 LDAPResult

- Changed heading from "Mapping Onto BER-based Transport Services"
to "Protocol Encoding".

B.5.9 Section 5.2.1

- Changed "The LDAPMessage PDUs" to "The encoded LDAPMessage PDUs" To resultCode, added ellipses "..." to point out that the PDUs are encoded before being streamed to
TCP.

B.6 Changes made enumeration to draft-ietf-ldapbis-protocol-04.txt:

B.6.1 Section 4.5.1 indicate
extensibility. and added a note, pointing to [LDAPIANA]

- Removed error groupings ad refer to Appendix A A.

C.8.19 Bind Operation

- Changed Added "Prior to the ASN.1 BindRequest, the implied identity is
anonymous. Refer to [AuthMeth] for the and and or choices authentication-related
semantics of Filter this operation." to have a
lower range of 1. This was an omission in the original ASN.1

B.6.2 Various

- Fixed various typo's

B.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:

B.7.1 Section 3.2.1 first paragraph.

- Added "(as ellipses "..." to AuthenticationChoice and added a note
"This type is extensible as defined in Section 12.4.1 3.6 of [X.501])" to the fifth
paragraph when talking about "operational attributes". This is
because the term "operational attributes" is never defined.
Alternately, we could drag [LDAPIANA].
Servers that do not support a definition into the spec, for now,
I'm just pointing to the reference choice supplied by a client will
return authMethodNotSupported in X.501.

B.7.2 Section 4.1.5

- Changed "And is also case insensitive" to "The entire
AttributeDescription is case insensitive". This is to clarify
whether we're talking about the entire attribute description, or
just result code of the options.
BindResponse."

- Expounded on Simplified text regarding how the definition server handles unknown versions.
Removed references to LDAPv2

C.8.20 Sequencing of attribute description options. This
doc now specifies a difference between transfer and tagging
options and describes the semantics of each, Bind Request

- Aligned with [AuthMeth] In particular, paragraphs 4 and how 6 were
removed, while a portion of 4 was retained (see C.8.9)

C.8.21 Authentication and when
subtyping rules apply. other Security Service

- Section was removed. Now allow options to be transmitted in any
order but disallow any ordering semantics to be implied. These
changes are [AuthMeth]

C.8.22 Continuation References in the Search Result

- Added "If the result originating search scope was singleLevel, the scope
part of ongoing input from an engineering team
designed to deal with ambiguity issues surrounding attribute
options.

B.7.3 Sections 4.1.5.1 and 4.1.6 the URL will be baseObject."

C.8.23 Security Considerations

- Refer Removed reference to non "binary" transfer encodings LDAPv2

C.8.24 Result Codes

- Added as "native encoding"
rather than "string" encoding normative appendix A

C.8.25 ASN.1

- Added EXTENSIBILITY IMPLIED

- Added a number of comments holding referenced to clarify [Models] and avoid confusion.

Appendix C
[ISO10646].

- Outstanding Work Items Removed AttributeType. It is not used.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 50 53
Lightweight Directory Access Protocol Version 3

C.1

Appendix D - Outstanding Work Items

D.1 Integrate result codes draft.

- The result codes draft should be reconciled with this draft.
Operation-specific instructions will reside with operations while
the error-specific sections will be added as an appendix.

C.2 Section 3.1

- Add "This also increases the complexity of clients in this
version." to fourth paragraph.

C.3 Section 4

- Change "MUST ignore elements of SEQUENCE encodings whose tags they
do not recognize" to "MUST ignore tagged elements of SEQUENCE
encodings Note
that they do not recognize" in the first paragraph.
- Change "version 2 may not provide this attribute." to "version 2
MAY NOT provide this attribute, or a root DSE." in the third
paragraph.

C.4 Section 4.1.1

- Change "the client may discard the PDU, or may abruptly close the
connection." to "the client MAY discard the PDU, or MAY abruptly
close the connection." in the fourth paragraph.

C.5 Section 4.1.1.1

- Add "If an unsolicited notification as described in section 4.4 there is
sent from a server, the messageID value MUST be zero." result codes appendix now. Still need to first
paragraph. reconcile
with each operation.

D.2 Verify references.

- Change "MUST have a value different" to "MUST Many referenced documents have a non-zero
value different" in the second paragraph. changed. Ensure references and
section numbers are correct.

D.3 Usage of Naming Context

- Make sure occurrences of "namingcontext" and naming context" are
consistent with [Models].

D.5 Section 4.1.1.1

- Remove "or of the abandoned operation until it has received a
response from the server for another request invoked subsequent to
the abandonRequest," from the fourth paragraph as this imposes
synchronous behavior on the server.

C.7 Section 4.1.4

- Add "Note that due to the restriction above, and due to this
allowance, servers MUST ensure that, within a controlling
subschema, no two attributes be named the same." to the fifth
paragraph.
- Resolve issue on list with the subject "Attribute Type character
set".

C.8 Section 4.1.5

- Change "A server may treat" to "A server MUST treat" in the second
to last paragraph.
- Change "A server MUST treat an AttributeDescription with any
options it does not implement as an unrecognized attribute type."

Sermersheim Internet-Draft - Expires July 2002 Page 51
Lightweight Directory Access Protocol Version 3

to "A server MUST treat an AttributeDescription with any options
it does not implement or support as an unrecognized attribute
type." in the second to last paragraph.
- Clarify the statement "An AttributeDescription with one or more
options is treated as a subtype of the attribute type without any
options". There is an unresolved thread titles "RFC 2596
questions" on the ietf-ldapext list regarding this.

C.9

D.9 Section 4.1.5.1 4.1.5.2

- Add "Servers SHOULD only return attributes with printable string
representations as binary when clients request binary transfer."
to the second paragraph.
- Clarify whether the "binary" attribute type option is to be
treated as a subtype.

C.10

D.10 Section 4.1.6

- Change "containing an encoded value of an AttributeValue data
type" to "containing an encoded attribute value data type"

C.11

D.11 Section 4.1.7

- Change "For all the string-valued user attributes described in
[5], the assertion value syntax is the same as the value syntax."
to "The assertion value syntax for all attributes using human-
readable syntaxes as described in [RFC2252] is the same as the
value syntax unless otherwise noted (an example being
objectIdentifierFirstComponentMatch)." in the third paragraph.
- Find out what the last sentence in third paragraph means (Clients
may use attributes...)
- Add a fourth paragraph: "Servers SHOULD NOT generate codes 81-90
as these are reserved for use by historical APIs [RFC 1823]. Later
API specifications SHOULD avoid using the resultCode enumeration
to represent anything other than a protocol result indication."

C.13

D.13 Section 4.1.11

- Add "after locating the target entry" to the first paragraph.

C.14

Sermersheim Internet-Draft - Expires Sep 2002 Page 54
Lightweight Directory Access Protocol Version 3

D.14 Section 4.1.12

- Specify whether or not servers are to advertise the OIDs of known
response controls.

C.15

D.15 Section 4.2

- Change "LDAPDN" to "identity" in the definition of the name field.
- Rework definition of the name field to enumerate empty password and
name combinations. <Needs more work following discussion on list>

C.17

D.17 Section 4.2.2

- Add "as the authentication identity" to second paragraph.

Sermersheim Internet-Draft - Expires July 2002 Page 52
Lightweight Directory Access Protocol Version 3

C.18

D.18 Section 4.2.3

- Change "If the bind was successful, the resultCode will be
success, otherwise it will be one of" to "If the bind was
successful, the resultCode will be success, otherwise it MAY be
one of" in the third paragraph. <May need further refinement when
reconciled with resultCode draft>.
- Change "operationsError" to "other" as a result code.
- Change "If the client bound with the password choice" to "If the
client bound with the simple choice" in the last paragraph.

C.19

D.19 Section 4.3

- Change "a protocol client may assume that the protocol session is
terminated and MAY close the connection." to "a protocol client
MUST assume that the protocol session is terminated and MAY close
the connection." in the second paragraph.
- Change "a protocol server may assume" to "a protocol server MUST
assume" in the second paragraph.
- Change "and may close the connection" to "and MUST close the
connection" in the second paragraph.

C.20

D.20 Section 4.4

- Add "Servers SHOULD NOT assume LDAPv3 clients understand or
recognize unsolicited notifications or unsolicited controls other
than Notice of Disconnection defined below. Servers SHOULD avoid
sending unsolicited notifications unless they know (by related
request or other means) that the client can make use of the
notification." as a fourth paragraph.

C.21

D.21 Section 4.5.1

- Make sure the use of "subordinates" in the derefInSearching
definition is correct. See "derefInSearching" on list.

C.22

D.22 Section 4.5.2

Sermersheim Internet-Draft - Expires Sep 2002 Page 55
Lightweight Directory Access Protocol Version 3

- Add "associated with a search operation" to the sixth paragraph.
- Same problem as in C.5.

C.23 D.5.

D.23 Section 4.5.3

- Add "Similarly, a server MUST NOT return a SearchResultReference
when the scope of the search is baseObject. If a client receives
such a SearchResultReference it MUST interpret is as a protocol
error and MUST NOT follow it." to the first paragraph.
- Add "If the scope part of the LDAP URL is present, the client MUST
use the new scope in its next request to progress the search. If
the scope part is absent the client MUST use subtree scope to
complete subtree searches and base scope to complete one level
searches." to the third paragraph.

Sermersheim Internet-Draft - Expires July 2002 Page 53
Lightweight Directory Access Protocol Version 3

C.24

D.24 Section 4.5.3.1

- Change examples to use dc naming.

C.25

D.25 Section 4.6

- Resolve the meaning of "and is ignored if the attribute does not
exist". See "modify: "non-existent attribute"" on the list.

C.26

D.26 Section 4.7

- Change examples to use dc naming.
- Clarify the paragraph that talks about structure rules. See
"discussing structure rules" on the list.

C.27

D.27 Section 4.10

- Specify what happens when the attr is missing vs. attr isn't in
schema. Also what happens if there's no equality matching rule.

C.28

D.28 Section 4.11

- Change "(since these may have been in transit when the abandon was
requested)." to "(since these may either have been in transit when
the abandon was requested, or are not able to be abandoned)." in
the fifth paragraph.
- Add "Abandon and Unbind operations are not able to be abandoned.
Other operations, in particular update operations, or operations
that have been chained, may not be abandonable (or immediately
abandonable)." as the sixth paragraph.

C.29

D.29 Section 4.12

- Change "digitally signed operations and results" to "for instance
StartTLS [RFC2830]"

C.30

D.30 Section 5.1

Sermersheim Internet-Draft - Expires Sep 2002 Page 56
Lightweight Directory Access Protocol Version 3

- Add "control and extended operation values" to last paragraph. See
"LBER (BER Restrictions)" on list.

C.31

D.31 Section 5.2.1

- Add "using the BER-based described in section 5.1".

C.32

D.32 Section 6.1

- Add "that are used by those attributes" to the first paragraph.
- Add "Servers which support update operations MUST, and other
servers SHOULD, support strong authentication mechanisms described
in [RFC2829]." as a second paragraph.
- Add "Servers which provide access to sensitive information MUST,
and other servers SHOULD support privacy protections such as those
described in [RFC2829] and [RFC2830]." as a third paragraph.

Sermersheim Internet-Draft - Expires July 2002 Page 54
Lightweight Directory Access Protocol Version 3

C.33

D.33 Section 7

- Add "Servers which support update operations MUST, and other
servers SHOULD, support strong authentication mechanisms described
in [RFC2829]." as a fourth paragraph.
- Add "In order to automatically follow referrals, clients may need
to hold authentication secrets. This poses significant privacy and
security concerns and SHOULD be avoided." as a sixth paragraph.
- Add "This document provides a mechanism which clients may use to
discover operational attributes. Those relying on security by
obscurity should implement appropriate access controls to
restricts access to operational attributes per local policy." as
an eighth paragraph.
- Add "This document provides a mechanism which clients may use to
discover operational attributes. Those relying on security by
obscurity should implement appropriate access controls to
restricts access to operational attributes per local policy." as
an eighth paragraph.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 55 57
Lightweight Directory Access Protocol Version 3

Full Copyright Statement

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.

Sermersheim Internet-Draft - Expires July Sep 2002 Page 56 58
----