WDIFF

draft-ietf-asid-ldapv3-protocol-01.txt --> draft-ietf-asid-ldapv3-protocol-02.txt

Network Working Group M. Wahl
INTERNET-DRAFT ISODE Consortium Critical Angle Inc.
Obsoletes: RFC 1777, RFC 1798 T. Howes
Netscape Communications Corp.
S. Kille
ISODE Consortium
Expires in six months from 5 June 30 August 1996
Intended Category: Standards Track

Lightweight Directory Access Protocol (v3)
<draft-ietf-asid-ldapv3-protocol-01.txt>
<draft-ietf-asid-ldapv3-protocol-02.txt>

Table of Contents - see end of document.

1. Status of this Memo

This document is an Internet-Draft. 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."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

2. Abstract

The protocol described in this document is designed to provide access
to directories supporting the X.500 models, while not incurring the
resource requirements of the X.500 Directory Access Protocol (DAP). This
protocol is specifically targeted at management applications and browser
applications that provide read/write interactive access to directories.
When used with a directory supporting the X.500 protocols, it is
intended to be a complement to the X.500 DAP.

Key aspects of this version of LDAP are:

- All protocol elements of LDAP (RFC 1777) and CLDAP (RFC 1798) are
supported.

- Protocol elements are carried directly over TCP or other transport,
bypassing much of the session/presentation overhead. Connectionless
transport (UDP) is also supported for efficient lookup operations.

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

- New features have been added to enable more powerful clients, such as
the abilities to retrieve attribute values in binary or search results
in pages.

Wahl, Howes, Kille [Page 1]

INTERNET-DRAFT LDAP August 1996

- Important features of X.500(1993) and X.500(1997) are included.

- Referrals to other servers may be returned.

- The protocol may be extended to support bilaterally-defined
operations.

- Several service session controls may be requested by the client.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

3. Models

Interest in X.500 [1] directory technologies in the Internet has lead to
efforts to reduce the high "cost of entry" associated with use of these
technologies. This document continues the efforts to define directory
protocol alternatives: it updates the LDAP [2] protocol specification,
adding support for new features, including some support for servers connecting
to X.500(1993). X.500 services that implement the 1993 or 1997 edition protocols.

3.1. Protocol Model

The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, a
client transmits a protocol request describing the operation to be
performed to a server, which is then responsible for performing
the necessary operations on operation(s) in the directory. Upon completion of
the
operations, 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 utilizing 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.
Rrequests
Requests and responses for multiple operations may be exchanged
between a client and server in any order, provided the client
eventually receives a response for every request that requires one.

In LDAP versions 1 and 2, no provision was made for protocol servers
returning referrals to clients. However, for improved performance and
distribution this version of the protocol permits servers to return to
clients referrals to other servers if requested. This allows servers,
if requested by clients, to offload the work of contacting other servers
to progress operations.

Clients may also request that no referrals be returned, in which case
the server must ensure that the operation is performed against the
directory, or else return an error. This is the default.

Note that this protocol can be mapped to a strict subset of the
X.500(1993)
X.500(1997) directory abstract service, so it can be cleanly provided
by the DAP. However there is not a one-to-one mapping between LDAP
protocol operations and DAP operations: some server implementations
acting as a gateway to X.500 directories may need to make multiple DAP
requests to perform extended operations.

Wahl, Howes, Kille [Page 2]

INTERNET-DRAFT LDAP August 1996
3.2. Data Model

This section provides a brief introduction to the X.500 data model, as
used by LDAP.

The LDAP protocol assumes there is are one or more servers which jointly
provide access to a Directory Information Tree. The tree is made up of
entries. Entries have names: one or more values from the entry itself
form its relative distinguished name, which must be unique among all
its siblings. The concatenation of the relative distinguished names
of entries, starting from the line of entries from a particular entry to an immediate
subordinate of the unnamed root of the tree and continuing to a specific entry forms that entry's Distinguished
Name, which is unique in the tree. An example of a Distinguished Name is

CN=Steve Kille, O=ISODE Consortium, C=GB

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

Entries consist of a set of attributes. An attribute is a type with
one or more associated values. The attribute type, described identified by a
short descriptive name and an OID (object identifier), governs the
maximum number of values permissible for an attribute of that type
in an entry, and the syntax to which the values must conform. conform, the types
of matching which can be performed on values of that attribute, and
other functions.

An example of an attribute is "mail". There may be one or more values
of this attribute, and they must be IA5
strings.

All the attributes of an entry strings, and they are mastered together in a single
server. Shadow case
insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").

Some servers may hold cache or cached shadow copies of entries may entries, which can be held in other
servers,
used to answer search and comparison queries, but these cannot be updated directly by users. will return referrals
or contact other servers if modification operations are requested.

3.2.1 Attributes of Entries

Each entry must have an objectClass attribute. Values of this attribute
may be modified by clients, but the objectClass attribute cannot be
removed. The objectClass
attribute specifies the object classes of an entry, which along with
the system and user schema determine the permitted attributes of an entry.
Values of this attribute may be modified by clients, but the objectClass
attribute cannot be removed. Servers may restrict the modifications of
this attribute to prevent the basic structural class of the entry from
being changed (e.g. one cannot change a person into a country).

Servers should not permit clients to add attributes to an entry unless
those attributes are permitted by the object class definitions, the user
schema controlling that entry (specified in the subschema subentry), or
are operational attributes known to that server and used for
administrative purposes.

Entries may contain the following operational attributes, but if present
should not Note that there is a particular objectClass
'extensibleObject' defined in [5] which permits all user attributes.

Entries may contain, among others, the following operational attributes,
defined in [5], which if present should not be modifiable by clients:

- creatorsName: the string representation of the Distinguished Name of the user who added this entry
to the directory, if known. directory.
- createTimestamp: the GeneralizedTime value of the time this entry was added to the directory, if known. directory.
- modifiersName: the string representation of the Distinguished Name of the user who last modified
this entry, if known. entry.
- modifyTimestamp: the GeneralizedTime value of the time this entry was last modified, if known. modified.

Wahl, Howes, Kille [Page 3]

INTERNET-DRAFT LDAP August 1996
- subschemaSubentry: the string representation of the Distinguished Name of the subschema subentry
which controls the schema for this entry.
- entryName;binary: a DER encoding of entryName: the Distinguished Name of the entry.

Servers may implement other operational attributes. Servers which
also make use of X.500(1993) protocols should provide support
for the attributes defined in X.501, including administrativeRole,
collectiveExclusions, governingStructureRule, dseType administrativeRole and entryACI.
dseType. Some servers may permit the retrieval of subschema attributes
directly from user entries.

3.2.2 Subschema Subentry

A server may provide access to one or more subschema subentries to
permit clients to interrogate the schema which is in force for entries
in the directory.

A server which masters or shadows entries and permits clients to modify these
entries must implement and provide access to these subschema subentries,
so that its clients may discover the attributes and object classes which
are permitted to be present. It is strongly recommended that all other
servers implement subschema subentries. subentries as well.

The following two attributes four attributes, defined in [6] with string representations
in [5], must be present in a all subschema subentries:

- CN: this attribute should be used to form the RDN of the subschema
subentry.
- objectClass: the attribute should have at least the values "top" and
"subschema".
- objectClasses: each value of this attribute specifies an object class
known to the server.
- attributeTypes: each value of this attribute specifies an attribute
type known to the server.

Other operational attributes may be present in subschema subentries.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

These subentries,
in particular dseType, subtreeSpecification, ditStructureRules, nameForms,
ditContentRules, matchingRules, matchingRuleUse, createTimestamp,
creatorsName, modifyTimestamp, modifiersName, entryName, as described in
[6].

Clients must only retrieve these attributes of subschema subentries may be retrieved from a subentry by requesting
them by name in a baseObject search of their name, with filter set to a test for the
presence of the objectClass attribute. Clients should not expect that
subschema subentries will be returned in searches with other settings of
scope or filter. subentry.

3.3. Relationship to X.500

This document defines LDAP in terms of X.500 as an X.500 access
mechanism. An LDAP server should act in accordance with the
X.500(1993) series of ITU Recommendations when providing the service.
However, it is not required that an LDAP server make use of any X.500
protocols in providing this service, e.g. LDAP can be mapped onto any
other directory system so long as the X.500 data and service model as
used in LDAP is
supported not violated in the LDAP interface.

Wahl, Howes, Kille [Page 4]

INTERNET-DRAFT LDAP August 1996

3.4. Server-specific Data Requirements

An LDAP server must provide information about itself and other
information that is specific to each server. This is represented as a
number of attributes located in the root DSE (DSA-Specific Entry),
that
which is named with the zero-length LDAPDN. These attributes
should be retrievable if a client performs a base object search of the
root, however they are subject to access control restrictions.
They should not be included if the client performs a subtree search
starting from the root. The server may, but need not not, allow the client to
modify these attributes.

The following attributes of the root DSE are defined in section 5.1.3 of
[5]. Additional attributes may be defined by in later documents or by bilateral
agreement. These attributes are currently defined: documents.

- administratorAddress: This attribute's values are string a URL containing
the addresses address of the LDAP server's human administrator. This
information may be of use when tracking down problems in an Internet
distributed directory. For simplicity
- currentTime: the syntax of current time.
- serverName: the values are
limited to being URLs Distinguished Name of the mailto form with an RFC 822 address:
"mailto:user@domain". Future versions of this protocol may permit other
forms of addresses. server.
- currentTime: This attribute has a single value, a string containing a
GeneralizedTime character string. This attribute need only be present
if the server supports LDAP strong or protected simple authentication.
Otherwise if certificationPath: the server does not know server's certificate path.
- namingContexts: naming contexts held in the current time, or does not
choose to present it to clients, server.
- subschemaSubentry: subschema subentries known by this attribute need not be present. The
client may wish to use server.
- altServer: alternative servers in case this value to detect whether a strong or
protected bind one is failing because the client and server clocks are not
sufficiently synchronized. Clients should not use this time field for
setting their own system clock. later unavailable.
- serverName;binary: This attribute's value is the binary representation
of the ASN.1 DER encoding supportedExtension: list of the server's Distinguished Name. supported extensions.

If the server does not have a Distinguished Name it will not be able to accept
strong authentication, master or shadow entries and this attribute should be absent. However does not know the
presence
locations of this schema information, the subschemaSubentry attribute does should
not guarantee that the server will be
able to perform strong authentication. present in the root DSE. If the server acts as a gateway
to more than one X.500 DSA capable holds master or shadow
copies of strong authentication, directory entries under one or more schema rules, there may be multiple
any number of values of this attribute, one per DSA.

- certificationPath;binary: This the subschemaSubentry attribute contains a binary DER
encoding in the root DSE.

4. Elements of an AF.CertificationPath data type, which Protocol

The LDAP protocol is the certificate
path for described using Abstract Syntax Notation 1 [3]. It
is typically transferred using a server. If subset of the server does not have a certificate path Basic Encoding Rules.
In order to support future extensions to this
attribute protocol, clients and
servers should be absent.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

- namingContexts: The values of this attribute are the string
representations ignore elements of Distinguished Names. Each value corresponds SEQUENCEs whose tags they do not
recognize.

Note that unlike X.500, each change to a
naming context which this server masters or shadows. If the server does
not master any information (e.g. it is an LDAP gateway to protocol other than through
the extension mechanisms will have a public X.500
directory) this attribute should be absent. If different version number. A client
may indicate the server believes version it
contains supports as part of the entire directory, bind request,
described in section 4.1.2. If a client has not sent a bind, the attribute server
should have a single value,
and assume that value should be version 3 is supported in the empty string (indicating client (since version 2
required that the null DN of client bind first).

4.1. Common Elements

This section describes the
root).

- subschemaSubentry: The values of this attribute LDAPMessage envelope PDU format, as well as
data type definitions which are used in the string
representations protocol operations.

4.1.1. Message Envelope

For the purposes of Distinguished Names. Each value corresponds to protocol exchanges, all protocol operations are
encapsulated in a
subschema subentry, common envelope, the LDAPMessage, which is an entry in which the server makes
available attributes specifying defined
as follows:

Wahl, Howes, Kille [Page 5]

INTERNET-DRAFT LDAP August 1996
LDAPMessage ::= SEQUENCE {
messageID MessageID,
cldapUserName LDAPDN OPTIONAL,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
searchResFull SearchResultFull,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
sessionRequest SessionRequest,
sessionResponse SessionResponse,
resumeRequest ResumeRequest,
resumeError ResumeError,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse } }

MessageID ::= INTEGER (0 .. maxInt)

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

The function of the schema. (This LDAPMessage is described to provide an envelope containing
common fields required in
section 3.2.2). If the server does not master or shadow entries and
does not know the locations of schema information, all protocol exchanges. At this attribute should
be absent. If time the server holds all
only common fields are the directory under a single set of
schema rules, there will be one attribute message ID and cldapUserName.

The message ID value (and a single subentry,
which could must be located anywhere echoed in all LDAPMessage envelopes
encapsulating responses corresponding to the directory hierarchy). If request contained in
the
server holds master or shadow copies of directory entries under one or
more schema rules, there may be any number of values of this attribute.

- altLdapServer: The values of this attribute are URLs of other LDAP
servers LDAPMessage in which may be contacted when this server becomes unavailable. If the server does not know message ID value was originally used.

The message ID is required to have a value different from the values of
any other requests outstanding in the LDAP servers session of which could be used this attribute should be absent. Clients should cache this information
in case their preferred LDAP server later becomes unavailable.

