draft-ietf-ldapbis-protocol-21.txt   draft-ietf-ldapbis-protocol-22.txt 
Internet-Draft Editor: J. Sermersheim Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc Intended Category: Standard Track Novell, Inc
Document: draft-ietf-ldapbis-protocol-21.txt Jan 2004 Document: draft-ietf-ldapbis-protocol-22.txt Feb 2004
Obsoletes: RFC 2251, 2830, [LIMR] Obsoletes: RFC 2251, 2830, [LIMR]
LDAP: The Protocol LDAP: The Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 50 skipping to change at line 50
Protocol (DAP). Protocol (DAP).
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
1.1. Relationship to Obsolete Specifications.......................3 1.1. Relationship to Obsolete Specifications.......................3
2. Conventions.....................................................3 2. Conventions.....................................................3
3. Protocol Model..................................................3 3. Protocol Model..................................................3
4. Elements of Protocol............................................4 4. Elements of Protocol............................................4
4.1. Common Elements...............................................4 4.1. Common Elements...............................................4
4.1.1. Message Envelope............................................4 4.1.1. Message Envelope............................................5
4.1.2. String Types................................................6 4.1.2. String Types................................................6
Sermersheim Internet-Draft - Expires Jul 2004 Page 1 Sermersheim Internet-Draft - Expires Aug 2004 Page 1
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
4.1.3. Distinguished Name and Relative Distinguished Name..........6 4.1.3. Distinguished Name and Relative Distinguished Name..........6
4.1.4. Attribute Descriptions......................................7 4.1.4. Attribute Descriptions......................................7
4.1.5. Attribute Value.............................................7 4.1.5. Attribute Value.............................................7
4.1.6. Attribute Value Assertion...................................7 4.1.6. Attribute Value Assertion...................................7
4.1.7. Attribute and PartialAttribute..............................8 4.1.7. Attribute and PartialAttribute..............................8
4.1.8. Matching Rule Identifier....................................8 4.1.8. Matching Rule Identifier....................................8
4.1.9. Result Message..............................................8 4.1.9. Result Message..............................................8
4.1.10. Referral..................................................10 4.1.10. Referral..................................................10
4.1.11. Controls..................................................11 4.1.11. Controls..................................................11
4.2. Bind Operation...............................................13 4.2. Bind Operation...............................................13
4.3. Unbind Operation.............................................16 4.3. Unbind Operation.............................................16
4.4. Unsolicited Notification.....................................16 4.4. Unsolicited Notification.....................................16
4.5. Search Operation.............................................17 4.5. Search Operation.............................................17
4.6. Modify Operation.............................................26 4.6. Modify Operation.............................................26
4.7. Add Operation................................................27 4.7. Add Operation................................................27
4.8. Delete Operation.............................................28 4.8. Delete Operation.............................................28
4.9. Modify DN Operation..........................................28 4.9. Modify DN Operation..........................................29
4.10. Compare Operation...........................................30 4.10. Compare Operation...........................................30
4.11. Abandon Operation...........................................30 4.11. Abandon Operation...........................................31
4.12. Extended Operation..........................................31 4.12. Extended Operation..........................................31
4.13. IntermediateResponse Message................................32 4.13. IntermediateResponse Message................................33
4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......33 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......33
4.13.2. Usage with LDAP Request Controls..........................34 4.13.2. Usage with LDAP Request Controls..........................34
4.14. StartTLS Operation..........................................34 4.14. StartTLS Operation..........................................34
5. Protocol Element Encodings and Transfer........................36 5. Protocol Element Encodings and Transfer........................36
5.1. Protocol Encoding............................................37 5.1. Protocol Encoding............................................37
5.2. Transfer Protocols...........................................37 5.2. Transfer Protocols...........................................37
6. Security Considerations........................................37 6. Security Considerations........................................38
7. Acknowledgements...............................................39 7. Acknowledgements...............................................39
8. Normative References...........................................39 8. Normative References...........................................39
9. Informative References.........................................40 9. Informative References.........................................41
10. IANA Considerations...........................................41 10. IANA Considerations...........................................41
11. Editor's Address..............................................41 11. Editor's Address..............................................41
Appendix A - LDAP Result Codes....................................42 Appendix A - LDAP Result Codes....................................42
A.1 Non-Error Result Codes........................................42 A.1 Non-Error Result Codes........................................42
A.2 Result Codes..................................................42 A.2 Result Codes..................................................42
Appendix B - Complete ASN.1 Definition............................46 Appendix B - Complete ASN.1 Definition............................46
Appendix C - Changes..............................................52 Appendix C - Changes..............................................52
C.1 Changes made to made to RFC 2251:.............................52 C.1 Changes made to made to RFC 2251:.............................52
C.2 Changes made to made to RFC 2830:.............................57 C.2 Changes made to made to RFC 2830:.............................57
C.3 Changes made to made to [LIMR]:...............................58 C.3 Changes made to made to [LIMR]:...............................58
skipping to change at line 108 skipping to change at line 108
1. Introduction 1. Introduction
The Directory is "a collection of open systems cooperating to provide The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. A directory user, which may be a human directory services" [X.500]. A directory user, which may be a human
or other entity, accesses the Directory through a client (or or other entity, accesses the Directory through a client (or
Directory User Agent (DUA)). The client, on behalf of the directory Directory User Agent (DUA)). The client, on behalf of the directory
user, interacts with one or more servers (or Directory System Agents user, interacts with one or more servers (or Directory System Agents
(DSA)). Clients interact with servers using a directory access (DSA)). Clients interact with servers using a directory access
protocol. protocol.
Sermersheim Internet-Draft - Expires Jul 2004 Page 2 Sermersheim Internet-Draft - Expires Aug 2004 Page 2
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
This document details the protocol elements of the Lightweight This document details the protocol elements of the Lightweight
Directory Access Protocol (LDAP), along with their semantics. Directory Access Protocol (LDAP), along with their semantics.
Following the description of protocol elements, it describes the way Following the description of protocol elements, it describes the way
in which the protocol elements are encoded and transferred. in which the protocol elements are encoded and transferred.
1.1. Relationship to Obsolete Specifications 1.1. Relationship to Obsolete Specifications
This document is an integral part of the LDAP Technical Specification This document is an integral part of the LDAP Technical Specification
skipping to change at line 136 skipping to change at line 136
Section 3.3 is obsoleted by [Roadmap]. Section 3.3 is obsoleted by [Roadmap].
Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth].
Appendix C.1 summarizes substantive changes to the remaining Appendix C.1 summarizes substantive changes to the remaining
sections. sections.
This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The
remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2
summarizes substantive changes to the remaining sections. summarizes substantive changes to the remaining sections.
This document also obsoletes [LIMR] in entrirety. This document also obsoletes [LIMR] in entirety.
<<Note to RFC Editor: [LIMR] is to be replaced with the RFC <<Note to RFC Editor: [LIMR] is to be replaced with the RFC
number assigned to draft-rharrison-ldap-intermediate-resp- number assigned to draft-rharrison-ldap-intermediate-resp-
xx.txt, an RFC-to-be.>> xx.txt, an RFC-to-be.>>
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in [Keyword]. to be interpreted as described in [Keyword].
skipping to change at line 162 skipping to change at line 162
The terms "association" and "LDAP association" both refer to the The terms "association" and "LDAP association" both refer to the
association of the LDAP connection and its current authentication and association of the LDAP connection and its current authentication and
authorization state. authorization state.
3. Protocol Model 3. Protocol Model
The general model adopted by this protocol is one of clients The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, a performing protocol operations against servers. In this model, a
client transmits a protocol request describing the operation to be client transmits a protocol request describing the operation to be
performed to a server. The server is then responsible for performing
Sermersheim Internet-Draft - Expires Jul 2004 Page 3 Sermersheim Internet-Draft - Expires Aug 2004 Page 3
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
performed to a server. The server is then responsible for performing
the necessary operation(s) in the Directory. Upon completion of an the necessary operation(s) in the Directory. Upon completion of an
operation, the server typically returns a response containing operation, the server typically returns a response containing
appropriate data to the requesting client. appropriate data to the requesting client.
Although servers are required to return responses whenever such Although servers are required to return responses whenever such
responses are defined in the protocol, there is no requirement for responses are defined in the protocol, there is no requirement for
synchronous behavior on the part of either clients or servers. synchronous behavior on the part of either clients or servers.
Requests and responses for multiple operations generally may be Requests and responses for multiple operations generally may be
exchanged between a client and server in any order, provided the exchanged between a client and server in any order, provided the
client eventually receives a response for every request that requires client eventually receives a response for every request that requires
skipping to change at line 194 skipping to change at line 194
make multiple DAP requests to service a single LDAP request. make multiple DAP requests to service a single LDAP request.
4. Elements of Protocol 4. Elements of Protocol
The protocol is described using Abstract Syntax Notation One The protocol is described using Abstract Syntax Notation One
([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
Rules ([BER]). Section 5.1 specifies how the protocol elements are Rules ([BER]). Section 5.1 specifies how the protocol elements are
encoded and transferred. encoded and transferred.
In order to support future extensions to this protocol, extensibility In order to support future extensions to this protocol, extensibility
is implied where it is allowed (per ASN.1). In addition, ellipses is implied where it is allowed per ASN.1 (i.e. sequence, set, choice,
(...) have been supplied in ASN.1 types that are explicitly and enumerated types are extensible). In addition, ellipses (...)
extensible as discussed in [LDAPIANA]. Because of the implied have been supplied in ASN.1 types that are explicitly extensible as
extensibility, clients and servers MUST (unless otherwise specified) discussed in [LDAPIANA]. Because of the implied extensibility,
ignore trailing SEQUENCE components whose tags they do not recognize. clients and servers MUST (unless otherwise specified) ignore trailing
SEQUENCE components whose tags they do not recognize.
Changes to the protocol other than through the extension mechanisms Changes to the protocol other than through the extension mechanisms
described here require a different version number. A client indicates described here require a different version number. A client indicates
the version it is using as part of the bind request, described in the version it is using as part of the bind request, described in
Section 4.2. If a client has not sent a bind, the server MUST assume Section 4.2. If a client has not sent a bind, the server MUST assume
the client is using version 3 or later. the client is using version 3 or later.
Clients may determine the protocol versions a server supports by Clients may determine the protocol versions a server supports by
reading the 'supportedLDAPVersion' attribute from the root DSE (DSA- reading the 'supportedLDAPVersion' attribute from the root DSE (DSA-
Specific Entry) [Models]. Specific Entry) [Models].
4.1. Common Elements 4.1. Common Elements
This section describes the LDAPMessage envelope Protocol Data Unit This section describes the LDAPMessage envelope Protocol Data Unit
(PDU) format, as well as data type definitions, which are used in the (PDU) format, as well as data type definitions, which are used in the
protocol operations. protocol operations.
4.1.1. Message Envelope Sermersheim Internet-Draft - Expires Aug 2004 Page 4
Sermersheim Internet-Draft - Expires Jul 2004 Page 4
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
4.1.1. Message Envelope
For the purposes of protocol exchanges, all protocol operations are For the purposes of protocol exchanges, all protocol operations are
encapsulated in a common envelope, the LDAPMessage, which is defined encapsulated in a common envelope, the LDAPMessage, which is defined
as follows: as follows:
LDAPMessage ::= SEQUENCE { LDAPMessage ::= SEQUENCE {
messageID MessageID, messageID MessageID,
protocolOp CHOICE { protocolOp CHOICE {
bindRequest BindRequest, bindRequest BindRequest,
bindResponse BindResponse, bindResponse BindResponse,
unbindRequest UnbindRequest, unbindRequest UnbindRequest,
skipping to change at line 273 skipping to change at line 274
SEQUENCE tag cannot be recognized, the messageID cannot be parsed, SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
the tag of the protocolOp is not recognized as a request, or the the tag of the protocolOp is not recognized as a request, or the
encoding structures or lengths of data fields are found to be encoding structures or lengths of data fields are found to be
incorrect, then the server SHOULD return the Notice of Disconnection incorrect, then the server SHOULD return the Notice of Disconnection
described in Section 4.4.1, with the resultCode set to protocolError, described in Section 4.4.1, with the resultCode set to protocolError,
and MUST immediately close the connection. and MUST immediately close the connection.
In other cases where the client or server cannot parse a PDU, it In other cases where the client or server cannot parse a PDU, it
SHOULD abruptly close the connection where further communication SHOULD abruptly close the connection where further communication
(including providing notice) would be pernicious. Otherwise, server (including providing notice) would be pernicious. Otherwise, server
implementations MUST return an appropriate response to the request,
with the resultCode set to protocolError.
Sermersheim Internet-Draft - Expires Jul 2004 Page 5 Sermersheim Internet-Draft - Expires Aug 2004 Page 5
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
implementations MUST return an appropriate response to the request,
with the resultCode set to protocolError.
4.1.1.1. Message ID 4.1.1.1. Message ID
All LDAPMessage envelopes encapsulating responses contain the All LDAPMessage envelopes encapsulating responses contain the
messageID value of the corresponding request LDAPMessage. messageID value of the corresponding request LDAPMessage.
The message ID of a request MUST have a non-zero value different from The message ID of a request MUST have a non-zero value different from
the values of any other requests outstanding in the LDAP association the values of any other requests outstanding in the LDAP association
of which this message is a part. The zero value is reserved for the of which this message is a part. The zero value is reserved for the
unsolicited notification message. unsolicited notification message.
skipping to change at line 328 skipping to change at line 330
For example, For example,
1.3.6.1.4.1.1466.1.2.3 1.3.6.1.4.1.1466.1.2.3
4.1.3. Distinguished Name and Relative Distinguished Name 4.1.3. Distinguished Name and Relative Distinguished Name
An LDAPDN is defined to be the representation of a Distinguished Name An LDAPDN is defined to be the representation of a Distinguished Name
(DN) after encoding according to the specification in [LDAPDN]. (DN) after encoding according to the specification in [LDAPDN].
LDAPDN ::= LDAPString Sermersheim Internet-Draft - Expires Aug 2004 Page 6
Sermersheim Internet-Draft - Expires Jul 2004 Page 6
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [LDAPDN] -- Constrained to <distinguishedName> [LDAPDN]
A RelativeLDAPDN is defined to be the representation of a Relative A RelativeLDAPDN is defined to be the representation of a Relative
Distinguished Name (RDN) after encoding according to the Distinguished Name (RDN) after encoding according to the
specification in [LDAPDN]. specification in [LDAPDN].
RelativeLDAPDN ::= LDAPString RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [LDAPDN] -- Constrained to <name-component> [LDAPDN]
4.1.4. Attribute Descriptions 4.1.4. Attribute Descriptions
skipping to change at line 382 skipping to change at line 383
[Models]. [Models].
Clients MUST only send attribute values in a request that are valid Clients MUST only send attribute values in a request that are valid
according to the syntax defined for the attributes. according to the syntax defined for the attributes.
4.1.6. Attribute Value Assertion 4.1.6. Attribute Value Assertion
The AttributeValueAssertion (AVA) type definition is similar to the The AttributeValueAssertion (AVA) type definition is similar to the
one in the X.500 Directory standards. It contains an attribute one in the X.500 Directory standards. It contains an attribute
description and a matching rule ([Models Section 4.1.3) assertion description and a matching rule ([Models Section 4.1.3) assertion
value suitable for that type. Elements of this type are typically
Sermersheim Internet-Draft - Expires Jul 2004 Page 7 Sermersheim Internet-Draft - Expires Aug 2004 Page 7
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
value suitable for that type. Elements of this type are typically
used to assert that the value in assertionValue matches a value of an used to assert that the value in assertionValue matches a value of an
attribute. attribute.
AttributeValueAssertion ::= SEQUENCE { AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription, attributeDesc AttributeDescription,
assertionValue AssertionValue } assertionValue AssertionValue }
AssertionValue ::= OCTET STRING AssertionValue ::= OCTET STRING
The syntax of the AssertionValue depends on the context of the LDAP The syntax of the AssertionValue depends on the context of the LDAP
skipping to change at line 436 skipping to change at line 437
either its <numericoid>, or one of its short name descriptors either its <numericoid>, or one of its short name descriptors
[Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'. [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
MatchingRuleId ::= LDAPString MatchingRuleId ::= LDAPString
4.1.9. Result Message 4.1.9. Result Message
The LDAPResult is the construct used in this protocol to return The LDAPResult is the construct used in this protocol to return
success or failure indications from servers to clients. To various success or failure indications from servers to clients. To various
requests, servers will return responses of LDAPResult or responses requests, servers will return responses of LDAPResult or responses
containing the components of LDAPResult to indicate the final status
of a protocol operation request.
Sermersheim Internet-Draft - Expires Jul 2004 Page 8 Sermersheim Internet-Draft - Expires Aug 2004 Page 8
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
containing the components of LDAPResult to indicate the final status
of a protocol operation request.
LDAPResult ::= SEQUENCE { LDAPResult ::= SEQUENCE {
resultCode ENUMERATED { resultCode ENUMERATED {
success (0), success (0),
operationsError (1), operationsError (1),
protocolError (2), protocolError (2),
timeLimitExceeded (3), timeLimitExceeded (3),
sizeLimitExceeded (4), sizeLimitExceeded (4),
compareFalse (5), compareFalse (5),
compareTrue (6), compareTrue (6),
authMethodNotSupported (7), authMethodNotSupported (7),
skipping to change at line 493 skipping to change at line 495
notAllowedOnRDN (67), notAllowedOnRDN (67),
entryAlreadyExists (68), entryAlreadyExists (68),
objectClassModsProhibited (69), objectClassModsProhibited (69),
-- 70 reserved for CLDAP -- -- 70 reserved for CLDAP --
affectsMultipleDSAs (71), affectsMultipleDSAs (71),
-- 72-79 unused -- -- 72-79 unused --
other (80), other (80),
... }, ... },
matchedDN LDAPDN, matchedDN LDAPDN,
diagnosticMessage LDAPString, diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
Sermersheim Internet-Draft - Expires Jul 2004 Page 9 Sermersheim Internet-Draft - Expires Aug 2004 Page 9
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
referral [3] Referral OPTIONAL }
The resultCode enumeration is extensible as defined in Section 3.6 of The resultCode enumeration is extensible as defined in Section 3.6 of
[LDAPIANA]. The meanings of the listed result codes are given in [LDAPIANA]. The meanings of the listed result codes are given in
Appendix A. If a server detects multiple errors for an operation, Appendix A. If a server detects multiple errors for an operation,
only one result code is returned. The server should return the result only one result code is returned. The server should return the result
code that best indicates the nature of the error encountered. code that best indicates the nature of the error encountered.
The diagnosticMessage field of this construct may, at the server's The diagnosticMessage field of this construct may, at the server's
option, be used to return a string containing a textual, human- option, be used to return a string containing a textual, human-
readable (terminal control and page formatting characters should be readable (terminal control and page formatting characters should be
avoided) diagnostic message. As this diagnostic message is not avoided) diagnostic message. As this diagnostic message is not
skipping to change at line 548 skipping to change at line 551
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
URI ::= LDAPString -- limited to characters permitted in URI ::= LDAPString -- limited to characters permitted in
-- URIs -- URIs
If the client wishes to progress the operation, it MUST follow the If the client wishes to progress the operation, it MUST follow the
referral by contacting one of the supported services. If multiple referral by contacting one of the supported services. If multiple
URIs are present, the client assumes that any supported URI may be URIs are present, the client assumes that any supported URI may be
used to progress the operation. used to progress the operation.
Clients that follow referrals MUST ensure that they do not loop Sermersheim Internet-Draft - Expires Aug 2004 Page 10
between servers. They MUST NOT repeatedly contact the same server for
the same request with the same target entry name, scope and filter.
Sermersheim Internet-Draft - Expires Jul 2004 Page 10
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
Some clients use a counter that is incremented each time referral Protocol peers that follow referrals MUST ensure that they do not
handling occurs for an operation, and these kinds of clients MUST be loop between servers. They MUST NOT repeatedly contact the same
able to handle at least ten nested referrals between the root and a server for the same request with the same target entry name, scope
leaf entry. and filter. Some implementations use a counter that is incremented
each time referral handling occurs for an operation, and these kinds
of implementations MUST be able to handle at least ten nested
referrals between the root and a leaf entry.
A URI for a server implementing LDAP and accessible via [TCP]/[IP] A URI for a server implementing LDAP and accessible via [TCP]/[IP]
(v4 or v6) is written as an LDAP URL according to [LDAPURL]. (v4 or v6) is written as an LDAP URL according to [LDAPURL].
When an LDAP URL is used, the following instructions are followed: When an LDAP URL is used, the following instructions are followed:
- If an alias was dereferenced, the <dn> part of the URL MUST be - If an alias was dereferenced, the <dn> part of the URL MUST be
present, with the new target object name. UTF-8 encoded characters present, with the new target object name. UTF-8 encoded characters
appearing in the string representation of a DN or search filter appearing in the string representation of a DN or search filter
may not be legal for URLs (e.g. spaces) and MUST be escaped using may not be legal for URLs (e.g. spaces) and MUST be escaped using
skipping to change at line 606 skipping to change at line 608
existing LDAP operations may be extended. One or more controls may be existing LDAP operations may be extended. One or more controls may be
attached to a single LDAP message. A control only affects the attached to a single LDAP message. A control only affects the
semantics of the message it is attached to. semantics of the message it is attached to.
Controls sent by clients are termed 'request controls' and those sent Controls sent by clients are termed 'request controls' and those sent
by servers are termed 'response controls'. by servers are termed 'response controls'.
When an extension calls for a particular response control to be sent When an extension calls for a particular response control to be sent
in response to a request control, the response and request controls in response to a request control, the response and request controls
are termed to be "paired". are termed to be "paired".
Controls ::= SEQUENCE OF control Control Sermersheim Internet-Draft - Expires Aug 2004 Page 11
Sermersheim Internet-Draft - Expires Jul 2004 Page 11
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE { Control ::= SEQUENCE {
controlType LDAPOID, controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE, criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL } controlValue OCTET STRING OPTIONAL }
The controlType field is the dotted-decimal representation of an The controlType field is the dotted-decimal representation of an
OBJECT IDENTIFIER which uniquely identifies the control, or the OBJECT IDENTIFIER which uniquely identifies the control, or the
request control and its paired response control. This provides request control and its paired response control. This provides
unambiguous naming of controls. unambiguous naming of controls.
skipping to change at line 662 skipping to change at line 664
Servers list the controlType of all request controls they recognize Servers list the controlType of all request controls they recognize
in the supportedControl attribute in the root DSE (Section 5.1 of in the supportedControl attribute in the root DSE (Section 5.1 of
[Models]). [Models]).
Controls SHOULD NOT be combined unless the semantics of the Controls SHOULD NOT be combined unless the semantics of the
combination has been specified. The semantics of control combination has been specified. The semantics of control
combinations, if specified, are generally found in the control combinations, if specified, are generally found in the control
specification most recently published. In the absence of combination specification most recently published. In the absence of combination
semantics, the behavior of the operation is undefined. semantics, the behavior of the operation is undefined.
Sermersheim Internet-Draft - Expires Aug 2004 Page 12
Lightweight Directory Access Protocol Version 3
Additionally, unless order-dependent semantics are given in a Additionally, unless order-dependent semantics are given in a
specification, the order of a combination of controls in the SEQUENCE specification, the order of a combination of controls in the SEQUENCE
is ignored. is ignored.
Sermersheim Internet-Draft - Expires Jul 2004 Page 12
Lightweight Directory Access Protocol Version 3
This document does not specify any controls. Controls may be This document does not specify any controls. Controls may be
specified in other documents. Documents detailing control extensions specified in other documents. Documents detailing control extensions
are to provide for each control: are to provide for each control:
- the OBJECT IDENTIFIER assigned to the control, - the OBJECT IDENTIFIER assigned to the control,
- direction as to what value the sender should provide for the - direction as to what value the sender should provide for the
criticality field (note: the semantics of the criticality field criticality field (note: the semantics of the criticality field
are defined above should not be altered by the control's are defined above should not be altered by the control's
specification), specification),
skipping to change at line 718 skipping to change at line 721
SaslCredentials ::= SEQUENCE { SaslCredentials ::= SEQUENCE {
mechanism LDAPString, mechanism LDAPString,
credentials OCTET STRING OPTIONAL } credentials OCTET STRING OPTIONAL }
Fields of the Bind Request are: Fields of the Bind Request are:
- version: A version number indicating the version of the protocol - version: A version number indicating the version of the protocol
to be used in this LDAP association. This document describes to be used in this LDAP association. This document describes
version 3 of the protocol. There is no version negotiation. The version 3 of the protocol. There is no version negotiation. The
Sermersheim Internet-Draft - Expires Aug 2004 Page 13
Lightweight Directory Access Protocol Version 3
client sets this field to the version it desires. If the server client sets this field to the version it desires. If the server
does not support the specified version, it MUST respond with does not support the specified version, it MUST respond with
protocolError in the resultCode field of the BindResponse. protocolError in the resultCode field of the BindResponse.
Sermersheim Internet-Draft - Expires Jul 2004 Page 13
Lightweight Directory Access Protocol Version 3
- name: The name of the Directory object that the client wishes to - 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 bind as. This field may take on a null value (a zero length
string) for the purposes of anonymous binds ([AuthMeth] Section string) for the purposes of anonymous binds ([AuthMeth] Section
5.1) or when using Simple Authentication and Security Layer [SASL] 5.1) or when using Simple Authentication and Security Layer [SASL]
authentication ([AuthMeth] Section 3.3.2). Server behavior is authentication ([AuthMeth] Section 3.3.2). Server behavior is
undefined when the name is a null value, simple authentication is undefined when the name is a null value, simple authentication is
used, and a non-null password is specified. Where the server used, and a non-null password is specified. Where the server
attempts to locate the named object, it SHALL NOT perform alias attempts to locate the named object, it SHALL NOT perform alias
dereferencing. dereferencing.
skipping to change at line 773 skipping to change at line 777
If the client did not bind before sending a request and receives an If the client did not bind before sending a request and receives an
operationsError to that request, it may then send a Bind Request. If operationsError to that request, it may then send a Bind Request. If
this also fails or the client chooses not to bind on the existing this also fails or the client chooses not to bind on the existing
connection, it may close the connection, reopen it and begin again by connection, it may close the connection, reopen it and begin again by
first sending a PDU with a Bind Request. This will aid in first sending a PDU with a Bind Request. This will aid in
interoperating with servers implementing other versions of LDAP. interoperating with servers implementing other versions of LDAP.
Clients may send multiple Bind Requests on a connection to change the Clients may send multiple Bind Requests on a connection to change the
authentication and/or security associations or to complete a multi- authentication and/or security associations or to complete a multi-
stage bind process. Authentication from earlier binds is subsequently
ignored.
Sermersheim Internet-Draft - Expires Jul 2004 Page 14 Sermersheim Internet-Draft - Expires Aug 2004 Page 14
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
stage bind process. Authentication from earlier binds is subsequently
ignored.
For some SASL authentication mechanisms, it may be necessary for the For some SASL authentication mechanisms, it may be necessary for the
client to invoke the BindRequest multiple times. This is indicated by client to invoke the BindRequest multiple times. This is indicated by
the server sending a BindResponse with the resultCode set to the server sending a BindResponse with the resultCode set to
saslBindInProgress. This indicates that the server requires the saslBindInProgress. This indicates that the server requires the
client to send a new bind request, with the same sasl mechanism, to client to send a new bind request, with the same sasl mechanism, to
continue the authentication process. Clients MUST NOT invoke continue the authentication process. Clients MUST NOT invoke
operations between two Bind Requests made as part of a multi-stage operations between two Bind Requests made as part of a multi-stage
bind. bind.
A client may abort a SASL bind negotiation by sending a BindRequest A client may abort a SASL bind negotiation by sending a BindRequest
skipping to change at line 829 skipping to change at line 834
protocolError, it is to assume that the server does not support this protocolError, it is to assume that the server does not support this
version of LDAP. While the client may be able proceed with another version of LDAP. While the client may be able proceed with another
version of this protocol (this may or may not require establishing a version of this protocol (this may or may not require establishing a
new connection), how to proceed with another version of this protocol new connection), how to proceed with another version of this protocol
is beyond the scope of this document. Clients which are unable or is beyond the scope of this document. Clients which are unable or
unwilling to proceed SHOULD drop the underlying connection. unwilling to proceed SHOULD drop the underlying connection.
The serverSaslCreds field is used as part of a SASL-defined bind The serverSaslCreds field is used as part of a SASL-defined bind
mechanism to allow the client to authenticate the server to which it mechanism to allow the client to authenticate the server to which it
is communicating, or to perform "challenge-response" authentication. is communicating, or to perform "challenge-response" authentication.
Sermersheim Internet-Draft - Expires Aug 2004 Page 15
Lightweight Directory Access Protocol Version 3
If the client bound with the simple choice, or the SASL mechanism If the client bound with the simple choice, or the SASL mechanism
does not require the server to return information to the client, then does not require the server to return information to the client, then
this field SHALL NOT be included in the BindResponse. this field SHALL NOT be included in the BindResponse.
Sermersheim Internet-Draft - Expires Jul 2004 Page 15
Lightweight Directory Access Protocol Version 3
4.3. Unbind Operation 4.3. Unbind Operation
The function of the Unbind Operation is to terminate an LDAP The function of the Unbind Operation is to terminate an LDAP
association and connection. The Unbind operation is not the association and connection. The Unbind operation is not the
antithesis of the Bind operation as the name implies. The naming of antithesis of the Bind operation as the name implies. The naming of
these operations is historical. The Unbind operation should be these operations is historical. The Unbind operation should be
thought of as the "quit" operation. thought of as the "quit" operation.
The Unbind Operation is defined as follows: The Unbind Operation is defined as follows:
skipping to change at line 884 skipping to change at line 890
- the format of the contents (if any) of the responseValue, - the format of the contents (if any) of the responseValue,
- the circumstances which will cause the notification to be - the circumstances which will cause the notification to be
returned, and returned, and
- the semantics of the operation. - the semantics of the operation.
4.4.1. Notice of Disconnection 4.4.1. Notice of Disconnection
Sermersheim Internet-Draft - Expires Aug 2004 Page 16
Lightweight Directory Access Protocol Version 3
This notification may be used by the server to advise the client that This notification may be used by the server to advise the client that
the server is about to close the connection due to an error the server is about to close the connection due to an error
condition. This notification is intended to assist clients in condition. This notification is intended to assist clients in
Sermersheim Internet-Draft - Expires Jul 2004 Page 16
Lightweight Directory Access Protocol Version 3
distinguishing between an error condition and a transient network distinguishing between an error condition and a transient network
failure. Note that this notification is not a response to an unbind failure. Note that this notification is not a response to an unbind
requested by the client. Outstanding operations are handled as requested by the client. Outstanding operations are handled as
specified in Section 5.2. specified in Section 5.2.
The responseName is 1.3.6.1.4.1.1466.20036, the response field is The responseName is 1.3.6.1.4.1.1466.20036, the response field is
absent, and the resultCode is used to indicate the reason for the absent, and the resultCode is used to indicate the reason for the
disconnection. disconnection.
The following result codes have these meanings when used in this The following result codes have these meanings when used in this
skipping to change at line 939 skipping to change at line 944
The Search Request is defined as follows: The Search Request is defined as follows:
SearchRequest ::= [APPLICATION 3] SEQUENCE { SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN, baseObject LDAPDN,
scope ENUMERATED { scope ENUMERATED {
baseObject (0), baseObject (0),
singleLevel (1), singleLevel (1),
wholeSubtree (2) }, wholeSubtree (2) },
derefAliases ENUMERATED { derefAliases ENUMERATED {
Sermersheim Internet-Draft - Expires Aug 2004 Page 17
Lightweight Directory Access Protocol Version 3
neverDerefAliases (0), neverDerefAliases (0),
derefInSearching (1), derefInSearching (1),
derefFindingBaseObj (2), derefFindingBaseObj (2),
derefAlways (3) }, derefAlways (3) },
Sermersheim Internet-Draft - Expires Jul 2004 Page 17
Lightweight Directory Access Protocol Version 3
sizeLimit INTEGER (0 .. maxInt), sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN, typesOnly BOOLEAN,
filter Filter, filter Filter,
attributes AttributeSelection } attributes AttributeSelection }
AttributeSelection ::= SEQUENCE OF selection LDAPString AttributeSelection ::= SEQUENCE OF selection LDAPString
-- constrained to <attributeSelection> below -- constrained to <attributeSelection> below
Filter ::= CHOICE { Filter ::= CHOICE {
skipping to change at line 997 skipping to change at line 1002
- scope: Specifies the scope of the search to be performed. The - scope: Specifies the scope of the search to be performed. The
semantics (as described in [X.511]) of the possible values of this semantics (as described in [X.511]) of the possible values of this
field are: field are:
baseObject: The scope is constrained to the entry named by baseObject: The scope is constrained to the entry named by
baseObject. baseObject.
singleLevel: The scope is constrained to the immediate singleLevel: The scope is constrained to the immediate
subordinates of the entry named by baseObject. subordinates of the entry named by baseObject.
Sermersheim Internet-Draft - Expires Aug 2004 Page 18
Lightweight Directory Access Protocol Version 3
wholeSubtree: the scope is constrained to the entry named by wholeSubtree: the scope is constrained to the entry named by
the baseObject, and all its subordinates. the baseObject, and all its subordinates.
Sermersheim Internet-Draft - Expires Jul 2004 Page 18
Lightweight Directory Access Protocol Version 3
- derefAliases: An indicator as to how alias entries (as defined in - derefAliases: An indicator as to how alias entries (as defined in
[Models]) are to be handled in searching. The semantics of the [Models]) are to be handled in searching. The semantics of the
possible values of this field are: possible values of this field are:
neverDerefAliases: Do not dereference aliases in searching or neverDerefAliases: Do not dereference aliases in searching or
in locating the base object of the search. in locating the base object of the search.
derefInSearching: While searching, dereference any alias entry derefInSearching: While searching, dereference any alias entry
subordinate to the base object which is also in the search subordinate to the base object which is also in the search
scope. The filter is applied to the dereferenced object(s). If scope. The filter is applied to the dereferenced object(s). If
skipping to change at line 1053 skipping to change at line 1058
FALSE causes both attribute descriptions and values to be FALSE causes both attribute descriptions and values to be
returned. returned.
- filter: A filter that defines the conditions that must be - filter: A filter that defines the conditions that must be
fulfilled in order for the search to match a given entry. fulfilled in order for the search to match a given entry.
The 'and', 'or' and 'not' choices can be used to form combinations The 'and', 'or' and 'not' choices can be used to form combinations
of filters. At least one filter element MUST be present in an of filters. At least one filter element MUST be present in an
'and' or 'or' choice. The others match against individual 'and' or 'or' choice. The others match against individual
attribute values of entries in the scope of the search. attribute values of entries in the scope of the search.
Sermersheim Internet-Draft - Expires Aug 2004 Page 19
Lightweight Directory Access Protocol Version 3
(Implementor's note: the 'not' filter is an example of a tagged (Implementor's note: the 'not' filter is an example of a tagged
choice in an implicitly-tagged module. In BER this is treated as choice in an implicitly-tagged module. In BER this is treated as
if the tag was explicit.) if the tag was explicit.)
Sermersheim Internet-Draft - Expires Jul 2004 Page 19
Lightweight Directory Access Protocol Version 3
A server MUST evaluate filters according to the three-valued logic A server MUST evaluate filters according to the three-valued logic
of X.511 (1993) Section 7.8.1. In summary, a filter is evaluated of X.511 (1993) Section 7.8.1. In summary, a filter is evaluated
to either "TRUE", "FALSE" or "Undefined". If the filter evaluates to either "TRUE", "FALSE" or "Undefined". If the filter evaluates
to TRUE for a particular entry, then the attributes of that entry to TRUE for a particular entry, then the attributes of that entry
are returned as part of the search result (subject to any are returned as part of the search result (subject to any
applicable access control restrictions). If the filter evaluates applicable access control restrictions). If the filter evaluates
to FALSE or Undefined, then the entry is ignored for the search. to FALSE or Undefined, then the entry is ignored for the search.
A filter of the "and" choice is TRUE if all the filters in the SET A filter of the "and" choice is TRUE if all the filters in the SET
OF evaluate to TRUE, FALSE if at least one filter is FALSE, and OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
skipping to change at line 1111 skipping to change at line 1117
the ORDERING matching rule for the attribute type. the ORDERING matching rule for the attribute type.
An approxMatch filter item evaluates to TRUE when there is a value An approxMatch filter item evaluates to TRUE when there is a value
of the attribute or subtype for which some locally-defined of the attribute or subtype for which some locally-defined
approximate matching algorithm (e.g. spelling variations, phonetic approximate matching algorithm (e.g. spelling variations, phonetic
match, etc.) returns TRUE. If an item matches for equality, it match, etc.) returns TRUE. If an item matches for equality, it
also satisfies an approximate match. If approximate matching is also satisfies an approximate match. If approximate matching is
not supported, this filter item should be treated as an not supported, this filter item should be treated as an
equalityMatch. equalityMatch.
An extensibleMatch filter item is evaluated as follows: Sermersheim Internet-Draft - Expires Aug 2004 Page 20
Sermersheim Internet-Draft - Expires Jul 2004 Page 20
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
An extensibleMatch filter item is evaluated as follows:
If the matchingRule field is absent, the type field MUST be If the matchingRule field is absent, the type field MUST be
present, and an equality match is performed for that type. present, and an equality match is performed for that type.
If the type field is absent and the matchingRule is present, the If the type field is absent and the matchingRule is present, the
matchValue is compared against all attributes in an entry which matchValue is compared against all attributes in an entry which
support that matchingRule. The matchingRule determines the support that matchingRule. The matchingRule determines the
syntax for the assertion value. The filter item evaluates to syntax for the assertion value. The filter item evaluates to
TRUE if it matches with at least one attribute in the entry, TRUE if it matches with at least one attribute in the entry,
FALSE if it does not match any attribute in the entry, and FALSE if it does not match any attribute in the entry, and
Undefined if the matchingRule is not recognized or the Undefined if the matchingRule is not recognized or the
skipping to change at line 1168 skipping to change at line 1174
invalid, or the assertion syntax is not supported. More details of invalid, or the assertion syntax is not supported. More details of
filter processing are given in Section 7.8 of [X.511]. filter processing are given in Section 7.8 of [X.511].
- attributes: A list of the attributes to be returned from each - attributes: A list of the attributes to be returned from each
entry which matches the search filter. LDAPString values of this entry which matches the search filter. LDAPString values of this
field are constrained to the following Augmented Backus-Naur Form field are constrained to the following Augmented Backus-Naur Form
([ABNF]): ([ABNF]):
attributeSelection = attributedescription / selectionspecial attributeSelection = attributedescription / selectionspecial
selectionspecial = noattrs / alluserattrs Sermersheim Internet-Draft - Expires Aug 2004 Page 21
Sermersheim Internet-Draft - Expires Jul 2004 Page 21
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
selectionspecial = noattrs / alluserattrs
noattrs = %x31.2E.31 ; "1.1" noattrs = %x31.2E.31 ; "1.1"
alluserattrs = %x2A ; asterisk ("*") alluserattrs = %x2A ; asterisk ("*")
The <attributedescription> production is defined in Section 2.5 of The <attributedescription> production is defined in Section 2.5 of
[Models]. [Models].
There are three special cases which may exist in the attribute There are three special cases which may exist in the attribute
selection: selection:
- an empty list with no attributes, - an empty list with no attributes,
skipping to change at line 1221 skipping to change at line 1227
client requesting a one-level LDAP search operation with a filter client requesting a one-level LDAP search operation with a filter
checking for the presence of the 'objectClass' attribute, and that an checking for the presence of the 'objectClass' attribute, and that an
X.500 "read"-like operation can be emulated by a base object LDAP X.500 "read"-like operation can be emulated by a base object LDAP
search operation with the same filter. A server which provides a search operation with the same filter. A server which provides a
gateway to X.500 is not required to use the Read or List operations, gateway to X.500 is not required to use the Read or List operations,
although it may choose to do so, and if it does, it must provide the although it may choose to do so, and if it does, it must provide the
same semantics as the X.500 search operation. same semantics as the X.500 search operation.
4.5.2. Search Result 4.5.2. Search Result
Sermersheim Internet-Draft - Expires Aug 2004 Page 22
Lightweight Directory Access Protocol Version 3
The results of the search operation are returned as zero or more The results of the search operation are returned as zero or more
searchResultEntry messages, zero or more SearchResultReference searchResultEntry messages, zero or more SearchResultReference
messages, followed by a single searchResultDone message. messages, followed by a single searchResultDone message.
SearchResultEntry ::= [APPLICATION 4] SEQUENCE { SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
Sermersheim Internet-Draft - Expires Jul 2004 Page 22
Lightweight Directory Access Protocol Version 3
objectName LDAPDN, objectName LDAPDN,
attributes PartialAttributeList } attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute partialAttribute PartialAttribute
-- Note that the PartialAttributeList may hold zero elements. -- Note that the PartialAttributeList may hold zero elements.
-- This may happen when none of the attributes of an entry -- This may happen when none of the attributes of an entry
-- were requested, or could be returned. -- were requested, or could be returned.
-- Note also that the partialAttribute vals set may hold zero -- Note also that the partialAttribute vals set may hold zero
-- elements. This may happen when typesOnly is requested, access -- elements. This may happen when typesOnly is requested, access
skipping to change at line 1278 skipping to change at line 1283
<numericoid> [Models] format of the attribute type's object <numericoid> [Models] format of the attribute type's object
identifier). The server SHOULD NOT use the short name if that name is identifier). The server SHOULD NOT use the short name if that name is
known by the server to be ambiguous, or otherwise likely to cause known by the server to be ambiguous, or otherwise likely to cause
interoperability problems. interoperability problems.
4.5.3. Continuation References in the Search Result 4.5.3. Continuation References in the Search Result
If the server was able to locate the entry referred to by the If the server was able to locate the entry referred to by the
baseObject but was unable to search one or more non-local entries, baseObject but was unable to search one or more non-local entries,
the server may return one or more SearchResultReference entries, each the server may return one or more SearchResultReference entries, each
Sermersheim Internet-Draft - Expires Aug 2004 Page 23
Lightweight Directory Access Protocol Version 3
containing a reference to another set of servers for continuing the containing a reference to another set of servers for continuing the
operation. A server MUST NOT return any SearchResultReference if it operation. A server MUST NOT return any SearchResultReference if it
has not located the baseObject and thus has not searched any entries; has not located the baseObject and thus has not searched any entries;
in this case it would return a SearchResultDone containing a referral in this case it would return a SearchResultDone containing a referral
result code. result code.
Sermersheim Internet-Draft - Expires Jul 2004 Page 23
Lightweight Directory Access Protocol Version 3
If a server holds a copy or partial copy of the subordinate naming If a server holds a copy or partial copy of the subordinate naming
context [Section 5 of Models], it may use the search filter to context [Section 5 of Models], it may use the search filter to
determine whether or not to return a SearchResultReference response. determine whether or not to return a SearchResultReference response.
Otherwise SearchResultReference responses are always returned when in Otherwise SearchResultReference responses are always returned when in
scope. scope.
The SearchResultReference is of the same data type as the Referral. The SearchResultReference is of the same data type as the Referral.
A URI for a server implementing LDAP and accessible via [TCP]/[IP] A URI for a server implementing LDAP and accessible via [TCP]/[IP]
(v4 or v6) is written as an LDAP URL according to [LDAPURL]. (v4 or v6) is written as an LDAP URL according to [LDAPURL].
skipping to change at line 1336 skipping to change at line 1342
- If the originating search scope was singleLevel, the <scope> part - If the originating search scope was singleLevel, the <scope> part
of the URL will be "base". of the URL will be "base".
- it is RECOMMENDED that the <scope> part be present to avoid - it is RECOMMENDED that the <scope> part be present to avoid
ambiguity. ambiguity.
- Other aspects of the new search request may be the same as or - Other aspects of the new search request may be the same as or
different from the search request which generated the different from the search request which generated the
SearchResultReference. SearchResultReference.
- The name of an unexplored subtree in a SearchResultReference need - The name of an unexplored subtree in a SearchResultReference need
not be subordinate to the base object. not be subordinate to the base object.
Sermersheim Internet-Draft - Expires Aug 2004 Page 24
Lightweight Directory Access Protocol Version 3
Other kinds of URIs may be returned. The syntax and semantics of such Other kinds of URIs may be returned. The syntax and semantics of such
URIs is left to future specifications. Clients may ignore URIs that URIs is left to future specifications. Clients may ignore URIs that
they do not support. they do not support.
Sermersheim Internet-Draft - Expires Jul 2004 Page 24
Lightweight Directory Access Protocol Version 3
4.5.3.1. Examples 4.5.3.1. Examples
For example, suppose the contacted server (hosta) holds the entry For example, suppose the contacted server (hosta) holds the entry
<DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
knows that either LDAP-capable servers (hostb) or (hostc) hold knows that either LDAP-capable servers (hostb) or (hostc) hold
<OU=People,DC=Example,DC=NET> (one is the master and the other server <OU=People,DC=Example,DC=NET> (one is the master and the other server
a shadow), and that LDAP-capable server (hostd) holds the subtree a shadow), and that LDAP-capable server (hostd) holds the subtree
<OU=Roles,DC=Example,DC=NET>. If a wholeSubtree search of <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree search of
<DC=Example,DC=NET> is requested to the contacted server, it may <DC=Example,DC=NET> is requested to the contacted server, it may
return the following: return the following:
skipping to change at line 1392 skipping to change at line 1398
ldap://hostc/OU=People,DC=Example,DC=NET??base } ldap://hostc/OU=People,DC=Example,DC=NET??base }
SearchResultReference { SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??base } ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
SearchResultDone (success) SearchResultDone (success)
If the contacted server does not hold the base object for the search, If the contacted server does not hold the base object for the search,
then it will return a referral to the client. For example, if the then it will return a referral to the client. For example, if the
client requests a subtree search of <DC=Example,DC=ORG> to hosta, the client requests a subtree search of <DC=Example,DC=ORG> to hosta, the
server may return only a SearchResultDone containing a referral. server may return only a SearchResultDone containing a referral.
Sermersheim Internet-Draft - Expires Aug 2004 Page 25
Lightweight Directory Access Protocol Version 3
SearchResultDone (referral) { SearchResultDone (referral) {
ldap://hostg/DC=Example,DC=ORG??sub } ldap://hostg/DC=Example,DC=ORG??sub }
Sermersheim Internet-Draft - Expires Jul 2004 Page 25
Lightweight Directory Access Protocol Version 3
4.6. Modify Operation 4.6. Modify Operation
The Modify Operation allows a client to request that a modification The Modify Operation allows a client to request that a modification
of an entry be performed on its behalf by a server. The Modify of an entry be performed on its behalf by a server. The Modify
Request is defined as follows: Request is defined as follows:
ModifyRequest ::= [APPLICATION 6] SEQUENCE { ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN, object LDAPDN,
changes SEQUENCE OF change SEQUENCE { changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED { operation ENUMERATED {
skipping to change at line 1447 skipping to change at line 1453
delete: delete values listed from the modification attribute, delete: delete values listed from the modification attribute,
removing the entire attribute if no values are listed, or if removing the entire attribute if no values are listed, or if
all current values of the attribute are listed for deletion; all current values of the attribute are listed for deletion;
replace: replace all existing values of the modification replace: replace all existing values of the modification
attribute with the new values listed, creating the attribute attribute with the new values listed, creating the attribute
if it did not already exist. A replace with no value will if it did not already exist. A replace with no value will
delete the entire attribute if it exists, and is ignored if delete the entire attribute if it exists, and is ignored if
the attribute does not exist. the attribute does not exist.
Sermersheim Internet-Draft - Expires Aug 2004 Page 26
Lightweight Directory Access Protocol Version 3
- modification: A PartialAttribute (which may have an empty SET - modification: A PartialAttribute (which may have an empty SET
of vals) used to hold the attribute type or attribute type and of vals) used to hold the attribute type or attribute type and
values being modified. values being modified.
Sermersheim Internet-Draft - Expires Jul 2004 Page 26
Lightweight Directory Access Protocol Version 3
Upon receipt of a Modify Request, the server attempts to perform the Upon receipt of a Modify Request, the server attempts to perform the
necessary modifications to the DIT and returns the result in a Modify necessary modifications to the DIT and returns the result in a Modify
Response, defined as follows: Response, defined as follows:
ModifyResponse ::= [APPLICATION 7] LDAPResult ModifyResponse ::= [APPLICATION 7] LDAPResult
The server will return to the client a single Modify Response The server will return to the client a single Modify Response
indicating either the successful completion of the DIT modification, indicating either the successful completion of the DIT modification,
or the reason that the modification failed. Due to the requirement or the reason that the modification failed. Due to the requirement
for atomicity in applying the list of modifications in the Modify for atomicity in applying the list of modifications in the Modify
skipping to change at line 1503 skipping to change at line 1509
AttributeList ::= SEQUENCE OF attribute Attribute AttributeList ::= SEQUENCE OF attribute Attribute
Fields of the Add Request are: Fields of the Add Request are:
- entry: the name of the entry to be added. The server SHALL NOT - entry: the name of the entry to be added. The server SHALL NOT
dereference any aliases in locating the entry to be added. dereference any aliases in locating the entry to be added.
- attributes: the list of attributes that, along with those from the - attributes: the list of attributes that, along with those from the
RDN, make up the content of the entry being added. Clients MUST RDN, make up the content of the entry being added. Clients MUST
include the 'objectClass' attribute, and values of any mandatory include the 'objectClass' attribute, and values of any mandatory
Sermersheim Internet-Draft - Expires Aug 2004 Page 27
Lightweight Directory Access Protocol Version 3
attributes of the listed object classes. Clients MUST NOT supply attributes of the listed object classes. Clients MUST NOT supply
NO-USER-MODIFICATION attributes such as the createTimestamp or NO-USER-MODIFICATION attributes such as the createTimestamp or
creatorsName attributes, since the server maintains these creatorsName attributes, since the server maintains these
automatically. automatically.
Sermersheim Internet-Draft - Expires Jul 2004 Page 27
Lightweight Directory Access Protocol Version 3
The entry named in the entry field of the AddRequest MUST NOT exist The entry named in the entry field of the AddRequest MUST NOT exist
for the AddRequest to succeed. The immediate superior (parent) of an for the AddRequest to succeed. The immediate superior (parent) of an
object or alias entry to be added MUST exist. For example, if the object or alias entry to be added MUST exist. For example, if the
client attempted to add <CN=JS,DC=Example,DC=NET>, the client attempted to add <CN=JS,DC=Example,DC=NET>, the
<DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
exist, then the server would return the noSuchObject result code with exist, then the server would return the noSuchObject result code with
the matchedDN field containing <DC=NET>. If the parent entry exists the matchedDN field containing <DC=NET>.
but is not in a naming context [Section 5 of Models] held by the
server, the server SHOULD return a referral to the server holding the If the entry to be added would not fall within a naming context
parent entry. [Section 5 of Models] held by the server, and the server has
knowledge of where that entry is to be located, a referral to the
server(s) holding the parent entry should be returned.
Server implementations SHOULD NOT restrict where entries can be Server implementations SHOULD NOT restrict where entries can be
located in the Directory unless DIT structure rules are in place. located in the Directory unless DIT structure rules are in place.
Some servers allow the administrator to restrict the classes of Some servers allow the administrator to restrict the classes of
entries which can be added to the Directory. entries which can be added to the Directory.
Upon receipt of an Add Request, a server will attempt to add the Upon receipt of an Add Request, a server will attempt to add the
requested entry. The result of the add attempt will be returned to requested entry. The result of the add attempt will be returned to
the client in the Add Response, defined as follows: the client in the Add Response, defined as follows:
skipping to change at line 1556 skipping to change at line 1565
Only leaf entries (those with no subordinate entries) can be deleted Only leaf entries (those with no subordinate entries) can be deleted
with this operation. with this operation.
Upon receipt of a Delete Request, a server will attempt to perform Upon receipt of a Delete Request, a server will attempt to perform
the entry removal requested and return the result in the Delete the entry removal requested and return the result in the Delete
Response defined as follows: Response defined as follows:
DelResponse ::= [APPLICATION 11] LDAPResult DelResponse ::= [APPLICATION 11] LDAPResult
Sermersheim Internet-Draft - Expires Aug 2004 Page 28
Lightweight Directory Access Protocol Version 3
4.9. Modify DN Operation 4.9. Modify DN Operation
The Modify DN Operation allows a client to change the Relative The Modify DN Operation allows a client to change the Relative
Distinguished Name (RDN) of an entry in the Directory, and/or to move Distinguished Name (RDN) of an entry in the Directory, and/or to move
a subtree of entries to a new location in the Directory. The Modify a subtree of entries to a new location in the Directory. The Modify
DN Request is defined as follows: DN Request is defined as follows:
Sermersheim Internet-Draft - Expires Jul 2004 Page 28
Lightweight Directory Access Protocol Version 3
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN, entry LDAPDN,
newrdn RelativeLDAPDN, newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN, deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL } newSuperior [0] LDAPDN OPTIONAL }
Fields of the Modify DN Request are: Fields of the Modify DN Request are:
- entry: the name of the entry to be changed. This entry may or may - entry: the name of the entry to be changed. This entry may or may
not have subordinate entries. not have subordinate entries.
skipping to change at line 1612 skipping to change at line 1621
rename the entry to be <cn=John Cougar Smith,c=US>. If there was rename the entry to be <cn=John Cougar Smith,c=US>. If there was
already an entry with that name, the operation would fail with the already an entry with that name, the operation would fail with the
entryAlreadyExists result code. entryAlreadyExists result code.
The object named in newSuperior MUST exist. For example, if the The object named in newSuperior MUST exist. For example, if the
client attempted to add <CN=JS,DC=Example,DC=NET>, the client attempted to add <CN=JS,DC=Example,DC=NET>, the
<DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
exist, then the server would return the noSuchObject result code with exist, then the server would return the noSuchObject result code with
the matchedDN field containing <DC=NET>. the matchedDN field containing <DC=NET>.
Sermersheim Internet-Draft - Expires Aug 2004 Page 29
Lightweight Directory Access Protocol Version 3
If the deleteoldrdn field is TRUE, the attribute values forming the If the deleteoldrdn field is TRUE, the attribute values forming the
old RDN but not the new RDN are deleted from the entry. If the old RDN but not the new RDN are deleted from the entry. If the
deleteoldrdn field is FALSE, the attribute values forming the old RDN deleteoldrdn field is FALSE, the attribute values forming the old RDN
will be retained as non-distinguished attribute values of the entry. will be retained as non-distinguished attribute values of the entry.
The server MUST fail the operation and return an error in the result The server MUST fail the operation and return an error in the result
code if the setting of the deleteoldrdn field would cause a schema code if the setting of the deleteoldrdn field would cause a schema
inconsistency in the entry. inconsistency in the entry.
Sermersheim Internet-Draft - Expires Jul 2004 Page 29
Lightweight Directory Access Protocol Version 3
Note that X.500 restricts the ModifyDN operation to only affect Note that X.500 restricts the ModifyDN operation to only affect
entries that are contained within a single server. If the LDAP server entries that are contained within a single server. If the LDAP server
is mapped onto DAP, then this restriction will apply, and the is mapped onto DAP, then this restriction will apply, and the
affectsMultipleDSAs result code will be returned if this error affectsMultipleDSAs result code will be returned if this error
occurred. In general, clients MUST NOT expect to be able to perform occurred. In general, clients MUST NOT expect to be able to perform
arbitrary movements of entries and subtrees between servers or arbitrary movements of entries and subtrees between servers or
between naming contexts. between naming contexts.
4.10. Compare Operation 4.10. Compare Operation
skipping to change at line 1669 skipping to change at line 1678
indicates that the comparison of the assertion value in the ava field indicates that the comparison of the assertion value in the ava field
and the values of the attribute or subtype resulted in an Undefined and the values of the attribute or subtype resulted in an Undefined
(Section 4.5.1) or non-equivalent match. (Section 4.5.1) or non-equivalent match.
In the event that the attribute or subtype is not present in the In the event that the attribute or subtype is not present in the
entry, the resultCode field is set to noSuchAttribute. If the entry, the resultCode field is set to noSuchAttribute. If the
attribute is unknown, the resultCode is set to attribute is unknown, the resultCode is set to
undefinedAttributeType. If the attribute or subtype has no equality undefinedAttributeType. If the attribute or subtype has no equality
matching rule, innapropriateMatching is returned in the resultCode. matching rule, innapropriateMatching is returned in the resultCode.
Sermersheim Internet-Draft - Expires Aug 2004 Page 30
Lightweight Directory Access Protocol Version 3
Note that some directory systems may establish access controls which Note that some directory systems may establish access controls which
permit the values of certain attributes (such as userPassword) to be permit the values of certain attributes (such as userPassword) to be
compared but not interrogated by other means. compared but not interrogated by other means.
4.11. Abandon Operation 4.11. Abandon Operation
Sermersheim Internet-Draft - Expires Jul 2004 Page 30
Lightweight Directory Access Protocol Version 3
The function of the Abandon Operation is to allow a client to request The function of the Abandon Operation is to allow a client to request
that the server abandon an outstanding operation. The Abandon Request that the server abandon an outstanding operation. The Abandon Request
is defined as follows: is defined as follows:
AbandonRequest ::= [APPLICATION 16] MessageID AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID is that of an operation which was requested earlier in The MessageID is that of an operation which was requested earlier in
this LDAP association. The abandon request itself has its own message this LDAP association. The abandon request itself has its own message
id. This is distinct from the id of the earlier operation being id. This is distinct from the id of the earlier operation being
abandoned. abandoned.
skipping to change at line 1722 skipping to change at line 1731
Servers MUST discard abandon requests for message IDs they do not Servers MUST discard abandon requests for message IDs they do not
recognize, for operations which cannot be abandoned, and for recognize, for operations which cannot be abandoned, and for
operations which have already been abandoned. operations which have already been abandoned.
4.12. Extended Operation 4.12. Extended Operation
The extended operation allows additional operations to be defined for The extended operation allows additional operations to be defined for
services not already available in the protocol. For example, to add services not already available in the protocol. For example, to add
operations to install transport layer security (see Section 4.14). operations to install transport layer security (see Section 4.14).
Sermersheim Internet-Draft - Expires Aug 2004 Page 31
Lightweight Directory Access Protocol Version 3
The extended operation allows clients to make requests and receive The extended operation allows clients to make requests and receive
responses with predefined syntaxes and semantics. These may be responses with predefined syntaxes and semantics. These may be
defined in RFCs or be private to particular implementations. defined in RFCs or be private to particular implementations.
Each extended operation consists of an extended request and an Each extended operation consists of an extended request and an
extended response. extended response.
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
Sermersheim Internet-Draft - Expires Jul 2004 Page 31
Lightweight Directory Access Protocol Version 3
requestName [0] LDAPOID, requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL } requestValue [1] OCTET STRING OPTIONAL }
The requestName is a dotted-decimal representation of the unique The requestName is a dotted-decimal representation of the unique
OBJECT IDENTIFIER corresponding to the request. The requestValue is OBJECT IDENTIFIER corresponding to the request. The requestValue is
information in a form defined by that request, encapsulated inside an information in a form defined by that request, encapsulated inside an
OCTET STRING. OCTET STRING.
The server will respond to this with an LDAPMessage containing an The server will respond to this with an LDAPMessage containing an
ExtendedResponse. ExtendedResponse.
skipping to change at line 1780 skipping to change at line 1788
Extended operations may be specified in other documents. The Extended operations may be specified in other documents. The
specification of an extended operation consists of: specification of an extended operation consists of:
- the OBJECT IDENTIFIER assigned to the requestName (and possibly - the OBJECT IDENTIFIER assigned to the requestName (and possibly
responseName), responseName),
- the format of the contents of the requestValue and responseValue - the format of the contents of the requestValue and responseValue
(if any), and (if any), and
Sermersheim Internet-Draft - Expires Aug 2004 Page 32
Lightweight Directory Access Protocol Version 3
- the semantics of the operation. - the semantics of the operation.
4.13. IntermediateResponse Message 4.13. IntermediateResponse Message
While the Search operation provides a mechanism to return multiple While the Search operation provides a mechanism to return multiple
response messages for a single search request, other operations, by response messages for a single search request, other operations, by
nature, do not provide for multiple response messages. nature, do not provide for multiple response messages.
Sermersheim Internet-Draft - Expires Jul 2004 Page 32
Lightweight Directory Access Protocol Version 3
The IntermediateResponse message provides a general mechanism for The IntermediateResponse message provides a general mechanism for
defining single-request/multiple-response operations in LDAP. This defining single-request/multiple-response operations in LDAP. This
message is intended to be used in conjunction with the extended message is intended to be used in conjunction with the extended
operation to define new single-request/multiple-response operations operation to define new single-request/multiple-response operations
or in conjunction with a control when extending existing LDAP or in conjunction with a control when extending existing LDAP
operations in a way that requires them to return intermediate operations in a way that requires them to return intermediate
response information. response information.
It is intended that the definitions and descriptions of extended It is intended that the definitions and descriptions of extended
operations and controls that make use of the IntermediateResponse operations and controls that make use of the IntermediateResponse
skipping to change at line 1835 skipping to change at line 1843
inclusion of responseName and responseValue in IntermediateResponse inclusion of responseName and responseValue in IntermediateResponse
messages. messages.
4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
A single-request/multiple-response operation may be defined using a A single-request/multiple-response operation may be defined using a
single ExtendedRequest message to solicit zero or more single ExtendedRequest message to solicit zero or more
IntermediateResponse messages of one or more kinds followed by an IntermediateResponse messages of one or more kinds followed by an
ExtendedResponse message. ExtendedResponse message.
Sermersheim Internet-Draft - Expires Aug 2004 Page 33
Lightweight Directory Access Protocol Version 3
An extended operation that defines the return of multiple kinds of An extended operation that defines the return of multiple kinds of
IntermediateResponse messages MUST provide and document a mechanism IntermediateResponse messages MUST provide and document a mechanism
for the client to distinguish the kind of IntermediateResponse for the client to distinguish the kind of IntermediateResponse
message being sent. This SHALL be accomplished by using different message being sent. This SHALL be accomplished by using different
responseName values for each type of IntermediateResponse message responseName values for each type of IntermediateResponse message
associated with the extended operation or by including identifying associated with the extended operation or by including identifying
information in the responseValue of each type of IntermediateResponse information in the responseValue of each type of IntermediateResponse
message associated with the extended operation. message associated with the extended operation.
Sermersheim Internet-Draft - Expires Jul 2004 Page 33
Lightweight Directory Access Protocol Version 3
4.13.2. Usage with LDAP Request Controls 4.13.2. Usage with LDAP Request Controls
Any LDAP operation may be extended by the addition of one or more Any LDAP operation may be extended by the addition of one or more
controls ([RFC2251] Section 4.1.12). A control's semantics may controls ([RFC2251] Section 4.1.12). A control's semantics may
include the return of zero or more IntermediateResponse messages include the return of zero or more IntermediateResponse messages
prior to returning the final result code for the operation. One or prior to returning the final result code for the operation. One or
more kinds of IntermediateResponse messages may be sent in response more kinds of IntermediateResponse messages may be sent in response
to a request control. to a request control.
All IntermediateResponse messages associated with request controls All IntermediateResponse messages associated with request controls
skipping to change at line 1888 skipping to change at line 1896
The Start Transport Layer Security (StartTLS) operation provides the The Start Transport Layer Security (StartTLS) operation provides the
ability to establish Transport Layer Security ([TLS]) on an LDAP ability to establish Transport Layer Security ([TLS]) on an LDAP
connection. The StartTLS operation is defined using the extended connection. The StartTLS operation is defined using the extended
operation mechanism described in Section 4.12. operation mechanism described in Section 4.12.
4.14.1. StartTLS Request 4.14.1. StartTLS Request
A client requests TLS establishment by transmitting a StartTLS A client requests TLS establishment by transmitting a StartTLS
request PDU to the server. The StartTLS request is defined in terms request PDU to the server. The StartTLS request is defined in terms
Sermersheim Internet-Draft - Expires Aug 2004 Page 34
Lightweight Directory Access Protocol Version 3
of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037",
and the requestValue field is always absent. and the requestValue field is always absent.
The client MUST NOT send any PDUs on this connection following this The client MUST NOT send any PDUs on this connection following this
request until it receives a StartTLS extended response and completes request until it receives a StartTLS extended response and completes
TLS negotiations. TLS negotiations.
Sermersheim Internet-Draft - Expires Jul 2004 Page 34
Lightweight Directory Access Protocol Version 3
4.14.2. StartTLS Response 4.14.2. StartTLS Response
When a StartTLS request is made, servers supporting the operation When a StartTLS request is made, servers supporting the operation
MUST return a StartTLS response PDU to the requestor. The MUST return a StartTLS response PDU to the requestor. The
responseName is also "1.3.6.1.4.1.1466.20037", and the responseValue responseName is also "1.3.6.1.4.1.1466.20037", and the responseValue
field is absent. field is absent.
The server provides a resultCode field to either success or one of The server provides a resultCode field to either success or one of
the other values outlined in Section 4.14.2.2. the other values outlined in Section 4.14.2.2.
skipping to change at line 1941 skipping to change at line 1950
Section 4 of [AuthMeth]. Section 4 of [AuthMeth].
If the server does not support TLS (whether by design or by current If the server does not support TLS (whether by design or by current
configuration), it MUST return the protocolError resultCode. The configuration), it MUST return the protocolError resultCode. The
client's current association is unaffected if the server does not client's current association is unaffected if the server does not
support TLS. The client may proceed with any LDAP operation, or it support TLS. The client may proceed with any LDAP operation, or it
may close the connection. may close the connection.
The server MUST return unavailable if it supports TLS but cannot The server MUST return unavailable if it supports TLS but cannot
establish a TLS connection for some reason, e.g. the certificate establish a TLS connection for some reason, e.g. the certificate
Sermersheim Internet-Draft - Expires Aug 2004 Page 35
Lightweight Directory Access Protocol Version 3
server not responding, it cannot contact its TLS implementation, or server not responding, it cannot contact its TLS implementation, or
if the server is in process of shutting down. The client may retry if the server is in process of shutting down. The client may retry
the StartTLS operation, or it may proceed with any other LDAP the StartTLS operation, or it may proceed with any other LDAP
operation, or it may close the LDAP connection. operation, or it may close the LDAP connection.
4.14.3. Closing a TLS Connection 4.14.3. Closing a TLS Connection
Sermersheim Internet-Draft - Expires Jul 2004 Page 35
Lightweight Directory Access Protocol Version 3
Two forms of TLS connection closure -- graceful and abrupt -- are Two forms of TLS connection closure -- graceful and abrupt -- are
supported. These do not involve LDAP PDUs, but are preformed at the supported. These do not involve LDAP PDUs, but are preformed at the
underlying layers. underlying layers.
4.14.3.1. Graceful Closure 4.14.3.1. Graceful Closure
Either the client or server MAY terminate the TLS connection and Either the client or server MAY terminate the TLS connection and
leave the LDAP connection intact by sending and receiving a TLS leave the LDAP connection intact by sending and receiving a TLS
closure alert. closure alert.
skipping to change at line 1993 skipping to change at line 2003
4.14.3.2. Abrupt Closure 4.14.3.2. Abrupt Closure
Either the client or server MAY abruptly close the TLS connection by Either the client or server MAY abruptly close the TLS connection by
dropping the underlying transfer protocol connection. In this dropping the underlying transfer protocol connection. In this
circumstance, a server MAY send the client a Notice of Disconnection circumstance, a server MAY send the client a Notice of Disconnection
before dropping the underlying LDAP connection. Outstanding before dropping the underlying LDAP connection. Outstanding
operations are handled as specified in Section 5.2. operations are handled as specified in Section 5.2.
5. Protocol Element Encodings and Transfer 5. Protocol Element Encodings and Transfer
Sermersheim Internet-Draft - Expires Aug 2004 Page 36
Lightweight Directory Access Protocol Version 3
One underlying service, LDAP over TCP, is defined here. This service One underlying service, LDAP over TCP, is defined here. This service
is generally applicable to applications providing or consuming X.500- is generally applicable to applications providing or consuming X.500-
based directory services on the Internet. based directory services on the Internet.
Implementations of LDAP over TCP MUST implement the mapping as Implementations of LDAP over TCP MUST implement the mapping as
described in Section 5.2.1 described in Section 5.2.1
Sermersheim Internet-Draft - Expires Jul 2004 Page 36
Lightweight Directory Access Protocol Version 3
5.1. Protocol Encoding 5.1. Protocol Encoding
The protocol elements of LDAP SHALL be encoded for exchange using the The protocol elements of LDAP SHALL be encoded for exchange using the
Basic Encoding Rules [BER] of [ASN.1] with the following Basic Encoding Rules [BER] of [ASN.1] with the following
restrictions: restrictions:
- Only the definite form of length encoding is used. - Only the definite form of length encoding is used.
- OCTET STRING values are encoded in the primitive form only. - OCTET STRING values are encoded in the primitive form only.
skipping to change at line 2046 skipping to change at line 2056
client MUST NOT assume that any outstanding requests which modified client MUST NOT assume that any outstanding requests which modified
the Directory have succeeded or failed. the Directory have succeeded or failed.
5.2.1. Transmission Control Protocol (TCP) 5.2.1. Transmission Control Protocol (TCP)
The encoded LDAPMessage PDUs are mapped directly onto the [TCP] The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
bytestream using the BER-based encoding described in Section 5.1. It bytestream using the BER-based encoding described in Section 5.1. It
is recommended that server implementations running over the TCP is recommended that server implementations running over the TCP
provide a protocol listener on the Internet Assigned Numbers provide a protocol listener on the Internet Assigned Numbers
Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
Sermersheim Internet-Draft - Expires Aug 2004 Page 37
Lightweight Directory Access Protocol Version 3
instead provide a listener on a different port number. Clients MUST instead provide a listener on a different port number. Clients MUST
support contacting servers on any valid TCP port. support contacting servers on any valid TCP port.
6. Security Considerations 6. Security Considerations
This version of the protocol provides facilities for simple This version of the protocol provides facilities for simple
authentication using a cleartext password, as well as any [SASL] authentication using a cleartext password, as well as any [SASL]
Sermersheim Internet-Draft - Expires Jul 2004 Page 37
Lightweight Directory Access Protocol Version 3
mechanism. SASL allows for integrity and privacy services to be mechanism. SASL allows for integrity and privacy services to be
negotiated. negotiated.
It is also permitted that the server can return its credentials to It is also permitted that the server can return its credentials to
the client, if it chooses to do so. the client, if it chooses to do so.
Use of cleartext password is strongly discouraged where the Use of cleartext password is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and may underlying transport service cannot guarantee confidentiality and may
result in disclosure of the password to unauthorized parties. result in disclosure of the password to unauthorized parties.
skipping to change at line 2103 skipping to change at line 2113
control policies which prevent the return of entries or attributes in control policies which prevent the return of entries or attributes in
search results except to particular authenticated clients. For search results except to particular authenticated clients. For
example, caches could serve result information only to the client example, caches could serve result information only to the client
whose request caused it to be in the cache. whose request caused it to be in the cache.
Servers may return referrals or search result references which Servers may return referrals or search result references which
redirect clients to peer servers. It is possible for a rogue redirect clients to peer servers. It is possible for a rogue
application to inject such referrals into the data stream in an application to inject such referrals into the data stream in an
attempt to redirect a client to a rogue server. Clients are advised attempt to redirect a client to a rogue server. Clients are advised
to be aware of this, and possibly reject referrals when to be aware of this, and possibly reject referrals when
Sermersheim Internet-Draft - Expires Aug 2004 Page 38
Lightweight Directory Access Protocol Version 3
confidentiality measures are not in place. Clients are advised to confidentiality measures are not in place. Clients are advised to
reject referrals from the StartTLS operation. reject referrals from the StartTLS operation.
The matchedDN and diagnosticMessage fields, as well as some
resultCode values (e.g., attributeOrValueExists and
entryAlreadyExists), could disclose the presence the specific data in
the directory which is subject to access and other administrative
controls. Server implementations should restrict access to protected
information equally under both normal and error conditions.
Protocol peers MUST be prepared to handle invalid and arbitrary Protocol peers MUST be prepared to handle invalid and arbitrary
length protocol encodings. A number of LDAP security advisories are length protocol encodings. A number of LDAP security advisories are
available through [CERT]. available through [CERT].
Sermersheim Internet-Draft - Expires Jul 2004 Page 38
Lightweight Directory Access Protocol Version 3
7. Acknowledgements 7. Acknowledgements
This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
Kille. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, Kille. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan,
and Mark Wahl. Their work along with the input of individuals of the and Mark Wahl. It is also based on [LIMR] by Roger Harrison, and Kurt
IETF ASID, LDAPEXT, LDUP, LDAPBIS, and other Working Groups is Zeilenga. Notable amounts of technical reviews and content were
gratefully acknowledged. provided by Kurt Zeilenga, Steven Legg, and Hallvard Furuseth. Their
work along with the input of individuals of the IETF ASID, LDAPEXT,
LDUP, LDAPBIS, and other Working Groups is gratefully acknowledged.
8. Normative References 8. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
"Information Technology - Abstract Syntax Notation One "Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation" (ASN.1): Specification of basic notation"
skipping to change at line 2150 skipping to change at line 2170
[IP] Postel, J., "Internet Protocol", STD5 and RFC 791, [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
September 1981 September 1981
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993. : 1993.
[Keyword] Bradner, S., "Key words for use in RFCs to Indicate [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
Sermersheim Internet-Draft - Expires Aug 2004 Page 39
Lightweight Directory Access Protocol Version 3
[LDAPDN] Zeilenga, K., "LDAP: String Representation of [LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
work in progress). work in progress).
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf- [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
ldapbis-bcp64-xx.txt, (a work in progress). ldapbis-bcp64-xx.txt, (a work in progress).
[LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf- [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
ldapbis-url-xx.txt, (a work in progress). ldapbis-url-xx.txt, (a work in progress).
[LIMR] Harrison, R., and K. Zeilenga, "The Lightweight Directory [LIMR] Harrison, R., and K. Zeilenga, "The Lightweight Directory
Access Protocol (LDAP) Intermediate Response Message", Access Protocol (LDAP) Intermediate Response Message",
draft-rharrison-ldap-intermediate-resp-xx.txt (a work in draft-rharrison-ldap-intermediate-resp-xx.txt (a work in
progress). progress).
Sermersheim Internet-Draft - Expires Jul 2004 Page 39
Lightweight Directory Access Protocol Version 3
[Models] Zeilenga, K., "LDAP: Directory Information Models", draft- [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
ietf-ldapbis-models-xx.txt (a work in progress). ietf-ldapbis-models-xx.txt (a work in progress).
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
[SASL] Melnikov, A., "Simple Authentication and Security Layer", [SASL] Melnikov, A., "Simple Authentication and Security Layer",
draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress). draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
[SASLPrep] Zeilenga, K., "Stringprep profile for user names and [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
skipping to change at line 2207 skipping to change at line 2227
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the 3.1" (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
Sermersheim Internet-Draft - Expires Aug 2004 Page 40
Lightweight Directory Access Protocol Version 3
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD63 and RFC3629, November 2003. 10646", STD63 and RFC3629, November 2003.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993. Models and Service", 1993.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993. Definition", 1993.
9. Informative References 9. Informative References
[CERT] The CERT(R) Center, http://www.cert.org [CERT] The CERT(R) Center, http://www.cert.org
Sermersheim Internet-Draft - Expires Jul 2004 Page 40
Lightweight Directory Access Protocol Version 3
[PortReg] IANA, "Port Numbers", [PortReg] IANA, "Port Numbers",
http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/port-numbers
10. IANA Considerations 10. IANA Considerations
It is requested that the Internet Assigned Numbers Authority (IANA) It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP result code registry to indicate that this document update the LDAP result code registry to indicate that this document
provides the definitive technical specification for result codes 0- provides the definitive technical specification for result codes 0-
36, 48-54, 64-70, 80-90. 36, 48-54, 64-70, 80-90.
skipping to change at line 2252 skipping to change at line 2272
11. Editor's Address 11. Editor's Address
Jim Sermersheim Jim Sermersheim
Novell, Inc. Novell, Inc.
1800 South Novell Place 1800 South Novell Place
Provo, Utah 84606, USA Provo, Utah 84606, USA
jimse@novell.com jimse@novell.com
+1 801 861-3088 +1 801 861-3088
Sermersheim Internet-Draft - Expires Jul 2004 Page 41 Sermersheim Internet-Draft - Expires Aug 2004 Page 41
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
Appendix A - LDAP Result Codes Appendix A - LDAP Result Codes
This normative appendix details additional considerations regarding This normative appendix details additional considerations regarding
LDAP result codes and provides a brief, general description of each LDAP result codes and provides a brief, general description of each
LDAP result code enumerated in Section 4.1.9. LDAP result code enumerated in Section 4.1.9.
Additional result codes MAY be defined for use with extensions Additional result codes MAY be defined for use with extensions
[LDAPIANA]. Client implementations SHALL treat any result code which [LDAPIANA]. Client implementations SHALL treat any result code which
skipping to change at line 2307 skipping to change at line 2327
or if TLS was already established. or if TLS was already established.
protocolError (2) protocolError (2)
Indicates the server received data which has incorrect Indicates the server received data which has incorrect
structure. structure.
For bind operation only, this code is also used to indicate For bind operation only, this code is also used to indicate
that the server does not support the requested protocol that the server does not support the requested protocol
version. version.
Sermersheim Internet-Draft - Expires Jul 2004 Page 42 Sermersheim Internet-Draft - Expires Aug 2004 Page 42
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
timeLimitExceeded (3) timeLimitExceeded (3)
Indicates that the time limit specified by the client was Indicates that the time limit specified by the client was
exceeded before the operation could be completed. exceeded before the operation could be completed.
sizeLimitExceeded (4) sizeLimitExceeded (4)
Indicates that the size limit specified by the client was Indicates that the size limit specified by the client was
exceeded before the operation could be completed. exceeded before the operation could be completed.
skipping to change at line 2364 skipping to change at line 2384
authentication process (see Section 4.2). authentication process (see Section 4.2).
noSuchAttribute (16) noSuchAttribute (16)
Indicates that the named entry does not contain the specified Indicates that the named entry does not contain the specified
attribute or attribute value. attribute or attribute value.
undefinedAttributeType (17) undefinedAttributeType (17)
Indicates that a request field contains an unrecognized Indicates that a request field contains an unrecognized
attribute description. attribute description.
Sermersheim Internet-Draft - Expires Jul 2004 Page 43 Sermersheim Internet-Draft - Expires Aug 2004 Page 43
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
inappropriateMatching (18) inappropriateMatching (18)
Indicates that an attempt was made, e.g. in an assertion, to Indicates that an attempt was made, e.g. in an assertion, to
use a matching rule not defined for the attribute type use a matching rule not defined for the attribute type
concerned. concerned.
constraintViolation (19) constraintViolation (19)
Indicates that the client supplied an attribute value which Indicates that the client supplied an attribute value which
does not conform to the constraints placed upon it by the does not conform to the constraints placed upon it by the
skipping to change at line 2422 skipping to change at line 2442
provide some form of credentials. provide some form of credentials.
invalidCredentials (49) invalidCredentials (49)
Indicates that the provided credentials (e.g. the user's name Indicates that the provided credentials (e.g. the user's name
and password) are invalid. and password) are invalid.
insufficientAccessRights (50) insufficientAccessRights (50)
Indicates that the client does not have sufficient access Indicates that the client does not have sufficient access
rights to perform the operation. rights to perform the operation.
Sermersheim Internet-Draft - Expires Jul 2004 Page 44 Sermersheim Internet-Draft - Expires Aug 2004 Page 44
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
busy (51) busy (51)
Indicates that the server is too busy to service the Indicates that the server is too busy to service the
operation. operation.
unavailable (52) unavailable (52)
Indicates that the server is shutting down or a subsystem Indicates that the server is shutting down or a subsystem
necessary to complete the operation is offline. necessary to complete the operation is offline.
skipping to change at line 2474 skipping to change at line 2494
For example, this code is returned when a client attempts to For example, this code is returned when a client attempts to
modify the structural object class of an entry. modify the structural object class of an entry.
affectsMultipleDSAs (71) affectsMultipleDSAs (71)
Indicates that the operation cannot be completed as it Indicates that the operation cannot be completed as it
affects multiple servers (DSAs). affects multiple servers (DSAs).
other (80) other (80)
Indicates the server has encountered an internal error. Indicates the server has encountered an internal error.
Sermersheim Internet-Draft - Expires Jul 2004 Page 45 Sermersheim Internet-Draft - Expires Aug 2004 Page 45
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
Appendix B - Complete ASN.1 Definition Appendix B - Complete ASN.1 Definition
This appendix is normative. This appendix is normative.
Lightweight-Directory-Access-Protocol-V3 Lightweight-Directory-Access-Protocol-V3
-- Copyright (C) The Internet Society (2003). This version of -- Copyright (C) The Internet Society (2003). This version of
-- this ASN.1 module is part of RFC XXXX; see the RFC itself -- this ASN.1 module is part of RFC XXXX; see the RFC itself
-- for full legal notices. -- for full legal notices.
skipping to change at line 2532 skipping to change at line 2552
LDAPString ::= OCTET STRING -- UTF-8 encoded, LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters -- [ISO10646] characters
LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
LDAPDN ::= LDAPString -- Constrained to <distinguishedName> LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [LDAPDN] -- [LDAPDN]
RelativeLDAPDN ::= LDAPString -- Constrained to <name-component> RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
Sermersheim Internet-Draft - Expires Jul 2004 Page 46 Sermersheim Internet-Draft - Expires Aug 2004 Page 46
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
-- [LDAPDN] -- [LDAPDN]
AttributeDescription ::= LDAPString AttributeDescription ::= LDAPString
-- Constrained to <attributedescription> -- Constrained to <attributedescription>
-- [Models] -- [Models]
AttributeValue ::= OCTET STRING AttributeValue ::= OCTET STRING
skipping to change at line 2590 skipping to change at line 2610
attributeOrValueExists (20), attributeOrValueExists (20),
invalidAttributeSyntax (21), invalidAttributeSyntax (21),
-- 22-31 unused -- -- 22-31 unused --
noSuchObject (32), noSuchObject (32),
aliasProblem (33), aliasProblem (33),
invalidDNSyntax (34), invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf -- -- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36), aliasDereferencingProblem (36),
-- 37-47 unused -- -- 37-47 unused --
Sermersheim Internet-Draft - Expires Jul 2004 Page 47 Sermersheim Internet-Draft - Expires Aug 2004 Page 47
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
inappropriateAuthentication (48), inappropriateAuthentication (48),
invalidCredentials (49), invalidCredentials (49),
insufficientAccessRights (50), insufficientAccessRights (50),
busy (51), busy (51),
unavailable (52), unavailable (52),
unwillingToPerform (53), unwillingToPerform (53),
loopDetect (54), loopDetect (54),
-- 55-63 unused -- -- 55-63 unused --
skipping to change at line 2647 skipping to change at line 2667
... } ... }
SaslCredentials ::= SEQUENCE { SaslCredentials ::= SEQUENCE {
mechanism LDAPString, mechanism LDAPString,
credentials OCTET STRING OPTIONAL } credentials OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE { BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult, COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL } serverSaslCreds [7] OCTET STRING OPTIONAL }
Sermersheim Internet-Draft - Expires Jul 2004 Page 48 Sermersheim Internet-Draft - Expires Aug 2004 Page 48
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
UnbindRequest ::= [APPLICATION 2] NULL UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE { SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN, baseObject LDAPDN,
scope ENUMERATED { scope ENUMERATED {
baseObject (0), baseObject (0),
singleLevel (1), singleLevel (1),
wholeSubtree (2) }, wholeSubtree (2) },
skipping to change at line 2704 skipping to change at line 2724
MatchingRuleAssertion ::= SEQUENCE { MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL, matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL, type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue, matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE } dnAttributes [4] BOOLEAN DEFAULT FALSE }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE { SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN, objectName LDAPDN,
attributes PartialAttributeList } attributes PartialAttributeList }
Sermersheim Internet-Draft - Expires Jul 2004 Page 49 Sermersheim Internet-Draft - Expires Aug 2004 Page 49
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
PartialAttributeList ::= SEQUENCE OF PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute partialAttribute PartialAttribute
SearchResultReference ::= [APPLICATION 19] SEQUENCE SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI SIZE (1..MAX) OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult SearchResultDone ::= [APPLICATION 5] LDAPResult
skipping to change at line 2762 skipping to change at line 2782
AbandonRequest ::= [APPLICATION 16] MessageID AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID, requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL } requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE { ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult, COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL, responseName [10] LDAPOID OPTIONAL,
Sermersheim Internet-Draft - Expires Jul 2004 Page 50 Sermersheim Internet-Draft - Expires Aug 2004 Page 50
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
responseValue [11] OCTET STRING OPTIONAL } responseValue [11] OCTET STRING OPTIONAL }
END END
Sermersheim Internet-Draft - Expires Jul 2004 Page 51 Sermersheim Internet-Draft - Expires Aug 2004 Page 51
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
Appendix C - Changes Appendix C - Changes
This appendix is non-normative. This appendix is non-normative.
This appendix summarizes substantive changes made to RFC 2251 and RFC This appendix summarizes substantive changes made to RFC 2251 and RFC
2830. 2830.
C.1 Changes made to made to RFC 2251: C.1 Changes made to made to RFC 2251:
skipping to change at line 2819 skipping to change at line 2839
- There was a mandatory requirement for the server to return a - There was a mandatory requirement for the server to return a
Notice of Disconnection and drop the connection when a PDU is Notice of Disconnection and drop the connection when a PDU is
malformed in a certain way. This has been clarified such that the malformed in a certain way. This has been clarified such that the
server SHOULD return the Notice of Disconnection, and MUST drop server SHOULD return the Notice of Disconnection, and MUST drop
the connection. the connection.
C.1.5 Section 4.1.1.1 C.1.5 Section 4.1.1.1
- Clarified that the messageID of requests MUST be non-zero. - Clarified that the messageID of requests MUST be non-zero.
Sermersheim Internet-Draft - Expires Jul 2004 Page 52 Sermersheim Internet-Draft - Expires Aug 2004 Page 52
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
- Clarified when it is and isn't appropriate to return an already - Clarified when it is and isn't appropriate to return an already
used message id. RFC 2251 accidentally imposed synchronous server used message id. RFC 2251 accidentally imposed synchronous server
behavior in its wording of this. behavior in its wording of this.
C.1.6 Section 4.1.2 C.1.6 Section 4.1.2
- Stated that LDAPOID is constrained to <numericoid> from [Models]. - Stated that LDAPOID is constrained to <numericoid> from [Models].
skipping to change at line 2870 skipping to change at line 2890
C.1.12 Section 4.1.11 C.1.12 Section 4.1.11
- Defined referrals in terms of URIs rather than URLs. - Defined referrals in terms of URIs rather than URLs.
- Removed the requirement that all referral URIs MUST be equally - Removed the requirement that all referral URIs MUST be equally
capable of progressing the operation. The statement was ambiguous capable of progressing the operation. The statement was ambiguous
and provided no instructions on how to carry it out. and provided no instructions on how to carry it out.
- Added the requirement that clients MUST NOT loop between servers. - Added the requirement that clients MUST NOT loop between servers.
- Clarified the instructions for using LDAPURLs in referrals, and in - Clarified the instructions for using LDAPURLs in referrals, and in
doing so added a recommendation that the scope part be present. doing so added a recommendation that the scope part be present.
Sermersheim Internet-Draft - Expires Jul 2004 Page 53 Sermersheim Internet-Draft - Expires Aug 2004 Page 53
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
C.1.13 Section 4.1.12 C.1.13 Section 4.1.12
- Specified how control values defined in terms of ASN.1 are to be - Specified how control values defined in terms of ASN.1 are to be
encoded. encoded.
- Noted that the criticality field is only applied to request - Noted that the criticality field is only applied to request
messages (except unbindRequest), and must be ignored when present messages (except unbindRequest), and must be ignored when present
on response messages and unbindRequest. on response messages and unbindRequest.
- Added language regarding combinations of controls on a message. - Added language regarding combinations of controls on a message.
skipping to change at line 2920 skipping to change at line 2940
negotiations. If there were dependencies between multiple negotiations. If there were dependencies between multiple
negotiations of a particular mechanism, the mechanism technical negotiations of a particular mechanism, the mechanism technical
specification should detail how applications are to deal with specification should detail how applications are to deal with
them. LDAP should not require any special handling. And if an LDAP them. LDAP should not require any special handling. And if an LDAP
client had used such a mechanism, it would have the option of client had used such a mechanism, it would have the option of
using another mechanism. using another mechanism.
- Dropped MUST imperative in paragraph 3 to align with [Keywords]. - Dropped MUST imperative in paragraph 3 to align with [Keywords].
C.1.16 Section 4.2.3 C.1.16 Section 4.2.3
Sermersheim Internet-Draft - Expires Jul 2004 Page 54 Sermersheim Internet-Draft - Expires Aug 2004 Page 54
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
- Moved most error-related text to Appendix A, and added text - Moved most error-related text to Appendix A, and added text
regarding certain errors used in conjunction with the bind regarding certain errors used in conjunction with the bind
operation. operation.
- Prohibited the server from specifying serverSaslCreds when not - Prohibited the server from specifying serverSaslCreds when not
appropriate. appropriate.
C.1.17 Section 4.3 C.1.17 Section 4.3
skipping to change at line 2972 skipping to change at line 2992
knows they are ambiguous or may cause interoperability problems. knows they are ambiguous or may cause interoperability problems.
- Removed all mention of ExtendedResponse due to lack of - Removed all mention of ExtendedResponse due to lack of
implementation. implementation.
C.1.21 Section 4.5.3 C.1.21 Section 4.5.3
- Made changes similar to those made to Section 4.1.11. - Made changes similar to those made to Section 4.1.11.
C.1.22 Section 4.5.3.1 C.1.22 Section 4.5.3.1
Sermersheim Internet-Draft - Expires Jul 2004 Page 55 Sermersheim Internet-Draft - Expires Aug 2004 Page 55
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
- Fixed examples to adhere to changes made to Section 4.5.3. - Fixed examples to adhere to changes made to Section 4.5.3.
C.1.23 Section 4.6 C.1.23 Section 4.6
- Removed restriction that required an EQUALITY matching rule in - Removed restriction that required an EQUALITY matching rule in
order to perform value delete modifications. It is sufficiently order to perform value delete modifications. It is sufficiently
documented that in absence of an equality matching rule, octet documented that in absence of an equality matching rule, octet
equality is used. equality is used.
skipping to change at line 3022 skipping to change at line 3042
data consistency. data consistency.
C.1.27 Section 4.11 C.1.27 Section 4.11
- Explained that since abandon returns no response, clients should - Explained that since abandon returns no response, clients should
not use it if they need to know the outcome. not use it if they need to know the outcome.
- Specified that Abandon and Unbind cannot be abandoned. - Specified that Abandon and Unbind cannot be abandoned.
C.1.28 Section 4.12 C.1.28 Section 4.12
- Specified how values of extended operations defined in terms of Sermersheim Internet-Draft - Expires Aug 2004 Page 56
ASN.1 are to be encoded.
Sermersheim Internet-Draft - Expires Jul 2004 Page 56
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
- Specified how values of extended operations defined in terms of
ASN.1 are to be encoded.
- Added instructions on what extended operation specifications - Added instructions on what extended operation specifications
consist of. consist of.
- Added a recommendation that servers advertise supported extended - Added a recommendation that servers advertise supported extended
operations. operations.
C.1.29 Section 5.2 C.1.29 Section 5.2
- Moved referral-specific instructions into referral-related - Moved referral-specific instructions into referral-related
sections. sections.
skipping to change at line 3049 skipping to change at line 3068
- Reworded notes regarding SASL not protecting certain aspects of - Reworded notes regarding SASL not protecting certain aspects of
the LDAP bind PDU. the LDAP bind PDU.
- Noted that Servers are encouraged to prevent directory - Noted that Servers are encouraged to prevent directory
modifications by clients that have authenticated anonymously modifications by clients that have authenticated anonymously
[AuthMeth]. [AuthMeth].
- Added a note regarding the scenario where an identity is changed - Added a note regarding the scenario where an identity is changed
(deleted, privileges or credentials modified, etc.). (deleted, privileges or credentials modified, etc.).
- Warned against following referrals that may have been injected in - Warned against following referrals that may have been injected in
the data stream. the data stream.
- Noted that servers should protect information equally, whether in
an error condition or not, and mentioned specifically; matchedDN,
diagnosticMessage, and resultCodes.
- Added a note regarding malformed and long encodings. - Added a note regarding malformed and long encodings.
C.1.31 Appendix A C.1.31 Appendix A
- Added "EXTESIBILITY IMPLIED" to ASN.1 definition. - Added "EXTESIBILITY IMPLIED" to ASN.1 definition.
- Removed AttributeType. It is not used. - Removed AttributeType. It is not used.
C.2 Changes made to made to RFC 2830: C.2 Changes made to made to RFC 2830:
This section summarizes the substantive changes made to Sections of This section summarizes the substantive changes made to Sections of
skipping to change at line 3072 skipping to change at line 3094
C.2.1 Section 2.3 C.2.1 Section 2.3
- Removed wording indicating that referrals can be returned from - Removed wording indicating that referrals can be returned from
StartTLS StartTLS
- Removed requirement that only a narrow set of result codes can be - Removed requirement that only a narrow set of result codes can be
returned. Some result codes are required in certain scenarios, but returned. Some result codes are required in certain scenarios, but
any other may be returned if appropriate. any other may be returned if appropriate.
C.2.1 Section 4.13.3.1 C.2.1 Section 4.13.3.1
Sermersheim Internet-Draft - Expires Aug 2004 Page 57
Lightweight Directory Access Protocol Version 3
- Reworded most of this section and added the requirement that after - Reworded most of this section and added the requirement that after
the TLS connection has been closed, the server MUST NOT send the TLS connection has been closed, the server MUST NOT send
responses to any request message received before the TLS closure. responses to any request message received before the TLS closure.
Sermersheim Internet-Draft - Expires Jul 2004 Page 57
Lightweight Directory Access Protocol Version 3
C.3 Changes made to made to [LIMR]: C.3 Changes made to made to [LIMR]:
- In general, all technical language was transferred in whole. - In general, all technical language was transferred in whole.
Supporting and background language seen as redundant due to its Supporting and background language seen as redundant due to its
presence in this document was omitted. presence in this document was omitted.
Sermersheim Internet-Draft - Expires Jul 2004 Page 58 Sermersheim Internet-Draft - Expires Aug 2004 Page 58
Lightweight Directory Access Protocol Version 3 Lightweight Directory Access Protocol Version 3
Intellectual Property Rights Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
skipping to change at line 3138 skipping to change at line 3160
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Sermersheim Internet-Draft - Expires Jul 2004 Page 59 Sermersheim Internet-Draft - Expires Aug 2004 Page 59
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/