- altX500Server: The values of this attribute are encoded
message is a part. A client must not send a second request with the
AccessPoint93 syntax. They are same
message ID as another request if the access points of X.500 DSAs which
could be contacted when this server becomes unavailable. first request is outstanding.
If this server it does not know of any X.500 DSAs this attribute should be absent.
Servers implemented as LDAP gateways to X.500 DAP may permit management
clients to modify so, the values of this attributes.

- supportedExtension: The values of this attribute are behavior is undefined. Typically a client will
increment a counter for each request.

For all requests except for a search with a pageSizeLimit, the string
representations of OBJECT IDENTIFIERs, in message ID
is outstanding until the dotted decimal form.
Each value client receives the final response for that
operation.

For searchRequest with a pageSize limit, if the client did not receive a
SearchResultDone for that search indicating all results were received,
the message ID is outstanding until after the name operation is abandoned.

Wahl, Howes, Kille [Page 6]

INTERNET-DRAFT LDAP August 1996

A client must not reuse the message id of an extended request which this server supports
(see section 4.11). If abandonRequest or the
abandoned operation until it has received a response from the server for
another request invoked subsequent to the abandonRequest, as the
abandonRequest itself does not support any extended
operations this attribute should be absent. have a response.

The ASN.1 type DistinguishedName is defined in [6], and cldapUserName identifies the type
CertificationPath requesting user for this message. It
is defined only present for backwards compatability with RFC 1798, if this
LDAPMessage is carried in [12].

4. Elements of Protocol

The a connectionless transport protocol, such as UDP.
Its significance is equivalent to a bind with a zero-length password.
When the LDAP protocol session is carried in a connection-oriented transport
protocol this field must be absent. LDAPv3 client implementors should not
use this field in connectionless requests, but instead concatenate a bind
request with the other operations in the request. Concatenation and
connectionless transport are described using Abstract Syntax Notation 1 [3]. It in section 5.1.3.

4.1.2. String Types

The LDAPString is typically transferred using a subset of the Basic Encoding Rules.
In order to support future extensions notational convenience to this protocol, clients and
servers should ignore elements indicate that, although
strings of SEQUENCEs whose tags they do not
recognize. LDAPString type encode as OCTET STRING types, the Unicode
[15] character set is used, encoded following the UTF-8 algorithm [16].
Note that unlike X.500, each change to in the LDAP protocol
will have a different version number.

4.1. Common Elements

This section describes UTF-8 algorithm, characters which are the LDAPMessage envelope PDU format, same as well
ASCII (0000 through 007F) are represented as
data type definitions which that same ASCII character
in a single byte. The other byte values are used in the protocol operations.

4.1.1. Message Envelope

For the purposes to form a variable-
length encoding of protocol exchanges, all protocol operations are
encapsulated in an arbitrary Unicode character.

LDAPString ::= OCTET STRING

The LDAPOID is a common envelope, notational convenience to indicate that the LDAPMessage, which permitted
value of this string is defined
as follows:

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

LDAPMessage a dotted-decimal representation of an OBJECT
IDENTIFIER.

LDAPOID ::= SEQUENCE {
messageID MessageID,
cldapUserName LDAPDN OPTIONAL,
protocolOp CHOICE {
bindRequest BindRequest,
bindReqContinue BindContinuationRequest,
bindRespBasic BindResponseBasic,
bindRespExtd BindResponseExtended,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
searchResFull SearchResultFull,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
resumeRequest ResumeRequest,
resumeError ResumeError,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse } }

MessageID ::= INTEGER (0 .. maxInt)

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

The function of the LDAPMessage is to provide an envelope containing
common fields required in all protocol exchanges. At this time the
only common fields are the message ID OCTET STRING

For example,
1.3.6.1.4.1.1466.1.2.3

4.1.3. Distinguished Name and Relative Distinguished Name

An LDAPDN and cldapUserName.

The message ID is required to have a value different from the values of
any other requests outstanding in RelativeLDAPDN are respectively defined to be the LDAP session
representation of which this
message is a part. Typically a client may increment Distinguished Name and a counter for each
request. The message ID value must be echoed in all LDAPMessage
envelopes encapsulating responses corresponding Relative Distinguished
Name after encoding according to the request
contained specification in the LDAPMessage [4], such that

<distinguished-name> ::= <name>

<relative-distinguished-name> ::= <name-component>

where <name> and <name-component> are as defined in which the message ID [4].

LDAPDN ::= LDAPString

RelativeLDAPDN ::= LDAPString

Wahl, Howes, Kille [Page 7]

INTERNET-DRAFT LDAP August 1996

4.1.4. Attribute Type and Description

An AttributeType takes on as its value was
originally used.

The cldapUserName identifies the requesting user for this message. It
is textual string associated
with that AttributeType in its specification. This string must begin
with a letter, and only present if contain ASCII letters and digit characters.
If this LDAPMessage is carried in a connectionless
transport protocol, such as UDP. This is described in section 5.1.3.
When the LDAP session is carried in a connection-oriented transport
protocol this field must be absent.

4.1.2. String Types

The LDAPString is a notational convenience to indicate that, although
strings of LDAPString type encode as OCTET STRING types, the legal
character set in such strings is defined to be the Basic Multilingual
Plane (BMP) of UCS. These are encoded following the UTF-8 algorithm.
Note that in the UTF-8 algorithm, characters which are the same as
printable ASCII (0020 through 007F) are represented as that same ASCII
character in a single byte.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

LDAPString ::= OCTET STRING

The LDAPOID is a notational convenince to indicate that the permitted
value of this string is a dotted-decimal representation of an OBJECT
IDENTIFIER.

LDAPOID ::= OCTET STRING

4.1.3. Distinguished Name and Relative Distinguished Name

An LDAPDN and a RelativeLDAPDN are respectively defined to be the
representation of a Distinguished Name and a Relative Distinguished
Name after encoding according to the specification in [4], such that

<distinguished-name> ::= <name>

<relative-distinguished-name> ::= <name-component>

where <name> and <name-component> are as defined in [4]. Only the single
line representation should be used, with comma as component separator.

LDAPDN ::= LDAPString

RelativeLDAPDN ::= LDAPString

4.1.4. Attribute Type and Description

An AttributeType takes on as its value the textual string associated
with that AttributeType in its specification. This string must begin
with a letter, and only contain ASCII letters and digit characters.
If this string string is not known, the AttributeType should take the ASCII
representation of its OBJECT IDENTIFIER, as decimal digits with
components separated by periods, e.g., "2.5.4.10". The attribute type
strings which must be supported are described used in section [5]. this version of LDAP are described in [5].

AttributeType ::= LDAPString

An AttributeDescription is a superset of the definition of the
AttributeType. It has the same ASN.1 definition, but allows additional
parameters
options to be specified.

AttributeDescription ::= LDAPString

A value of AttributeDescription is based on the following BNF:

<AttributeDescription> ::= <AttributeType> [ ";" <options> ]

<language-option> ::= "lang=" <lang-code>

<lang-code> ::= <printable-ascii> -- as defined in [17]

<binary-option> ::= "binary"

If the "binary" option is present, this overrides any printable string-based
encoding representation defined for that attribute. attribute in [5]. Instead the
attribute is to be transferred as a BER-encoded DER-encoded binary value. value [11].

If the "lang=" option is present, this associates a natural language
with values for that attribute. The binary and language tags may both
be present in an AttributeDescription. The format and use of language
tags in LDAP is defined in [17]. (The language tag has no effect on the
character set encoding for string representations of DirectoryString
syntax values; UTF-8 is always used).

Examples of valid AttributeDescription:

CN
givenName;lang=en-US
CN;lang=ja-JP-kanji
CN;lang=ja-JP-roman
userCertificate;binary
1.3.6.1.4.1.1466.99.98.97;binary

Wahl, Howes, Kille [Page 8]

INTERNET-DRAFT LDAP August 1996

The data type "AttributeDescriptionList" describes a list of 0 or more
attribute types. Clients and servers should be prepared to accept a (A list of many hundreds of attribute types. zero elements has special significance in
the Search request.)

AttributeDescriptionList ::= SEQUENCE SIZE (0..maxInt) OF
AttributeDescription

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

4.1.5. Attribute Value

A field of type AttributeValue takes on as its value either an octet string
encoding of a X.500 Directory AttributeValue type. data type, or an OCTET STRING containing
a DER-encoded binary value, depending on whether the "binary" option is
present in the companion AttributeDescription to this AttributeValue.

The definition of
these string encodings for different syntaxes and types may
be found in companions to this document, such as in particular [5].

AttributeValue ::= OCTET STRING

Note that there is no defined limit on the size of this encoding; thus
PDUs including multi-megabyte attributes (e.g. photographs) may be
returned. If the client has limited memory or storage capabilities it
may wish to set the attrSizeLimit field when session control before invoking a
search operation.

Clients and server implementors should be aware that attributes whose
type names they do not recognize may have an arbitrary and non-printable
syntax. Implementations should not either simply display or attempt to
decode as DER a value if its syntax is not known. The implementation
may attempt to discover the subschema subentry and retrieve the value of
attributeTypes from it.

4.1.6. Attribute Value Assertion

The AttributeValueAssertion type definition is similar to the one in
the X.500 directory standards. It contains an attribute type description
and a equality matching assertion suitable for that type.

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

AssertionValue ::= OCTET STRING

If the "binary" option is present in attributeDesc, this signals to the
server that the assertionValue is a binary DER encoding of the assertion
value.

For all the string-valued user attributes described in [5], the assertion
value syntax is the same as the value syntax. Note however that the
assertion syntax may be different than the value syntax for operational
attributes or for non-equality matching rules.

Wahl, Howes, Kille [Page 9]

INTERNET-DRAFT LDAP August 1996

4.1.7. Attribute

An attribute consists of a type and one or more values of that type.

Attribute
(Though attributes must have at least one value when stored, due to
access control restrictions the set may be empty when transferred
in protocol. This is described in section 4.5.2, concerning the
PartialAttributeList type.)

Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET SIZE (1..maxInt) OF AttributeValue }

4.1.8. Matching Rule Identifier

An X.501(1993) Matching Rule is identified in the LDAP protocol by the
ASCII representation of its OBJECT IDENTIFIER, either as one of the
strings given in [5], or as decimal digits with components separated by
periods, e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".

MatchingRuleId ::= LDAPOID LDAPString

4.1.9. Result Message

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

Wahl, Howes, Kille [Page 10]

INTERNET-DRAFT LDAP August 1996

LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
unableToProceed (13), -- new
-- 14-15 13-15 unused --
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
overSpecifiedFilter (22),
-- new
-- 23-31 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf (35), --
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),
resultsTooLarge (70), -- cl only
affectsMultipleDSAs (71), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL,
matchedSubtype [4] AttributeType OPTIONAL }

Wahl, Howes, Kille [Page 11]

INTERNET-DRAFT LDAP August 1996

The errorMessage field of this construct may, at the servers option,
be used to return an ASCII a string containing a textual, human-readable
error diagnostic. As this error diagnostic is not standardized,
implementations should not rely on the values returned. If the server
chooses not to return a textual diagnostic, the errorMessage field of
the LDAPResult type should contain a zero length string.

For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
isLeaf, invalidDNSyntax
and aliasDereferencingProblem, the matchedDN field is set to
the name of the lowest entry (object or alias) in the DIT that was
matched and is
matched. If no aliases were dereferenced while attempting to locate
the entry, this will be a truncated form of the name provided or, if an alias
has been dereferenced, of the resulting name in a Search or Compare
result. provided.
The matchedDN field should be set to a NULL DN (a zero length
string) in with all other cases.

When the resultCode is compareTrue the matchedSubtype field may contain
the type name of the attribute whose value matched the ava in the
Compare operation.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996 result codes.

4.1.10. Referral

The referral field is present in an LDAPResult if the
LDAPResult.resultCode field value is referral. referral, and absent with all other
result codes. It contains a reference to another server (or set of
servers) which may be accessed via LDAP or other protocols.
At least one LDAPURL must be present in the Reference.

Referral ::= SEQUENCE SIZE (1..maxInt) OF LDAPURL

LDAPURL ::= LDAPString -- limited to characters permitted in URLs

The referral contains a list client may contact any of the listed URLs [14] of servers, any of which the
client could contact servers to
continue the request. Each server in the list must be capable of
processing the operation and presenting a consistent view of the DIT to
the client. (The mechanisms for how servers achieve this are outside
the scope of this document.)

URLs for servers implementing the LDAP protocol are written according
to [9]; other kinds [9]. If an alias was dereferenced, the dn part of URLs may be returned so long as the same
information could URL should
be received using other protocols.

LDAPURL ::= LDAPString present, with the new target object name. If this is present,
the server has not information client should use this name in its next request, otherwise it
should use the same name as in the original request. Some servers
(e.g. participating in distributed indexing) may change the filter
in a referral for a search operation. If the filter part of where to progress the URL is
present in an LDAPURL, the client should use this filter in its next
request, otherwise it should use the same filter as it used for that
search.

Note that UTF-8 characters appearing in a DN or search filter may not
be legal for URLs (e.g. spaces) and must be escaped using the % method
in RFC 1738.

Other kinds of URLs may be returned so long as the operation could be
performed using that protocol, and the client has indicated (in a session
control) that it could return to support that protocol.

If the client, client has not indicated that it is capable of handling referrals,
the server should not attempt to progress the referral on behalf of the client.
Only if it fails to do so may it return a referral, but
instead return and the result code unableToProceed. URLs in this
referral must be of the LDAP form.

Wahl, Howes, Kille [Page 12]

INTERNET-DRAFT LDAP August 1996

4.2. Bind Operation

The function of the Bind Operation is to allow authentication information
to be exchanged between the client and server, and optionally allow
session-wide parameters to be set. server.

The Bind Request is defined as follows:

BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice,
serviceControls [7] Controls OPTIONAL AuthenticationChoice }

AuthenticationChoice ::= CHOICE {
simple [1] [0] OCTET STRING,
-- 2 1 and 3 2 reserved
protected [4] ProtectedPassword,
strong [5] StrongCredentials,
otherkind [6] OtherCredentials }

ProtectedPassword ::= SEQUENCE {
time1 [0] UTCTime OPTIONAL,
time2 [1] UTCTime OPTIONAL,
random1 [2] BIT STRING OPTIONAL,
random2
sasl [3] BIT STRING OPTIONAL,
protected [4] OCTET STRING }

StrongCredentials ::= SEQUENCE {
certification-path [0] AF.CertificationPath OPTIONAL,
bind-token [1] DAS.Token SaslCredentials }

OtherCredentials

SaslCredentials ::= SEQUENCE {
authMechanism [0] LDAPOID,
authToken [1]
mechanism LDAPString,
credentials OCTET STRING }

Controls ::= SEQUENCE OF SEQUENCE {
controlType LDAPString,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING }

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

Parameters of the Bind Request are:

- version: A version number indicating the version of the protocol to
be used in this protocol session. This document describes version
3 of the LDAP protocol. Note that there is no version negotiation,
and the client should just set this parameter to the version it
desires. The client may request version 2, in which case the server
should
must implement only the protocol as described in [2]. [2], and not
return any v3-specific result codes or protocol fields.

- name: The name of the directory object that the client wishes to
bind as. This field may take on a null value (a zero length
string) for the purposes of anonymous binds, or when authentication
has been performed at a lower layer. layer, or when using SASL credentials
with a mechanism that includes the LDAPDN in the credentials.

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

- serviceControls: additional requests the client may make about the
protocol.

Upon receipt of a Bind Request, a protocol server will authenticate
the requesting client client, if necessary, and attempt to set up a protocol
session with that client. necessary. The server will then return a
Bind Response to the client indicating the status of the session setup request. authentication.

4.2.1. Sequencing of the Bind Request

For some authentication mechanisms, it may be necessary for the client
to invoke the BindRequest multiple times. If at any stage the client
wishes to abort the bind process it should drop the underlying
connection. Clients must not invoke operations between two Bind requests
made as part of a multi-stage bind.

Wahl, Howes, Kille [Page 13]

INTERNET-DRAFT LDAP August 1996

Unlike LDAP v2, the client need not send a Bind Request in the first
PDU of the connection. The client may request any operations and the
server should treat these as unauthenticated (or authentication may have
already occured at a lower layer). If the server requires that the
client bind first, the server should reject any request other that than
binding or unbinding with the "operationsError" result. If the
client did not bind before sending a request and receives an
operationsError, it should close the connection, reopen it and begin
again by first sending a PDU with a Bind Request. This will aid in
interoperating with LDAPv2 servers.

Clients may send multiple bind requests on an association. association to change
their credentials. A subsequent bind process has the effect of abandoning
all search, compare and resume operations outstanding.
Authentication or controls from earlier binds are subsequently ignored, and
so if the bind fails, the connection will be treated as anonymous.
Clients should subequently resend their session controls if needed after rebinding,
as session controls may be
ignored.

4.2.1 reset to defaults by servers.

4.2.2 Authentication and Other Security Services

The simple authentication option provides minimal authentication
facilities, with the contents of the authentication field consisting
only of a cleartext password. Note that the use of cleartext passwords
is not recommended over open networks when there is no authentication or
encryption being performed by a lower layer; see the "Security
Considerations section".

If no authentication is to be performed, or has been performed at a
lower layer, then the simple authentication option should be chosen,
and the password be of zero length. (This is often done by LDAPv2
clients.)

The "simple" authentication option provides minimal authentication
facilities, sasl choice allows for any mechanism defined for use with SASL [18]
or listed in Appendix B to be used. The mechanism field contains the contents
name of the authentication field consisting
only of a cleartext password. mechanism. The ProtectedPassword authentication option allows a hash of credentials field contains the
password, combined optionally with arbitrary data
used for authentication, inside an OCTET STRING wrapper. Note that unlike
some Internet application protocols where SASL is used, LDAP is not
text-based, thus no base64 transformations are performed on the current time and a random
number, to be sent to credentials.

If any SASL-based integrity or confidentiality services are enabled, they
take effect following the DSA. The protected field contains transmission by the hash
value.

Strong authentication to server and reception by
the directory can be accomplished using client of the
strong credentials option. final BindResponse with resultCode success.

4.2.3. Bind Response

The ASN.1 type "CertificationPath" Bind Response is defined in [12], and as follows.

BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
supportedVersion [5] INTEGER (1..127) OPTIONAL,
serverURL [6] LDAPURL OPTIONAL,
serverCreds [7] AuthenticationChoice OPTIONAL }

A BindResponse consists simply of an indication from the ASN.1 type "Token" is defined in [13]. They
are included in Appendix B server of
the status of the client's request for reference. authentication.

Wahl, Howes, Kille [Page 14]

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June LDAP August 1996

Other kinds of authentication to

If the directory can bind was successful, the resultCode will be performed using success,
otherwise it will be one of:

operationsError
protocolError
authMethodNotSupported
strongAuthRequired
referral
inappropriateAuthentication
invalidCredentials
unavailable
unavailableCriticalExtension

If the other credentials option. The authMechanism must client receives a BindResponse response where the resultCode was
protocolError and the supportedVersion field is absent, it should close
the connection as the server will be unwilling to accept further
operations. (This is for compatability with earlier versions of LDAP.)

The serverURL contains the
dotted-decimal printable representation URL of this LDAP server, if it wishes to
provide an OBJECT IDENTIFIER of that
authentication mechanism: "authoritative" URL for interoperability the full decimal format
must itself. Typically this will be used. The authToken is arbitrary information of a form
defined by that authentication mechanism, encoded in an OCTET STRING.

4.2.1.1. Strong Credentials Signature Algorithm

It is recommended for interoperability that if strong authentication
is to be performed, then if
URL of the server's or client's certificates "ldap:" type, indicating the official host name, and the
name part of the URL will contain RSA public keys the PKCS md5WithRSAEncryption
(1.2.840.113549.1.1.4) algorithm should be used.

4.2.2. Service Controls

Service Controls encoded name of the server itself.
The serverCreds are requests made by used as part of a SASL-defined bind mechanism; to
allow the client to authenticate the server to which affect its
interaction it is communicating,
or to perform "challenge-response" authentication. If the client
bound with the server. Controls are not saved after a session
unbinds password choice, or disconnects abruptly, and do the SASL mechanism does not affect other sessions to
this or other servers.

If require
the server to return information to the client, then this field is not capable
to be included in the result.

The supportedVersion field contains the minimum of setting one or more requested controls,
it should set as many as possible. If any the version supplied
by the client in the BindRequest and the highest version of LDAP supported
in the controls which server. If the client and server could not set are marked as critical, both implement the protocol
described in this document it should return will have the
unavailableCriticalExtension error.

The controlType value 3. This field must either
should be absent when responding to a string defined in this section, version 2 or earlier client.

4.3. Unbind Operation

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

UnbindRequest ::= [APPLICATION 2] NULL

The Unbind Operation has no response defined. Upon transmission of an OBJECT IDENTIFIER. This will
aid in preventing conflicts between privately-defined control extensions.

The following controls have been defined:
- referringServer
- chainingProhibited
- supportedReferral
- useAliasOnUpdate
- manageDsaIT
- preferredLanguage

The referringServer control is always non-critical. The value field
contains
UnbindRequest, a protocol client may assume that the URL protocol session
is terminated. Upon receipt of another server which referred an operation to this
server. This control should only be present if the connection is being
made only to process UnbindRequest, a referral. If protocol server
may assume that the connection will be held open to
handle referrals from multiple servers this control should be omitted.

The chainingProhibited control requesting client has terminated the session and
that all outstanding requests may be critical or non-critical at discarded, and may close the
clients request. The value should
connection. All session controls will be an empty string. If present, forgotten and search result
caches will be cleared when a connection closes.

4.4. Session Control Operation

SessionRequest ::= [APPLICATION 17] Controls

SessionResponse ::= [APPLICATION 18] SEQUENCE {
COMPONENTS OF LDAPResult,
unsupportedCtls [12] SEQUENCE OF LDAPString }

Wahl, Howes, Kille [Page 15]

INTERNET-DRAFT LDAP August 1996

Controls ::= SEQUENCE OF SEQUENCE {
controlType LDAPString,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING }

Session Controls are requests made by the
server should client which affect its
interaction with the server. Controls are not contact any saved after a session
unbinds or disconnects abruptly, and do not affect other servers, if it would be possible to
instead return sessions to
this or other servers. Session controls do not affect operations which
have already been requested on this connection, e.g. if the client sends
a referral. If search request and subsequently sends a sessionControlRequest while the
server is a gateway to
X.500, it in the middle of sending responses, the session controls which
were in force when the search operation began should set continue to apply
for all the chainingProhibited service results of that search.

Session controls are not cumulative, and a session request will
override all session controls which were set by a previous request.
If a control was set on any
DAP/DSP requests it makes.

The supportedReferral control is always non-critical. The field is a string name of previous request and was not mentioned in
a protocol which subsequent request, it will be reset by the client implements. The name of server to its default
value. (This permits session controls, such as supportedProtocol, to
have multiple values.)

If the protocol may be "ldap", "cldap", "dap", or any IANA-assigned protocol
name server is not capable of setting one or URL mechanism. more requested controls,
it should set as many as possible. If this control is present, a any of the controls which the
server could not set are marked as critical, it should return the
unavailableCriticalExtension error.

The controlType field must either be a referral rather than chain to another server. string defined in this section,
or a dotted-decimal representation of an OBJECT IDENTIFIER. This will
aid in preventing conflicts between privately-defined control extensions.
String names are case insensitive.

The following controls have been defined:
- attrSizeLimit
- dontUseCopy
- usePartialCopy
- referringServer
- chainingProhibited
- supportedProtocol
- useAliasOnUpdate
- manageDsaIT
- preferredLanguage

The attrSizeLimit control may be critical or non-critical at the
clients client's
request. The value should be field contains either an empty string. If present, the
server should permit alias names to be used as components of string, implying no
limit, or a
Distinguished Name in Add, Modify and Delete operations. If the server
is string representation of a gateway to X.500, it should set the useAliasOnUpdate critical
extensions on any DAP/DSP AddEntry, ModifyEntry and RemoveEntry requests
it makes.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996 positive integer, e.g. "10000".
The manageDsaIT default if this control is always critical. The value should be an
empty string. If present, the chainingProhibited control must also be not present and critical. This control affects the name resolution behavior is that there is no limit.
The attrSizeLimit number is a size in bytes of the server to permit a manager to read and modify knowledge references
and other server-specific attributes. If largest encoded value
which the server client is capable of processing. Servers should not return
attribute values in a gateway to
X.500, it search response which are larger than this size.
(If attribute values are excluded because of this control, the
incompleteEntry field should be set to TRUE in the manageDsaIT SearchResultEntry).

The dontUseCopy control may be critical extension, as well as or non-critical at the
appropriate common arguments, on any DAP/DSP requests it makes. client's
request. The preferredLanguage value field contains either "TRUE" or "FALSE". To aid
interoperability with LDAPv2 clients, the default if this control is always non-critical. The value
not set is an
ISO 646 language code (such as "EN" for English). "FALSE". This control advises only affects the server what language should be used for returned attribute values Search and
error messages. It does not affect character sets; BMP is always used.

4.2.3. Bind Response Compare
operations.
Wahl, Howes, Kille [Page 16]

INTERNET-DRAFT LDAP August 1996

The Bind Response will usePartialCopy control may be one of critical or non-critical at the following, client's
request. The value field contains either
BindResponseBasic "TRUE" or BindResponseExtended.

BindResponseBasic ::= [APPLICATION 1] LDAPResult

A BindResponseBasic consists simply of an indication from the server of
the status of "FALSE". To aid
interoperability with LDAPv2 clients, the client's request for default if this control is
not set is "FALSE". This control only affects the initiation Search and Compare
operations when dontUseCopy is "FALSE". If present and set to "TRUE",
then if a contacted server holds at least one requested attribute or
at least one subtype of a protocol
session. If requested attribute type in an entry, that
entry may be used to satisfy the bind was successful, request, even if not all the resultCode will be success,
otherwise it will be one of:

operationsError
protocolError
authMethodNotSupported
strongAuthRequired
referral
inappropriateAuthentication
invalidCredentials
unavailable
unavailableCriticalExtension requested
attributes are in the shadowed copy. If FALSE the client receives server must not
return attributes from a BindResponseBasic response where shadow copy of an entry unless none of the
resultCode was not success, it should close
requested attributes were excluded from the connection as shadow copy. (How servers
replicate information and configure shadowing is outside the
server will be unwilling to accept further operations. scope of
this specification.)

The BindResponseExtended referringServer control is used to provide additional information
in the bind response, for either a successful or unsuccessfull
bind operation.

BindResponseExtended ::= [APPLICATION 17] SEQUENCE {
result [0] LDAPResult,
serverURL [1] LDAPURL OPTIONAL,
serverCreds [2] AuthenticationChoice OPTIONAL,
supportedExtns [3] SEQUENCE OF LDAPString,
unsupportedCtls [4] SEQUENCE OF LDAPString } always non-critical. The serverURL value field
contains the URL of another server which referred an operation to this LDAP
server. The serverCreds
allows This control should only be present if the client connection is being
made only to authenticate process a referral. If the server connection will be held open to which it
handle referrals from multiple servers this control should be omitted.
There is
communicating. The supportedExtns contains the names no protocol effect of service
controls and extended operations which this server supports. The
unsupportedCtls names the service controls which the client requested
but the server was not able to set.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

4.2.4 Bind Continuation

The BindContinuationRequest control; it is used when a "challenge-response" style
of authentication is to assist in
tracing knowledge inconsistencies in the distributed directory.

The chainingProhibited control may be performed. critical or non-critical at the
client's request. The client will initially send a
BindRequest, value should be either "TRUE" or "FALSE". To aid
interoperability with LDAPv2 clients, the default if this control is not
set is "FALSE". If this control is present and will receive a BindResponseExtended. The client may
then send a BindContinuationRequest set to supply additional information "TRUE", the
server should not contact any other servers as part of a single authentication process. The server will reply processing
operations requested by this client, if it would be possible to instead
return to the BindContinuationRequest with client a BindResponseExtended.

BindContinuationRequest ::= [APPLICATION 19] SEQUENCE {
otherkind [6] OtherCredentials }

4.3. Unbind Operation

The function of referral. If the Unbind Operation server is a gateway to terminate X.500,
and DAP is not a supported client referral protocol
session. (see next paragraph),
the server should set the chainingProhibited service control on any DAP
or DSP requests it makes.

The Unbind Operation supportedProtocol control is defined as follows:

UnbindRequest ::= [APPLICATION 2] NULL always non-critical. The Unbind Operation has no response defined. Upon transmission of an
UnbindRequest, a protocol client may assume that the protocol session field is terminated. Upon receipt
a string name of an UnbindRequest, a protocol server
may assume that which the requesting client has terminated implements. The name of
the session and
that all outstanding requests protocol may be discarded, and may close the
connection.

4.4. Search Operation

The Search Operation allows a client "ldap", "cldap", "dap", any IANA-assigned protocol
name or URL mechanism, or "*" to request indicate that any type of referral may
be returned. If this control is present, a search server should return a
referral, rather than itself chain to another server using one of the
indicated protocol. This control may be
performed on its behalf by present multiple times in a server. The Search Request
session control if the client wishes to name multiple protocols it
supports.

If the supportedProtocol control is defined as
follows:

SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList,
pageSizeLimit [0] INTEGER OPTIONAL,
sortKeys [1] SortKeyList OPTIONAL,
modifyRightsReq [3] BOOLEAN DEFAULT FALSE,
extraAttributes [4] BOOLEAN DEFAULT FALSE,
attrSizeLimit [5] INTEGER OPTIONAL,
subentries [6] BOOLEAN DEFAULT FALSE,
dontUseCopy [7] BOOLEAN DEFAULT FALSE,
usePartialCopy [8] BOOLEAN DEFAULT FALSE }

SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeType,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

Filter ::= CHOICE { absent and [0] SET OF Filter, the server is capable of
contacting other servers, then it should return not return results with
referrals, as described in 4.1.10, or [1] SET OF Filter, SearchResultContinuation, as
described in 4.5.3. If however the server is not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }

SubstringFilter ::= SEQUENCE { capable of contacting
other servers, it may return a referral or continuation containing a URL
of type AttributeType,
substrings SEQUENCE SIZE (1..maxInt) OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }

MatchingRuleAssertion ::= SEQUENCE {
matchingRules [1] SET SIZE (0..maxInt) OF MatchingRuleId,
type [2] AttributeType,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN }

Parameters of the Search Request are:

- baseObject: An LDAPDN that "LDAP".

It is recommended that clients, as a minimum, support LDAP referrals,
and set the base object entry relative to
which the search is supportedProtocol control to be performed.

- scope: An indicator of the scope of the search to "ldap".

Wahl, Howes, Kille [Page 17]

INTERNET-DRAFT LDAP August 1996

The useAliasOnUpdate control may be performed. critical or non-critical at the
client's request. The
semantics of value should be either "TRUE" or "FALSE". To
aid interoperability with LDAPv2 clients, the possible values of default if this field are identical control
is not set is "FALSE". If present and set to TRUE, the
semantics server should
permit alias names to be used as components of the scope field a Distinguished Name in
Add, Modify and Delete operations. If the directory Search Operation.

- derefAliases: An indicator as server is a gateway to how alias objects X.500,
it should set the useAliasOnUpdate critical extension on any DAP/DSP
AddEntry, ModifyEntry and RemoveEntry requests it makes if this
control is "TRUE".

The manageDsaIT control is always critical. The value should be
handled in searching. either
"TRUE" or "FALSE". The semantics of the possible values of default, if this field are:

neverDerefAliases: do control is not dereference aliases in searching
or in locating set, is "FALSE".
This control affects the base object name resolution behavior of the search;

derefInSearching: dereference aliases in subordinates of server to
permit a manager to read and modify knowledge references and other
X.500 server-specific attributes. If the base object in searching, but not in locating the
base object of the search;

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

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

- sizelimit: A sizelimit that restricts the maximum number of entries server is a gateway to be returned
X.500, it should set the manageDsaIT critical extension, as well as a result of the search. A value
appropriate common arguments, on any DAP/DSP requests it makes, based on
this control.

The preferredLanguage control is always non-critical. The use of 0 in this
field indicates that no sizelimit restrictions are in effect for
the search.

- timelimit: A timelimit that restricts
control and its impact on the maximum time (in seconds)
allowed for a search. A value of 0 directory is defined in [17]. The default
if this field indicates control is not set, is that there is no
timelimit restrictions are in effect for the search.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

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

4.5. Search Operation

The Search Operation allows a client to be returned.

- filter: A filter that defines the conditions request that must be fulfilled
in order for the a search to match be
performed on its behalf by a given entry. server.

4.5.1. Search Request

The and, or and not
choices may Search Request is defined as follows:

SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeType,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }

Wahl, Howes, Kille [Page 18]

INTERNET-DRAFT LDAP August 1996

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

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

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

Parameters of filters. the Search Request are:

- attributes: A list of baseObject: An LDAPDN that is the attributes from each base object entry found as a
result of relative to
which the search is to be returned. performed.

- scope: An empty list signifies that
all attributes from each entry found in indicator of the scope of the search are to be
returned.

- pageSizeLimit: if present and set to TRUE, then if more entries performed. The
semantics of the possible values of this field are identical to
be returned than the pageSizeLimit, the server should return only as
many as this limit before returning the SearchResultDone response.
It must cache all of the results for the lifetime of the association.
(The client will be able to request more
semantics of the entries using the
ResumeRequest, and the cached results can be cleared if the client
sends the Abandon operation for this search). If scope field in the same or fewer
entries than this limit are X.511 Search Operation.

- derefAliases: An indicator as to be returned, the server how alias objects should return
all the entries and the SearchResultDone response, and need not cache
the result. be
handled in searching. The pageSizeLimit does not affect SearchResultReference
responses, semantics of which any number may be returned by the server.

- sortKeys: If possible values of
this field is present, then it specifies one are:

neverDerefAliases: do not dereference aliases in searching
or more
attribute types and matching rules, and the returned entries should
be sorted in order based on these types. If locating the reverseOrder field is
set to TRUE, then base object of the entries will be presented search;

derefInSearching: dereference aliases in reverse sorted
order.

If subordinates of
the server does base object in searching, but not recognize any in locating the
base object of the attribute types, or search;

derefFindingBaseObject: dereference aliases in locating
the
ordering rule associated with an attribute type is base object of the search, but not applicable, or
none when searching
subordinates of the attributes base object;

derefAlways: dereference aliases both in searching and in
locating the search responses are base object of these types,
then the sortKeys field is ignored and result entries are returned
in random order. search.

- modifyRightsReq: If this field is set to TRUE and sizelimit: A sizelimit that restricts the scope field is
set maximum number of entries
to baseObject, then be returned as a result of the client requests search. A value of 0 in this
field indicates that the modification
rights no sizelimit restrictions are in effect for
the entry be included in search.

Wahl, Howes, Kille [Page 19]

INTERNET-DRAFT LDAP August 1996

- timelimit: A timelimit that restricts the search result. Support maximum time (in seconds)
allowed for a search. A value of 0 in this field is optional, and clients should expect indicates that not all
servers will implement returning modify rights. no
timelimit restrictions are in effect for the search.

- extraAttributes: If typesOnly: An indicator as to whether search results should contain
both attribute types and values, or just attribute types. Setting
this field is present and set to TRUE then
all operational attributes are requested causes only attribute types (no values) to be returned as well.
Note that specific operational attributes may instead be listed in
the attributes field. Servers are permitted to ignore extraAttributes
if returning this information is prohibited by security policy.
Clients should note that many operational attributes are not
modifiable.

- attrSizeLimit: If
returned. Setting this field is present, then if the size in bytes
of an to FALSE causes both attribute types
and all its values which would to be returned in a
result entry exceeds this size in bytes, then returned.

- filter: A filter that defines the attribute is not
included conditions that must be fulfilled
in order for the result and the incompleteEntry field is set search to TRUE.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

- subentries: if present match a given entry. The 'and', 'or' and set to TRUE, the server should ignore
ordinary
'not' choices may be used to form boolean combinations of filters. At
least one filter element must be present in an 'and' or 'or'
choice. The others match against individual attribute values of
entries and only perform in the search against subentries. If scope of the server not support subentries and search.

The extensibleMatch is new in this version of LDAP. If the
matchingRule field is TRUE it should
not do any searching, absent, the type field must be present, and return an empty result. (Note that if
the
LDAP equality match is backed by an X.500(1988) directory service, performed for that type. If the LDAP server may
receive a protocolError or unavailableCriticalExtension error, which
it should discard type field is
absent and instead return to matchingRule is present, the client matchValue is compared
against all attributes in an empty result.)

- dontUseCopy: if present entry which support that matchingRule,
and set to TRUE, only the server which holds matchingRule determines the master copy of syntax for the entry is permitted to perform assertion value.
If the filtering
and attribute selection.

- usePartialCopy: if type field is present and set to TRUE, if matchingRule is present, the server holds a
shadow copy of at least
matchingRule must be one attribute from a matching entry, it should permitted for use with that copy type.
If the dnAttributes field is set to satisfy TRUE, the search, even if not match is applied
against all the attributes
requested are present in the shadowed copy. an entry's distinguished name as
well. (Editors note: The results dnAttributes field is present so that there
does not need to be multiple versions of generic matching rules such as
wordMatch, one to apply to entries and another to apply to entries and
dn attributes as well).

- attributes: A list of the search attempted by attributes from each entry found as a
result of the server upon receipt of a
Search Request are returned in Search Responses, which are LDAP
messages containing either SearchResultEntry, SearchResultReference,
SearchResultDone or SearchResultFull data types.

SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN, search to be returned. An empty list signifies that
all user attributes PartialAttributeList,
modifyRights [2] BOOLEAN OPTIONAL,
incompleteEntry [3] BOOLEAN DEFAULT FALSE,
fromEntry [4] BOOLEAN DEFAULT FALSE,
thisEntryNumber [5] INTEGER OPTIONAL,
totalCount [6] INTEGER OPTIONAL }

PartialAttributeList ::= SEQUENCE SIZE (0..maxInt) OF SEQUENCE {
type AttributeDescription,
vals SET SIZE (0..maxInt) OF AttributeValue }

SearchResultReference ::= [APPLICATION 18] Referral

SearchResultDone ::= [APPLICATION 5] LDAPResult

SearchResultFull ::= SEQUENCE SIZE (1..maxInt) OF CHOICE { from each entry SearchResultEntry,
reference SearchResultReference,
resultCode SearchResultDone }

Upon receipt of a Search Request, a server will perform found in the necessary search of the DIT.

If the LDAP session is operating over a connection-oriented transport
such are to be
returned, as TCP, does the server will return to special attribute description string "*". (the
latter technique allows the client a sequence of
responses in separate LDAP messages. There may be zero or more
responses containing SearchResultEntry, one for each entry found
during to request all user attributes
along with selected operational attributes). If the search. There may also be zero or more responses
containing SearchResultReference, one for each area client does not explored by
this server during
want any attributes returned, it can request only the search. The SearchResultEntry and
SearchResultReferences may come attribute with
OID "1.1". Attributes should be named at most once in any order. Following all the
SearchResultReference responses list, and
are returned at most once in an entry.

Client implementors should note that even if all SearchResultEntry responses up
to a pageSizeLimit (if any), user attributes are
requested, some attributes of the server will entry may not be included in search
results due to access control restrictions. Furthermore, servers
will not return a response containing
the SearchResultDone, which contains an indication of success, operational attributes, such as modifyRights or
detailing any errors that have occurred.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

If the
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 session is operating over a connectionless transport such
as UDP, given in [5].)

- pageSizeLimit: if present, then if more entries are to be returned than
the pageSizeLimit, the server will should return to the client only one response, a
LDAPMessage containing a SearchResultFull data type. All if any but
the last element of as many as this limit
before returning the SEQUENCE OF SearchResultDone response. It must be cache all of
the SearchResultEntry
type, and the last must be of resulting entries from this search, at least until the SearchResultDone type.

The SearchResultFull next
(non-resume) operation is never returned over a connection-oriented
transport.

Each entry returned in a SearchResultEntry will contain invoked. The server may cache all attributes,
complete with associated values if necessary, the
results for as long as specified in the
attributes field lifetime of the Search Request. Return of attributes is subject
to access control and other administrative policy.

In a SearchResultEntry, as an encoding optimisation, association, although if
server resources are limited it may clear the value of cache after the
objectName next
(non-resume) operation is invoked.
Wahl, Howes, Kille [Page 20]

INTERNET-DRAFT LDAP DN may use August 1996

If a trailing '*' character to refer to the
baseObject of pageSizeLimit was set and reached during the corresponding searchRequest. For example, if search, the
baseObject is specified as "o=UofM, c=US", then client
will be able to request more of the following
objectName LDAPDNs in a response would have entries using the indicated meanings

objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"

If (and only if) ResumeRequest,
and the modifyRightsReq field was present in cached results can be cleared by the Search
Request may client sending the Abandon
operation for this search message id. If the same or fewer entries than
this limit are to be returned, the server also include should return all the ModifyRights field in entries
and the
entry. If present SearchResultDone response, and need not cache the result. The
pageSizeLimit does not affect SearchResultReference responses, of which
any number may be returned by the server.

If operating over connectionless data transport, the client must not
set to TRUE, this field.

- sortKeys: If this field is present, then the server suggests it is
likely that a valid modification operation specifies one or more
attribute types and matching rules, and the returned entries should
be sorted in order based on this entry would succeed. these types. If present and the reverseOrder field is
set to FALSE, TRUE, then it is likely the operation would
fail due to an authentication or access control restriction. entries will be presented in reverse sorted
order.

If no
information is available the server should does not include recognize any of the
modifyRights field in attribute types, or the response.

The incompleteEntry flag
ordering rule associated with an attribute type is set if one not applicable, or more
none of the attributes in the search responses are of these types,
then the sortKeys field is not
present used and result entries are returned
in random order.

If the PartialAttributeList, because their size would have
exceeded the attribute size limit, or if a partial shadow copy of the
entry was used to satisfy server does not support sorting with the request and some requested attributes are
not returned. It
or matching rules, then it must return only protocolError (which is never set just because typesOnly was set to TRUE.

The what
an LDAPv2 server may set would return), undefinedAttributeType or
inappropriateMatching and no searchResultEntry or
searchResultReference responses.

If the fromEntry field client includes the attribute type name 'modifyRights' in a SearchResult entry to TRUE
if it is known that the
search is not based upon request attribute type list when performing a shadow or cached
copy of the entry, but that the source of entry data has been directly
contacted.

If the pageSizeLimit control was present, baseObject search,
then the server must number should return the
entries which match modifyRights attribute as part of
the search. response attributes for that entry. The first entry returned will have
thisEntryNumber field contain the number 0, the next value of this attribute
is number 1, etc.
The server must also indicate a count described in section 6.2.2.1 of [5], and corresponds to the total number X.511(93)
ModifyRights field of entries in the field totalCount. The server may revise ReadResponse.

Note that an X.500 "list"-like operation can be emulated by the count, client
requesting a larger
totalCount field in one-level LDAP search operation with a later SearchResultEntry will override filter checking for
the
totalCount field existence of an earlier SearchResultEntry for the objectClass attribute, and that search.

If an X.500 "read"-like
operation can be emulated by a base object LDAP search operation with
the same filter. A server was able which provides a gateway to locate the entry referred X.500 is not
required to by use the
baseObject but was unable Read or List operations, although it may choose to search all
do so.

If the entries in search filter includes an equality match of the scope at objectClass
attribute and under the baseObject, value "subentry", then if the server may return one or more
SearchResultReference, each containing a reference is converting
to another LDAP
server for continuing the operation. The server should return at most
one SearchResultReference for a subtree. A server must not return a
SearchResultReference if it has not located the baseObject and thus has
not searched any entries; in this case it should return a
SearchResultDone containing a referral resultCode.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

Note that an X.500 "list" operation can be emulated by a one-level
LDAP search operation with a filter checking for protocol, the existence subentries service control should be set.

4.5.2. Search Result

The results of the
objectClass attribute, and that an X.500 "read" operation can be
emulated by a base object LDAP search operation with attempted by the same filter.

4.5. Resume Search Operation

The Resume server upon receipt of a
Search Operation is used Request are returned in conjunction with a Search
operation Responses, which was previously issued on this association.

ResumeRequest are LDAP
messages containing either SearchResultEntry, SearchResultReference,
SearchResultDone or SearchResultFull data types.

Wahl, Howes, Kille [Page 21]

INTERNET-DRAFT LDAP August 1996

SearchResultEntry ::= [APPLICATION 20] 4] SEQUENCE {
searchRequestID [0] MessageID,
startAtEntry [1] INTEGER OPTIONAL,
entriesToReturn [2] INTEGER OPTIONAL
objectName LDAPDN,
attributes PartialAttributeList }

The SearchRequest must have been made with the pageSizeLimit
field present, and

PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the server must not PartialAttributeList may have returned
-- zero elements (if none of the SearchResultDone
for this search, indicating attributes of that all the results have been returned entry were
-- requested, or
an error was encountered. A Search which has been abandoned cannot could be
resumed.

The searchRequestID field must contain the value of messageID which the
client used for returned), and that the original search operation.

The startAtEntry number vals set may be any number greater than 0, and also
-- have zero elements (if types only was requested, or all the sum values
-- exceeded the attribute size limit or were excluded because of
startAtEntry and entriesToReturn
-- access control).

SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must not be greater than the value of present

SearchResultDone ::= [APPLICATION 5] SEQUENCE {
COMPONENTS OF LDAPResult,
totalCount returned by the [8] INTEGER OPTIONAL }

SearchResultFull ::= SEQUENCE OF CHOICE {
entry SearchResultEntry,
reference SearchResultReference,
resultCode SearchResultDone }

Upon receipt of a Search Request, a server for this search. Note that the client
may request that will perform the server retransmit entries which it has already sent,
by setting a value necessary
search of startAtEntry smaller than the thisEntryNumber of DIT.

If the last entry which LDAP session is operating over a connection-oriented transport
such as TCP, the server has transmitted.

The server will respond return to the ResumeRequest with either a ResumeError,
or with client a series sequence of SearchResultEntry responses. The ResumeError is
only returned if
responses in separate LDAP messages. There may be zero or more
responses containing SearchResultEntry, one for each entry found
during the search. There may also be zero or more responses
containing SearchResultReference, one for each area not explored by
this server detected a problem with during the ResumeRequest,
such as an invalid searchRequestID. search. The SearchResultEntry and
SearchResultReferences may come in any order. Following all the
SearchResultReference responses
have and all SearchResultEntry responses up
to a pageSizeLimit (if any), the MessageID of server will return a response containing
the ResumeRequest, not SearchResultDone, which contains an indication of success, or
detailing any errors that have occurred.

If the original
SearchRequest.

ResumeError ::= [APPLICATION 21] LDAPResult

An example of using Resume LDAP session is as follows:

CLIENT SERVER

0,BindRequest
-->
0,BindResponse
<--

1,SearchRequest (pageSizeLimit=2)
-->
(search matches 5 entries)
1,SearchResultEntry (0 of 5)
<--
1,SearchResultEntry (1 of 5)
<--
1,SearchResultDone
<--

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
2,ResumeRequest (search id 1, start at 2, retrieve 3)
-->
2,SearchResultEntry (2 of 5)
<--
2,SearchResultEntry (3 of 5)
<--
2,SearchResultEntry (4 of 5)
<--

3,AbandonRequest (id 1)
-->
(search cache cleared)

4.6. Modify Operation

The Modify Operation allows operating over a connectionless transport such
as UDP, the server will return to the client only one response to request that the
search, an LDAPMessage containing a modification SearchResultFull data type. All (if
any) but the last element of the DIB be performed on its behalf by a server. The Modify
Request is defined as follows:

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }

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

Parameters must be of the Modify Request are:

- object: The object to
SearchResultEntry or SearchResultReference types, and the last must be modified. The value of this field should
name
the object to be modified. SearchResultDone type.

The server will not perform any
alias dereferencing SearchResultFull is never returned over a connection-oriented
transport.

Wahl, Howes, Kille [Page 22]

INTERNET-DRAFT LDAP August 1996

Each entry returned in a SearchResultEntry will contain all attributes,
complete with associated values if necessary, as specified in determining the object to be modified.

- A list
attributes field of modifications to be performed on the entry to be modified.
The entire list Search Request. Return of entry modifications should attributes is subject
to access control and other administrative policy. Some attributes may
be performed returned in DER-encoded binary format (indicated by the order they are listed, as
AttributeDescription in the response having the binary option present),
or in a single atomic operation. While
individual modifications may violate language-specific subtype (indicated by the directory schema, AttributeDescription
in the
resulting response having the language option present).

The following are not strictly attributes of an entry after (or a subentry),
but may appear in the entire result list of modifications if requested.

- entryName. This operational attribute is performed
must conform maintained by the server and
appears to be present in each entry. The value of this attribute
is the requirements distinguished name of the directory schema. The
values entry from which it is read. It
is expected that may be taken on by the 'operation' field client would retrieve this attribute in each
modification construct have binary.

- modifyRights. Each value is the following semantics respectively:

add: add values listed encoding of an element of modifyRights.
The attribute is specific to the given attribute, creating particular search operation and
the attribute requestor, and must not be cached or replicated.'

- incompleteEntry. This attribute's value is TRUE if necessary;

delete: delete values listed from one or more
attributes are not present in the given attribute,
removing PartialAttributeList, because their
size would have exceeded the entire attribute if no values are listed, size limit, or if all current values a partial
shadow copy of the attribute are listed for
deletion;

replace: replace existing values of entry was used to satisfy the given request and some
requested attributes are not returned. It is never set just because
typesOnly was set to TRUE, or because a requested attribute
with the new values listed, creating was not
present in the attribute if
necessary. A replace with no (master) entry.

- fromEntry. The server may return this attribute's value should delete as FALSE if it
is known that the entire
attribute.

The result search is based upon a shadow or cached copy of the modify attempted by
entry, and may return it as TRUE if the server upon receipt of a
Modify Request is returned in masters the entry.

In a Modify Response, defined SearchResultEntry, as follows:

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

ModifyResponse ::= [APPLICATION 7] LDAPResult

Upon receipt an encoding optimization, the value of a Modify Request, a server will perform the necessary
modifications
objectName LDAP DN may use a trailing '*' character to the DIB.

The server will return refer to the client a single Modify Response
indicating either the successful completion
baseObject of the DIB modification,
or the reason that corresponding searchRequest. For example, if the modification failed. Note that due to
baseObject is specified as "o=UofM, c=US", then the
requirement for atomicity following
objectName LDAPDNs in applying a response would have the list of modifications in indicated meanings

objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"

If the Modify Request, pageSizeLimit field was present, the client may expect that no modifications of server must number the DIB have been performed if
entries which match the Modify Response received indicates
any sort of error, search, and that all requested modifications have been
performed if must indicate the Modify Response indicates successful completion
total number of entries which match the Modify Operation.

4.7. Add Operation

The Add Operation allows a client to request search in the addition field totalCount
of an entry
into the directory. SearchResultDone. The Add Request is defined as follows:

AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList,
targetSystem [0] LDAPString OPTIONAL }

AttributeList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
type AttributeDescription,
vals SET SIZE (1..maxInt) OF AttributeValue }

Parameters of total count would either be the Add Request are:

- entry: same as
or greater than the Distinguished Name number of SearchResultEntry responses returned at
this time. If it is greater, then the entry to be added. Note that server did not return all components of the name except for
responses because the last RDN component pageSizeLimit was reached, and the server must
exist for
cache all the add to succeed. Note also that resulting entries. If it is the same, then the server will did
not
dereference any aliases in locating exceed the entry to be added, pageSizeLimit, and that
there are never any entries subordinate to an alias entry.

- attributes: the list of attributes that make up server need not cache the content of responses.

When the
entry being added.

- targetSystem: if present, search result exceeded the string representation of an
AccessPoint93, identifying pageSizeLimit, all matching entries
are cached (including those for which SearchResultEntry was returned),
and the server which should hold must not clear the target
entry. cache until an operation other than a
ResumeRequest for this search is received.
Wahl, Howes, Kille [Page 23]

INTERNET-DRAFT LDAP August 1996

4.5.3. Continuation References in the Search Result

If the server does not support was able to locate the targetSystem extension
it should return entry referred to by the error unavailableCriticalExtension.

The result of
baseObject but was unable to search all the add attempted by entries in the scope at
and under the baseObject, the server upon receipt of may return one or more
SearchResultReference, each containing a Add
Request is returned in the Add Response, defined as follows:

AddResponse ::= [APPLICATION 9] LDAPResult

Upon receipt reference to another set of an Add Request,
servers for continuing the operation. The server should return at most
one SearchResultReference for a new subordinate base object with a
particular scope and filter. A server will attempt to perform must not return a
SearchResultReference if it has not located the
add requested. baseObject and
thus has not searched any entries; in this case it should return a
SearchResultDone containing a referral resultCode.

The result SearchResultReference is of the add attempt will be returned to same data type as the
client Referral.
A URL in the Add Response.

4.8. Delete Operation

The Delete Operation allows a client to request SearchResultReference may only be included if the removal of an
entry from client has
indicated (in the directory. The Delete Request session controls) that it is defined as follows:

DelRequest ::= [APPLICATION 10] LDAPDN

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

The Delete Request consists of the Distinguished Name of the
entry able to be deleted. Note handle that
protocol. If the server will client has not dereference aliases
while resolving the name of indicated any protocols which the target entry
server could use to be removed.

The result of return in a SearchResultReference, the delete attempted by server must
itself process the entire search. If the server upon receipt of a
Delete Request is could not contact
all other servers, it may return one or more SearchResultReference for
unexplored subtrees, and must indicate also that only partial results were
returned by setting the resultCode in the Delete Response, defined as follows:

DelResponse ::= [APPLICATION 11] LDAPResult

Upon receipt of a Delete Request, a server will attempt SearchResultDone to perform be something
other than success, such as timeLimitExceeded.

URLs for servers implementing the entry removal requested. LDAP protocol are written according
to [9]. The result of the delete attempt will dn part must be
returned to the client present in the Delete Response. Note that only leaf
objects may be deleted URL, with this operation.

4.9. Modify DN Operation the new target
object name. The Modify DN Operation allows a client to must use this name in its next request.
Some servers (e.g. participating in distributed indexing) may change
the last component
of filter. If the name filter part of an entry the URL is present in an LDAP URL,
the directory, or to move a subtree of
entries to a new location client should use this filter in its next request, otherwise it
should use the directory. The Modify DN Request is
defined same filter as follows:

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

Parameters of the Modify DN Request are:

- entry: the name it used for that search.

Other kinds of the entry to URLs may be changed.

- newrdn: returned so long as the RDN operation could be
performed using that will form the last component of protocol, and the new name.

- deleteoldrdn: client has indicated (in a boolean parameter
session control) that controls whether the old RDN
attribute values should be retained as attributes of the entry or
deleted from the entry.

- newSuperior: if present, this it is the able to handle that protocol.

The name of another entry which
should be the superior of the an unexplored subtree in a SearchResultReference need not be
subordinate to the entry field.

The result base object if an alias was dereferenced, however it
should not be a prefix of the name change attempted by base object, otherwise the server upon receipt of
a Modify DN Request client will
loop. (Client implementations must detect loops; see section 6.2.)

Note: the "X.500 Non-Specific Subordinate Reference" is returned not permitted in
LDAP. Servers must not return multiple SearchResultReference for the Modify DN Response, defined
as follows:

ModifyDNResponse ::= [APPLICATION 13] LDAPResult

Upon receipt of a Modify RDN Request, a server will attempt to
perform the name change. The result same
subtree, and any one of (not all of) the name change attempt will servers listed in a
SearchResultReference may be returned contacted to perform the client entire search in a
particular subtree.

4.5.3.1 Example

For example, suppose the Modify DN Response. The attributes
that make up contacted server (hosta) holds the old RDN are deleted from entry
"O=MNN,C=WW" and the entry, entry "CN=Manager,O=MNN,C=WW". It knows that either
LDAP-capable servers (hostb) or kept,
depending on (hostc) hold "OU=People,O=MNN,C=WW" (one
is the setting of master and the deleteoldrdn parameter.

4.10. Compare Operation

The Compare Operation allows other server a client shadow), and that LDAP-capable
server (hostd) holds the subtree "OU=Roles,O=MNN,C=WW". If a subtree
search of "O=MNN,C=WW" is requested to compare an assertion
provided with an entry the contacted server in which
chainingProhibited is set and referrals are permitted, and the directory. The Compare Request filter is
defined as follows:

CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion,
dontUseCopy [1] BOOLEAN DEFAULT FALSE }

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

Parameters of
objectClass=*, the Compare Request are:

- entry: the name of server may return the entry to following responses:

Wahl, Howes, Kille [Page 24]

INTERNET-DRAFT LDAP August 1996

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 (entries = 2)

Client implementors should note that when following a
SearchResultReference, additional SearchResultReference may be compared with.

- ava: the assertion with which an attribute in
generated. Continuing the entry is to be
compared.

- dontUseCopy: example, if present and set to TRUE, only the server which holds the master copy of client contacted the entry is permitted to return
server (hostb) and issued the compareTrue
or compareFalse results.

The result of search for the compare attempted by subtree
"OU=People,O=MNN,C=WW", the server upon receipt of a
Compare Request is returned in the Compare Response, defined might respond as follows:

CompareResponse

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
}

4.6. Resume Search Operation

The Resume Search Operation is used in conjunction with a Search
operation which was previously issued on this association.

ResumeRequest ::= [APPLICATION 15] LDAPResult

Upon receipt of a Compare Request, a server will attempt to perform
the requested comparison. 20] SEQUENCE {
searchRequestID [0] MessageID,
startAtEntry [1] INTEGER,
entriesToReturn [2] INTEGER }

The result of the comparison will be
returned to the client in SearchRequest must have been made with the Compare Response. Note that errors pageSizeLimit
field present, and the result of comparison are all server must not have returned in all the same construct.

Note that some directory systems may establish access controls which
permit results
at the values of certain attributes (such as userPassword) to be
compared but not read.

4.11. Abandon Operation

The function time of the Abandon Operation is to allow search, or indicated a client to request
that resultCode in the server abandon an outstanding operation. The Abandon
Request
SearchResultDone other than success, timeLimitExceeded,
sizeLimitExceeded or adminLimitExcceded.

A Search which is defined as follows:

AbandonRequest ::= [APPLICATION 16] MessageID still in progress (the final SearchResultDone has not
been returned) or has been abandoned cannot be resumed.

The MessageID searchRequestID field must be that contain the value of a Search, Resume or Compare operation messageID which was requested earlier during this association. Other types the
client used for the original search operation.

Entries in a result are always numbered starting from 1.

The startAtEntry number may be any number greater than 0, and the sum of
operations cannot
startAtEntry and entriesToReturn must not be abandoned.

There is no response defined in greater than one plus the Abandon Operation. Upon
transmission
value of an Abandon Operation, a totalCount returned by the server for this search.

The client may expect request that the
operation identified by server retransmit entries which it had
already sent as responses for the Message ID in search, e.g. by setting startAtEntry
to "1" and entriesToReturn to be the Abandon Request has
been abandoned. In same as totalCount, all the event that a entries
will be transmitted.

Wahl, Howes, Kille [Page 25]

INTERNET-DRAFT LDAP August 1996

The server receives an Abandon
Request on will respond to the ResumeRequest with either a Search ResumeError,
or Resume Operation in the midst with a series of transmitting SearchResultEntry responses to and a SearchResultDone
response. The ResumeError is returned if the search, that server should cease transmitting entry
responses to the abandoned request immediately.

If the MessageID is for detected a Search operation in which pageSizeLimit was
set,
problem with the abandon will clear ResumeRequest, such as an invalid searchRequestID, or if
the results from server has cleared the server's cache.
Abandoning a Resume operation does not clear the cache.

4.11 Extended Operation

It may be desirable in some communities to define additional operations
for services not available in this protocol, for instance digitally
signed operations cache and cannot resume that search, or if
the Directory Information Tree has changed such that the search would no
longer return the same results. Thus an extension mechanism The extended operation allows clients to make requests SearchResultEntry and receive SearchResultDone
responses with bilaterally-defined syntaxes from a ResumeRequest have the Message ID of the ResumeRequest,
not of the original SearchRequest.

Any SearchResultReferences are returned at the the time of the original
search, and semantics.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

ExtendedRequest none returned by a resume operation.

ResumeError ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING }

The requestName 21] LDAPResult

An example of using Resume is a dotted-decimal representation as follows:

CLIENT SERVER

1,SearchRequest (pageSizeLimit=2)
-->
(search matches 5 entries)
1,SearchResultEntry (1 of the
OBJECT IDENTIFIER corresponding 5)
<--
1,SearchResultEntry (2 of 5)
<--
1,SearchResultDone (5)
<--

2,ResumeRequest (search id 1, startAtEntry 3, entriesToReturn 3)
-->
2,SearchResultEntry (3 of 5)
<--
2,SearchResultEntry (4 of 5)
<--
2,SearchResultEntry (5 of 5)
<--

<-- 2,SearchResultDone (5)

3,AbandonRequest (id 1)
-->
(search cache cleared)

4.7. Modify Operation

The Modify Operation allows a client to request that a modification
of the request. DIB be performed on its behalf by a server. The requestValue Modify
Request is information in a form defined by that request,
encapsulated inside an OCTET STRING.

The server will respond to this with an LDAPMessage containing the
ExtendedResponse.

ExtendedResponse as follows:

ModifyRequest ::= [APPLICATION 24] 6] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
response [1] OCTET STRING OPTIONAL,
standardResponse [2] LDAPResult
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues }

If the server does not recognize }
Wahl, Howes, Kille [Page 26]

INTERNET-DRAFT LDAP August 1996

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

Parameters of the operation name, it Modify Request are:

- object: The object to be modified. The value of this field should return
only the standardResponse field, containing the protocolError result
code.

5. Protocol Element Encodings and Transfer

For compatibility with
name the existing LDAP v2 and CLDAP protocols, four
underlying services are defined here. However an LDAP object to be modified. The server need will not
implement all of them.

5.1. Mapping Onto BER-based Transport Services

This protocol perform any
alias dereferencing in determining the object to be modified unless
the useAliasOnUpdate session control is designed set to run over connection-oriented, reliable
transports, with all 8 bits in an octet being significant in TRUE.

- A list of modifications to be performed on the data
stream. entry to be modified.
The protocol elements entire list of LDAP entry modifications should be performed
in the order they are encoded for exchange using listed, as a single atomic operation. While
individual modifications may violate the
Basic Encoding Rules (BER) [11] directory schema, the
resulting entry after the entire list of ASN.1 [3]. However, due modifications is performed
must conform to the
high overhead involved in using certain elements requirements of the BER, the
following additional restrictions are placed directory schema. The
values that may be taken on BER-encodings of LDAP
protocol elements:

(1) Only by the definite form of length encoding will be used.

(2) BIT STRINGs and OCTET STRINGs will be encoded 'operation' field in each
modification construct have the primitive form
only.

(3) If following semantics respectively:

add: add values listed to the given attribute, creating
the attribute if necessary;

delete: delete values listed from the given attribute,
removing the entire attribute if no values are listed, or
if all current values of the attribute are listed for
deletion;

replace: replace all existing values of the given attribute
with the new values listed, creating the attribute if it
did not already exist. A replace with no value should delete
the entire attribute.

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

ModifyResponse ::= [APPLICATION 7] LDAPResult

Upon receipt of a Modify Request, a server will perform the encoding should have
its contents octets set necessary
modifications to hex "FF".

(4) If the DIB.

The server will return to the client a value single Modify Response
indicating either the successful completion of a type is its default value, it should be absent.
Only some BOOLEAN and ENUMERATED types have default values in this
protocol definition.

If an implementation supports the protected DIB modification,
or strong authentication
elements then the following additional restrictions apply:

(5) UTC Times in reason that the protocol itself should be encoded with modification failed. Note that due to the "Z"
suffix, not as a local time. (This
requirement does not apply to
times in attribute values).

(6) Unused bits for atomicity in applying the final octet list of modifications in
the encoding of a BIT STRING
value, if there are any, should always be set to zero.

These restrictions do not apply to ASN.1 types encapsulated inside Modify Request, the client may expect that no modifications of
OCTET STRINGs, such as attribute values.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

5.1.1. Transmission Control Protocol (TCP)

The LDAPMessage PDUs are mapped directly onto
the TCP bytestream.
Server implementations running over DIB have been performed if the TCP should provide a protocol
listener on port 389.

5.1.2. Connection Oriented Transport Service (COTS)

The connection is established. No special use Modify Response received indicates
any sort of T-Connect is made.
Each LDAPMessage PDU error, and that all requested modifications have been
performed if the Modify Response indicates successful completion of
the Modify Operation. If the connection fails, whether the modification
occurred or not is mapped directly onto T-Data.

5.1.3. User Datagram Protocol (UDP)

The LDAPMessage PDUs are mapped directly onto UDP datagrams. Only
one request may be sent indeterminate.

Note that due to the simplifications made in LDAP, there is not a single datagram. Only one response may
be sent direct
mapping of the modifications in an LDAP ModifyRequest onto the
EntryModifications of a single datagram. Server a DAP ModifyEntry operation, and different
implementations running over of LDAP-DAP gateways may use different means of
representing the UDP should provide a protocol listener on port 389. change. The only final effect of the operations on the
entry will be identical.
Wahl, Howes, Kille [Page 27]

INTERNET-DRAFT LDAP August 1996

4.8. Add Operation

The Add Operation allows a client to request the addition of an entry
into the directory. The Add Request is defined as follows:

AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }

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

Parameters of the Add Request are:

- entry: the Distinguished Name of the entry to be added. Note that
all components of the name except for the last RDN component must
exist for the add to succeed. Note also that the server will not
dereference any aliases in locating the entry to be added (unless
the useAliasOnUpdate session control is TRUE), and that there are
never any entries subordinate to an alias entry.

- attributes: the list of attributes that make up the content of the
entry being added. Clients must included distinguished values in
this list.

The result of the add attempted by the server upon receipt of a Add
Request is returned in the Add Response, defined as follows:

AddResponse ::= [APPLICATION 9] LDAPResult

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.

4.9. Delete Operation

The Delete Operation allows a client to request the removal of an
entry from the directory. The Delete Request is defined as follows:

DelRequest ::= [APPLICATION 10] LDAPDN

The Delete Request consists of the Distinguished Name of the
entry to be deleted. Note that the server will not dereference aliases
while resolving the name of the target entry to be removed, unless
the useAliasOnUpdate session control is TRUE.

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

DelResponse ::= [APPLICATION 11] LDAPResult

Upon receipt of a Delete Request, a server will attempt to perform
the entry removal requested. The result of the delete attempt will be
returned to the client in the Delete Response. Note that only leaf
objects (with no subordinates) may be deleted with this operation.

Wahl, Howes, Kille [Page 28]

INTERNET-DRAFT LDAP August 1996

4.10. Modify DN Operation

The Modify DN Operation allows a client to change the last component
of the name of an entry in the directory, or to move a subtree of
entries to a new location in the directory. The Modify DN Request is
defined as follows:

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

Parameters of the Modify DN Request are:

- entry: the name of the entry to be changed.

- newrdn: the RDN that will form the last component of the new name.

- deleteoldrdn: a boolean parameter that controls whether the old RDN
attribute values should be retained as attributes of the entry or
deleted from the entry.

- newSuperior: if present, this is the name of the entry which
becomes the immediate superior of the existing entry.

The result of the name change attempted by the server upon receipt of
a Modify DN Request is returned in the Modify DN Response, defined
as follows:

ModifyDNResponse ::= [APPLICATION 13] LDAPResult

Upon receipt of a Modify RDN Request, a server will attempt to
perform the name change. The result of the name change attempt will
be returned to the client in the Modify DN Response. The attributes
that make up the old RDN are deleted from the entry, or kept,
depending on the setting of the deleteoldrdn parameter.

Note that X.500 restricts the ModifyDN operation to only affect entries
that are contained within a single server. If the LDAP server is mapped
onto DAP, then this restriction will apply, and the resultCode
affectsMultipleDSAs will be returned. In general clients should not
expect to be able to perform arbitrary movements of entries and subtrees.

4.11. Compare Operation

The Compare Operation allows a client to compare an assertion
provided with an entry in the directory. The Compare Request is
defined as follows:

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

Parameters of the Compare Request are:

- entry: the name of the entry to be compared with.

Wahl, Howes, Kille [Page 29]

INTERNET-DRAFT LDAP August 1996

- ava: the assertion with which an attribute in the entry is to be
compared.

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

CompareResponse ::= [APPLICATION 15] SEQUENCE {
COMPONENTS OF LDAPResult,
matchedSubtype [9] AttributeType OPTIONAL }

When the resultCode is compareTrue the matchedSubtype field is
permitted to contain the type name of the attribute whose value
matched the ava in the Compare operation. Servers which do not
implement attribute hierarchies will omit this element.

Upon receipt of a Compare Request, a server will attempt to perform
the requested comparison. The result of the comparison will be
returned to the client in the Compare Response. Note that errors and
the result of comparison are all returned in the same construct.

Note that some directory systems may establish access controls which
permit the values of certain attributes (such as userPassword) to be
compared but not read. In a search result, it may be that an attribute
of that type would be returned, but with an empty set of values.

4.12. Abandon Operation

The function of the Abandon Operation is to allow a client to request
that the server abandon an outstanding operation. The Abandon
Request is defined as follows:

AbandonRequest ::= [APPLICATION 16] MessageID

The MessageID must be that of a Search, Resume or Compare operation
which was requested earlier during this association. Other types of
operations cannot be abandoned.

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

There is no response defined in the Abandon Operation. Upon
transmission of an Abandon Operation, a client may expect that the
operation identified by the Message ID in the Abandon Request has
been abandoned. In the event that a server receives an Abandon
Request on a Search or Resume Operation in the midst of transmitting
responses to the search, that server should cease transmitting entry
responses to the abandoned request immediately. Of course, the server
must ensure that only properly encoded LDAPMessages are transmitted.

Clients must not send abandon requests for the same operation multiple
times. Servers must discard abandon requests for message ids it does
not recognize, for operations which cannot be abandoned, and for
operations which have already been abandoned.

Wahl, Howes, Kille [Page 30]

INTERNET-DRAFT LDAP August 1996

If the MessageID is for a Search operation in which pageSizeLimit was
set, the abandon will clear the results from the server's cache.
Abandoning a Resume operation does not clear the cache, it just stops
the server from sending responses.

4.13. Extended Operation

It may be desirable in some communities to define additional operations
for services not available in this protocol, for instance digitally
signed operations and results. Thus an extension mechanism has been
added in this version of LDAP.

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
operation should have a unique OBJECT IDENTIFIER assigned to it.

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING }

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

The server will respond to this with an LDAPMessage containing the
ExtendedResponse.

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

If the server does not recognize the operation name, it should return
only the standard response fields, containing the protocolError result
code.

5. Protocol Element Encodings and Transfer

For compatibility with the existing LDAP v2 and CLDAP protocols, four
underlying services are defined here. However an LDAP server need not
implement all of them.

5.1. Mapping Onto BER-based Transport Services

This protocol is designed to run over connection-oriented, reliable
transports, with all 8 bits in an octet being significant in the data
stream.

The protocol elements of LDAP are encoded for exchange using the
Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
high overhead involved in using certain elements of the BER, the
following additional restrictions are placed on BER-encodings of LDAP
protocol elements:

(1) Only the definite form of length encoding will be used.

Wahl, Howes, Kille [Page 31]

INTERNET-DRAFT LDAP August 1996

(2) BIT STRINGs and OCTET STRINGs will be encoded in the primitive form
only.

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

(4) If a value of a type is its default value, it should be absent.
Only some BOOLEAN and INTEGER types have default values in this
protocol definition.

These restrictions do not apply to ASN.1 types encapsulated inside of
OCTET STRINGs, such as attribute values, unless otherwise noted.

5.1.1. Transmission Control Protocol (TCP)

The LDAPMessage PDUs are mapped directly onto the TCP bytestream.
Server implementations running over the TCP should provide a protocol
listener on port 389.

5.1.2. Connection Oriented Transport Service (COTS)

The connection is established. No special use of T-Connect is made.
Each LDAPMessage PDU is mapped directly onto T-Data.

5.1.3. User Datagram Protocol (UDP)

The LDAPMessage PDUs are mapped directly onto UDP datagrams. A datagram
may contain one or more concatenated requests. Only one response datagram
is returned, containing all the responses concatenated together. The only
operations which the client may request are sessionRequest, searchRequest,
compareRequest and extendedReq. The server may return sessionResponse,
searchResFull, compareResponse and extendedResp. If any of the requests in
an incoming datagram generates an error (a result other than success,
compareTrue or compareFalse), the server should ignore any following
requests in that datagram.

Server implementations running over the UDP should provide a protocol
listener on port 389.

5.1.4. Secure Socket Layer over TCP (SSL)

LDAP is an application protocol which may be carried inside of an
Secure Sockets Layer connection [19]. After establishing the SSL
connection over TCP, the LDAPMessage PDUs are mapped directly onto
the bytestream. Server implementations running over SSL/TCP should
provide a protocol listener on port 636.

Note: it is expected that future versions of this document may reference
an IETF specification for equivalent security services, should one
become available.

Wahl, Howes, Kille [Page 32]

INTERNET-DRAFT LDAP August 1996

6. Implementation Guidelines

6.1. Server Implementations

The server should be capable of recognizing all the mandatory attribute
type names and implement the syntaxes specified in [5]. Servers may also
recognize additional attribute type names.

6.2. Client Implementations

For simple lookup applications using the connectionless transport
protocol UDP, use of a retry algorithm with multiple servers similar
to that commonly used in DNS stub resolver implementations is
recommended. The location of a CLDAP server or servers may be better
specified using IP addresses (simple or broadcast) rather than names
that must first be looked up in another directory such as DNS.

6.2.1. Loop Detection

Clients which request referrals should ensure that they do not loop
between servers. They must not progress a referral or reference in a
subtree search where the new name is a superior of the name requested.
They must not repeatedly contact the same server twice with the same
target entry name. Some clients may be using a counter that is
incremented each time referral handling is handled for an operation,
and these kind of clients must be able to handle a DIT with up to ten
layers of naming contexts between the root and a leaf entry.

7. Security Considerations

When used with a connection-oriented transport, this version of the
protocol provides facilities for the LDAP v2 authentication mechanism,
simple authentication using a cleartext password, as well as any SASL
mechanism [18].

It is also permitted that the server can return its credentials to the
client, if it chooses to do so.

This document also defines a mapping of LDAP over the Secure Sockets
Layer (SSL), which can provide strong authentication, integrity and
privacy of the connection.

Use of cleartext password is strongly discouraged where the underlying
transport service cannot guarantee confidentiality. A password hashing
mechanism is given in Appendix B.

When used with SASL, it should be noted that the name field of the
BindRequest is not protected against modification. Thus if there is a
client name (LDAPDN) agreed through the negotiation of the credentials,
it must take precedence over any value in the unprotected name field.

Wahl, Howes, Kille [Page 33]

INTERNET-DRAFT LDAP August 1996

When used with the connectionless transport, no security services are
available. There has been some discussion about the desirability of
authentication with connectionless LDAP requests. This might take the
form of a clear text password (which would go against the current IAB
drive to remove such things from protocols) or some arbitrary
credentials. It is felt that, in general, authentication would incur
sufficient overhead to negate the advantages of the connectionless
basis of LDAP. If an application requires authenticated access to the
directory then connectionless LDAP is not an appropriate protocol.

8. Acknowledgements

This document is an update to RFC 1777, by Wengyik Yeong, Tim
Howes, and Steve Kille. It also includes material from RFC 1798, by
Alan Young. Design ideas included in this document are based on those
discussed in ASID and other IETF Working Groups. The contributions of
individuals in these working groups is gratefully acknowledged.

9. Bibliography

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

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

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

[4] S. Kille, M. Wahl, "A UTF-8 String Representation of Distinguished
Names", INTERNET-DRAFT <draft-ietf-asid-ldapv3-dn-00.txt>.
August 1996.

[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
"Lightweight X.500 Directory Access Protocol Standard and Pilot
Attribute Definitions", INTERNET-DRAFT
<draft-ietf-asid-ldapv3-attributes-02.txt>, August 1996.

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

[7] ITU-T Rec. X.520, "The Directory: Selected Attribute Types", 1993.

[9] T. Howes, M. Smith, "An LDAP URL Format", RFC 1959, June 1996.

[10] ITU-T Rec. X.518, "The Directory: Procedures for Distributed
Operation", 1993.

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

[12] ITU-T Rec. X.509, "The Directory: Authentication Framework",
1993.

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

[14] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, Dec. 1994.

Wahl, Howes, Kille [Page 34]

INTERNET-DRAFT LDAP August 1996

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

[16] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.

[17] M. Wahl, T. Howes, "LDAP Use of Language Indications",
INTERNET-DRAFT <draft-ietf-asid-ldapv3-lang-00.txt"> August 1996.

[18] J. Meyers, "Simple Authentication and Security Layer",
INTERNET-DRAFT <draft-myers-auth-sasl-04.txt>, July 1996.

[19] A. Freier, P. Karlton, P. Kocher, "The SSL Protocol Version 3.0",
INTERNET-DRAFT <draft-freier-ssl-version3-01.txt>, March 1996.

10. Authors' Address

Mark Wahl
Critical Angle Inc.
4815 W Braker Lane #502-385
Austin, TX 78759
USA

EMail: M.Wahl@critical-angle.com

Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA

Phone: +1 415 254-1900
EMail: howes@netscape.com

Steve Kille
ISODE Consortium
The Dome, The Square
Richmond
TW9 1DT
UK

Phone: +44-181-332-9091
EMail: S.Kille@isode.com

Appendix A - Complete ASN.1 Definition

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

BEGIN

Wahl, Howes, Kille [Page 35]

INTERNET-DRAFT LDAP August 1996

LDAPMessage ::= SEQUENCE {
messageID MessageID,
cldapUserName LDAPDN OPTIONAL,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
searchResFull SearchResultFull,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
sessionRequest SessionRequest,
sessionResponse SessionResponse,
resumeRequest ResumeRequest,
resumeError ResumeError,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse } }

MessageID ::= INTEGER (0 .. maxInt)

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

LDAPString ::= OCTET STRING

LDAPOID ::= OCTET STRING

LDAPDN ::= LDAPString

RelativeLDAPDN ::= LDAPString

AttributeType ::= LDAPString

AttributeDescription ::= LDAPString

AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription

AttributeValue ::= OCTET STRING

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

AssertionValue ::= OCTET STRING

Wahl, Howes, Kille [Page 36]

INTERNET-DRAFT LDAP August 1996

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

MatchingRuleId ::= LDAPString

LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),

authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
-- 13-15 unused --
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),
resultsTooLarge (70), -- cl only
affectsMultipleDSAs (71), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
Wahl, Howes, Kille [Page 37]

INTERNET-DRAFT LDAP August 1996

Referral ::= SEQUENCE OF LDAPURL

LDAPURL ::= LDAPString -- limited to characters permitted in URLs

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

AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }

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

BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
supportedVersion [5] INTEGER (1..127) OPTIONAL,
serverURL [6] LDAPURL OPTIONAL,
serverCreds [7] AuthenticationChoice OPTIONAL }

UnbindRequest ::= [APPLICATION 2] NULL

SessionRequest ::= [APPLICATION 17] Controls

SessionResponse ::= [APPLICATION 18] SEQUENCE {
COMPONENTS OF LDAPResult,
unsupportedCtls [12] SEQUENCE OF LDAPString }

Controls ::= SEQUENCE OF SEQUENCE {
controlType LDAPString,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING }

Wahl, Howes, Kille [Page 38]

INTERNET-DRAFT LDAP August 1996

SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeType,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }

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

MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeType 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 }
-- implementors should note that the PartialAttributeList may have
-- zero elements (if none of the attributes of that entry were
-- requested, or could be returned), and that the vals set may also
-- have zero elements (if types only was requested, or all the values
-- exceeded the attribute size limit or were excluded because of
-- access control).

SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present

SearchResultDone ::= [APPLICATION 5] SEQUENCE {
COMPONENTS OF LDAPResult,
totalCount [8] INTEGER OPTIONAL }

SearchResultFull ::= SEQUENCE OF CHOICE {
entry SearchResultEntry,
reference SearchResultReference,
resultCode SearchResultDone }

Wahl, Howes, Kille [Page 39]

INTERNET-DRAFT LDAP August 1996

ResumeRequest ::= [APPLICATION 20] SEQUENCE {
searchRequestID [0] MessageID,
startAtEntry [1] INTEGER,
entriesToReturn [2] INTEGER }

ResumeError ::= [APPLICATION 21] LDAPResult

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

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

ModifyResponse ::= [APPLICATION 7] LDAPResult

AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }

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

AddResponse ::= [APPLICATION 9] LDAPResult

DelRequest ::= [APPLICATION 10] LDAPDN

DelResponse ::= [APPLICATION 11] LDAPResult

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

ModifyDNResponse ::= [APPLICATION 13] LDAPResult

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

CompareResponse ::= [APPLICATION 15] SEQUENCE {
COMPONENTS OF LDAPResult,
matchedSubtype [9] AttributeType OPTIONAL }

AbandonRequest ::= [APPLICATION 16] MessageID

Wahl, Howes, Kille [Page 40]

INTERNET-DRAFT LDAP August 1996

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING }

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

-- not part of LDAP core protocol, see Appendix B --

ProtectedPassword ::= SEQUENCE {
time1 [0] UTCTime OPTIONAL,
time2 [1] UTCTime OPTIONAL,
random1 [2] BIT STRING OPTIONAL,
random2 [3] BIT STRING OPTIONAL,
protected [4] OCTET STRING }

StrongCredentials ::= SEQUENCE {
certification-path [0] AF.CertificationPath OPTIONAL,
bind-token [1] DAS.Token }

END

Appendix B - X.500 Authentication Mechanisms

This Appendix defines two SASL authentication mechanisms which the client may request are searchRequest and
abandonRequest. The server may only respond
be used with the searchResultFull.

5.1.4. Secure Socket Layer over TCP (SSL)

After establishing the SSL connection over TCP, the LDAPMessage PDUs LDAP. These mechanisms are mapped directly onto the bytestream. Server implementations
running over SSL/TCP should provide a protocol listener only for authentication, they
have no effect on port TBD.

6. Implementation Guidelines

6.1. Server Implementations

The server should be capable of recognizing all the mandatory attribute
type names and implement the syntaxes specified in [5]. Servers may also
recognize additional attribute type names.

6.2. Client Implementations

For simple lookup applications using the connectionless transport protocol UDP, use of a retry algorithm with multiple servers similar encodings and are not designed to that commonly used in DNS stub resolver implementations is
recommended. The location of a CLDAP server or servers may be better
specified using IP addresses (simple
provide integrity or broadcast) rather than names
that must first confidentiality services.

If an implementation supports these elements, then the following
additional encoding restrictions apply tor these elements:

(5) UTC Times should be looked up in another directory such as DNS.

7. Security Considerations

When used encoded with a connection-oriented transport, this version of the
protocol provides facilities for the LDAP v2 authentication mechanism:
simple authentication using a cleartext password. It also provides for
two other authentication mechanisms "Z" suffix, not as described a local time.

(6) Unused bits in X.511: transfer the final octet of the encoding of a BIT STRING
value, if there are any, should always be set to zero.

B.1. X.511-Protected

The "X.511-Protected" authentication mechanism allows a hash of the client's
password, combined optionally with the current time and strong authentication based on random
numbers, to be sent to the
private key of server. The protected field contains the client. It hash
value. This prevents a password from being carried in the clear.

The mechanism field is also permitted that set to the string "X.511-Protected", and the server can
return its
credentials to field contain the client.

This document also defines DER encoding of a mapping value of the following
ASN.1 type:

ProtectedPassword ::= SEQUENCE {
time1 [0] UTCTime OPTIONAL,
time2 [1] UTCTime OPTIONAL,
random1 [2] BIT STRING OPTIONAL,
random2 [3] BIT STRING OPTIONAL,
protected [4] OCTET STRING }
Wahl, Howes, Kille [Page 41]

INTERNET-DRAFT LDAP over August 1996

The use of the Secure Sockets
Layer (SSL), which can provide strong authentication, integrity time1, time2, random1, random2 and protected fields are
as defined in ITU-T Rec. X.509 [12] and
privacy of the connection.

Use of cleartext password functional profile for X.500
for the environment in which this authentication mechanism is strongly discouraged where to be used.

The name field of the underlying
transport service cannot guarantee confidentiality.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

When BindRequest must be a nonempty string when this
mechanism is being used with to authenticate the connectionless transport, no client. Note that this
security services are
available. There has been some discussion about mechanism is not intended to protect against attackers
modifying the desirability of bind name field or other protocol elements.

B.2. X.511-Strong

Strong authentication with connectionless LDAP requests. This might take to the directory can be accomplished using the
form
"X.511-Strong".

The mechanism field is set to the string "X.511-Strong", and the
credentials field set to a DER-encoding of a clear text password (which would go against value of the current IAB
drive to remove such things from protocols) or some arbitrary
credentials. It following
ASN.1 type:

StrongCredentials ::= SEQUENCE {
certification-path [0] AF.CertificationPath OPTIONAL,
bind-token [1] DAS.Token }

The ASN.1 type "CertificationPath" is felt that, defined in general, authentication would incur
sufficient overhead to negate [12], and the advantages of ASN.1
type "Token" is defined in [13].

When the connectionless
basis of CLDAP. If an application requires authenticated access credentials are being used to authenticate the
directory then CLDAP client, it is not an appropriate protocol.

8. Acknowledgements

This document
recommended that the certification-path field be present, which will
contain minimally the client's certificate. If the certification-path
field is supplied, then the name field of the BindRequest must be an update to RFC 1777, by Wengyik Yeong, Tim
Howes,
empty string, and Steve Kille. It also includes material the server will obtain the name of the client from RFC 1798, by
Alan Young. Design ideas included in this document are based on those
discussed in ASID and other IETF Working Groups.

9. Bibliography

[1] The Directory: Overview
the subject field of Concepts, Models and Service. ITU-T
Recommendation X.500, 1993.

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

[3] Abstract Syntax Notation One (ASN.1) - Specification the certification-path userCertificate.

It is recommended for interoperability that if the server's or client's
certificates contain RSA public keys, the PKCS md5WithRSAEncryption
(1.2.840.113549.1.1.4) algorithm should be used.

Table of Basic
Notation. ITU-T Recommendation X.680, 1994.

[4] S. Kille, "A String Representation Contents

1. Status of this Memo .................................... 1
2. Abstract ............................................... 1
3. Models ................................................. 2
3.1. Protocol Model ........................................ 2
3.2. Data Model ............................................ 3
3.2.1 Attributes of Distinguished Names", RFC
1779, March 1995.

[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
"Lightweight Entries ................................ 3
3.2.2 Subschema Subentry ................................... 4
3.3. Relationship to X.500 Directory Access ................................. 4
3.4. Server-specific Data Requirements ..................... 5
4. Elements of Protocol Standard ................................... 5
4.1. Common Elements ....................................... 5
4.1.1. Message Envelope .................................... 5
4.1.2. String Types ........................................ 7
4.1.3. Distinguished Name and Pilot Relative Distinguished Name .. 7
4.1.4. Attribute Definitions", <draft-ietf-asid-ldapv3-attributes-03.txt>,
May 1996.

[6] The Directory: Models. ITU-T Recommendation X.501, 1993.

[7] The Directory: Selected Type and Description ...................... 8
4.1.5. Attribute Types. ITU-T Recommendation
X.520, 1993.

[9] T. Value ..................................... 9
4.1.6. Attribute Value Assertion ........................... 9
4.1.7. Attribute ........................................... 10
4.1.8. Matching Rule Identifier ............................ 10
4.1.9. Result Message ...................................... 10
Wahl, Howes, M. Smith, An Kille [Page 42]

INTERNET-DRAFT LDAP URL Format, December 1995,
<draft-ietf-asid-ldap-format-03.txt>

[10] The Directory: Procedures for Distributed Operation. ITU-T
Recommendation X.518, 1993.

[11] Specification August 1996

4.1.10. Referral ........................................... 12
4.2. Bind Operation ....................................... 13
4.2.1. Sequencing of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules. ITU-T Recommendation X.690, 1994.

[12] The Directory: the Bind Request ...................... 13
4.2.2 Authentication Framework. ITU-T Recommendation
X.509, 1993.

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

[14] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, Dec. 1994.

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

INTERNET-DRAFT Lightweight Directory Access Other Security Services ........... 14
4.2.3. Bind Response ....................................... 14
4.3. Unbind Operation ..................................... 15
4.4. Session Control Operation ............................ 15
4.5. Search Operation ..................................... 18
4.5.1. Search Request ...................................... 18
4.5.2. Search Result ....................................... 21
4.5.3. Continuation References in the Search Result ........ 24
4.5.3.1 Example ............................................ 24
4.6. Resume Search Operation .............................. 25
4.7. Modify Operation ..................................... 26
4.8. Add Operation ........................................ 28
4.9. Delete Operation ..................................... 28
4.10. Modify DN Operation ................................. 29
4.11. Compare Operation ................................... 29
4.12. Abandon Operation ................................... 30
4.13. Extended Operation .................................. 31
5. Protocol Element Encodings and Transfer ................ 31
5.1. Mapping Onto BER-based Transport Services ............ 31
5.1.1. Transmission Control Protocol (v3) June 1996

[16] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1. (TCP) ................ 32
5.1.2. Connection Oriented Transport Service (COTS) ....... 32
5.1.3. User Datagram Protocol (UDP) ....................... 32
5.1.4. Secure Socket Layer over TCP (SSL) ................. 32
6. Implementation Guidelines .............................. 32
6.1. Server Implementations ............................... 32
6.2. Client Implementations ............................... 32
6.2.1. Loop Detection ...................................... 32
7. Security Considerations ................................ 33
8. Acknowledgements ....................................... 34
9. Bibliography ........................................... 34
10. Authors' Address

Mark Wahl
ISODE Consortium Inc.
3925 West Braker Lane, Suite 333
Austin, TX 78759
USA

Phone: +1 512-305-0280
EMail: M.Wahl@isode.com

Tim Howes
Netscape Communications Corp.
685 Middlefield
Mountain View, CA 94043
USA

Phone: +1 415 254-1900
EMail: howes@netscape.com

Steve Kille
ISODE Consortium
The Dome, The Square
Richmond
TW9 1DT
UK

Phone: +44-181-332-9091
EMail: S.Kille@isode.com ...................................... 35
Appendix A - Complete ASN.1 Definition

In the IMPORTS statement the "AF" module refers to X.509(1993),
and the "DAS" module to X.511(1993).

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

BEGIN

IMPORTS CertificationPath FROM AF
Token FROM DAS;

--- to be provided ---

END ..................... 35
Appendix B - Imported ASN.1 Definitions

Note that the types described here are distinct from those defined in
the body of this document. X.500 Authentication Mechanisms ............... 41
B.1. Types from X.509(1993) "Authentication Framework"

The type "Certificate" is defined in X.509(1993). It it strongly
recommended that clients and server implementations which support
certificates implement the draft addendums to X.509 which provide
certificate extensions.

INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996

AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY OPTIONAL }

CertificatePair ::= SEQUENCE {
forward [0] Certificate OPTIONAL,
reverse [1] Certificate OPTIONAL
-- at least one of the pair shall be present -- }

CertificationPath ::= SEQUENCE {
userCertificate Certificate,
theCACertificates SEQUENCE OF CertificatePair
OPTIONAL } X.511-Protected ....................................... 41
B.2. Types from X.511(1993) "Directory Abstract Syntax"

The type "DistinguishedName" is defined in X.501(1993). It is the
ASN.1 encoding, not a string encoding.

Token ::= SIGNED { SEQUENCE {
algorithm [0] AlgorithmIdentifier,
name [1] DistinguishedName,
time [2] UTCTime,
random [3] BIT STRING } }

<draft-ietf-asid-ldapv3-protocol-01.txt> X.511-Strong .......................................... 42

<draft-ietf-asid-ldapv3-protocol-02.txt> Expires: December 5, 1996
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996 March 2, 1997

Wahl, Howes, Kille [Page 43]

----