draft-ietf-ldapbis-protocol-08.txt | draft-ietf-ldapbis-protocol-09.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-08.txt June 2002 | Document: draft-ietf-ldapbis-protocol-09.txt Oct 2002 | |||
Obsoletes: RFC 2251 | Obsoletes: RFC 2251 | |||
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 | |||
Directory Access Protocol (DAP). | Directory Access Protocol (DAP). | |||
Table of Contents | Table of Contents | |||
1. Introduction.....................................................2 | 1. Introduction.....................................................2 | |||
2. Conventions......................................................3 | 2. Conventions......................................................3 | |||
3. Protocol Model...................................................3 | 3. Protocol Model...................................................3 | |||
4. Elements of Protocol.............................................3 | 4. Elements of Protocol.............................................3 | |||
4.1. Common Elements................................................4 | 4.1. Common Elements................................................4 | |||
4.1.1. Message Envelope.............................................4 | 4.1.1. Message Envelope.............................................4 | |||
4.1.1.1. Message ID.................................................5 | 4.1.2. String Types.................................................5 | |||
4.1.2. String Types.................................................6 | 4.1.3. Distinguished Name and Relative Distinguished Name...........6 | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 1 | Sermersheim Internet-Draft - Expires Apr 2003 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.4. Attribute Descriptions.......................................6 | 4.1.4. Attribute Descriptions.......................................6 | |||
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....................................................8 | 4.1.7. Attribute....................................................7 | |||
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................................................12 | 4.2. Bind Operation................................................12 | |||
4.2.1. Sequencing of the Bind Request..............................13 | ||||
4.2.2. Bind Response...............................................13 | ||||
4.3. Unbind Operation..............................................15 | 4.3. Unbind Operation..............................................15 | |||
4.4. Unsolicited Notification......................................15 | 4.4. Unsolicited Notification......................................15 | |||
4.4.1. Notice of Disconnection.....................................15 | ||||
4.5. Search Operation..............................................16 | 4.5. Search Operation..............................................16 | |||
4.5.1. Search Request..............................................16 | ||||
4.5.2. Search Result...............................................20 | ||||
4.5.3. Continuation References in the Search Result................21 | ||||
4.6. Modify Operation..............................................23 | 4.6. Modify Operation..............................................23 | |||
4.7. Add Operation.................................................24 | 4.7. Add Operation.................................................25 | |||
4.8. Delete Operation..............................................25 | 4.8. Delete Operation..............................................26 | |||
4.9. Modify DN Operation...........................................26 | 4.9. Modify DN Operation...........................................26 | |||
4.10. Compare Operation............................................27 | 4.10. Compare Operation............................................27 | |||
4.11. Abandon Operation............................................28 | 4.11. Abandon Operation............................................28 | |||
4.12. Extended Operation...........................................28 | 4.12. Extended Operation...........................................29 | |||
5. Protocol Element Encodings and Transfer.........................29 | 5. Protocol Element Encodings and Transfer.........................29 | |||
5.1. Protocol Encoding.............................................29 | 5.1. Protocol Encoding.............................................29 | |||
5.2. Transfer Protocols............................................29 | 5.2. Transfer Protocols............................................30 | |||
5.2.1. Transmission Control Protocol (TCP).........................30 | ||||
6. Implementation Guidelines.......................................30 | 6. Implementation Guidelines.......................................30 | |||
6.1. Server Implementations........................................30 | 6.1. Server Implementations........................................30 | |||
6.2. Client Implementations........................................30 | 6.2. Client Implementations........................................30 | |||
7. Security Considerations.........................................30 | 7. Security Considerations.........................................31 | |||
8. Acknowledgements................................................31 | 8. Acknowledgements................................................31 | |||
9. Normative References............................................31 | 9. Normative References............................................31 | |||
10. Editor's Address...............................................32 | 10. Editor's Address...............................................32 | |||
Appendix A - LDAP Result Codes.....................................33 | Appendix A - LDAP Result Codes.....................................33 | |||
A.1 Non-Error Result Codes.........................................33 | A.1 Non-Error Result Codes.........................................33 | |||
A.2 Error Result Codes.............................................33 | A.2 Error Result Codes.............................................33 | |||
A.3 Classes and Precedence of Error Result Codes...................33 | A.3 Classes and Precedence of Error Result Codes...................33 | |||
Appendix C - Change History........................................44 | Appendix C - Change History........................................44 | |||
C.1 Changes made to RFC 2251:......................................44 | C.1 Changes made to RFC 2251:......................................44 | |||
C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:............44 | C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:............44 | |||
C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:............45 | C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:............45 | |||
C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:............45 | C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:............45 | |||
C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:............47 | C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:............47 | |||
C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:............49 | C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:............49 | |||
C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:............49 | C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:............49 | |||
C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:............50 | C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:............50 | |||
C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:............53 | C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:............53 | |||
C.10 Changes made to draft-ietf-ldapbis-protocol-07.txt:...........53 | ||||
Appendix D - Outstanding Work Items................................53 | Appendix D - Outstanding Work Items................................53 | |||
1. Introduction | 1. Introduction | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 2 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
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 | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 2 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
(DSA)). Clients interact with servers using a directory access | (DSA)). Clients interact with servers using a directory access | |||
protocol. | protocol. | |||
This document details the protocol elements of Lightweight Directory | This document details the protocol elements of Lightweight Directory | |||
Access Protocol, along with their semantic meanings. Following the | Access Protocol, along with their semantic meanings. Following the | |||
description of protocol elements, it describes the way in which the | description of protocol elements, it describes the way in which the | |||
protocol is encoded and transferred. | protocol is encoded and transferred. | |||
This document is an integral part of the LDAP Technical Specification | This document is an integral part of the LDAP Technical Specification | |||
[Roadmap]. | [Roadmap]. | |||
skipping to change at line 165 | skipping to change at line 159 | |||
eventually receives a response for every request that requires one. | eventually receives a response for every request that requires one. | |||
Note that the core protocol operations defined in this document can | Note that the core protocol operations defined in this document can | |||
be mapped to a subset of the X.500(1997) directory abstract service. | be mapped to a subset of the X.500(1997) directory abstract service. | |||
However there is not a one-to-one mapping between LDAP protocol | However there is not a one-to-one mapping between LDAP protocol | |||
operations and DAP operations. Server implementations acting as a | operations and DAP operations. Server implementations acting as a | |||
gateway to X.500 directories may need to make multiple DAP requests. | gateway to X.500 directories may need to make multiple DAP requests. | |||
4. Elements of Protocol | 4. Elements of Protocol | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 3 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The LDAP protocol is described using Abstract Syntax Notation 1 | The LDAP protocol is described using Abstract Syntax Notation 1 | |||
(ASN.1) [X.680], and is transferred using a subset of ASN.1 Basic | (ASN.1) [X.680], and is transferred using a subset of ASN.1 Basic | |||
Encoding Rules [X.690]. Section 5.1 specifies how the protocol is | Encoding Rules [X.690]. Section 5.1 specifies how the protocol is | |||
encoded and transferred. | encoded and transferred. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 3 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
In order to support future Standards Track extensions to this | In order to support future Standards Track extensions to this | |||
protocol, extensibility is implied where it is allowed (per ASN.1). | protocol, extensibility is implied where it is allowed (per ASN.1). | |||
In addition, ellipses (...) have been supplied in ASN.1 types that | In addition, ellipses (...) have been supplied in ASN.1 types that | |||
are explicitly extensible as discussed in [LDAPIANA]. Because of the | are explicitly extensible as discussed in [LDAPIANA]. Because of the | |||
implied extensibility, clients and servers MUST ignore trailing | implied extensibility, clients and servers MUST ignore trailing | |||
SEQUENCE elements whose tags they do not recognize. | SEQUENCE elements whose tags they do not recognize. | |||
Changes to the LDAP protocol other than those described in [LDAPIANA] | Changes to the LDAP protocol other than those described in [LDAPIANA] | |||
Comment | ||||
: | ||||
I | ||||
s | ||||
t | ||||
h | ||||
i | ||||
s | ||||
t | ||||
r | ||||
u | ||||
e | ||||
? | ||||
require a different version number. A client indicates the version it | require a different version number. A client indicates the version it | |||
is using as part of the bind request, described in section 4.2. If a | 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 the client is | client has not sent a bind, the server MUST assume the client is | |||
using version 3 or later. | 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 | reading the supportedLDAPVersion attribute from the root DSE | |||
[Models]. Servers which implement version 3 or later MUST provide | [Models]. Servers which implement version 3 or later MUST provide | |||
this attribute. | this attribute. | |||
skipping to change at line 219 | skipping to change at line 229 | |||
searchRequest SearchRequest, | searchRequest SearchRequest, | |||
searchResEntry SearchResultEntry, | searchResEntry SearchResultEntry, | |||
searchResDone SearchResultDone, | searchResDone SearchResultDone, | |||
searchResRef SearchResultReference, | searchResRef SearchResultReference, | |||
modifyRequest ModifyRequest, | modifyRequest ModifyRequest, | |||
modifyResponse ModifyResponse, | modifyResponse ModifyResponse, | |||
addRequest AddRequest, | addRequest AddRequest, | |||
addResponse AddResponse, | addResponse AddResponse, | |||
delRequest DelRequest, | delRequest DelRequest, | |||
delResponse DelResponse, | delResponse DelResponse, | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 4 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
modDNRequest ModifyDNRequest, | modDNRequest ModifyDNRequest, | |||
modDNResponse ModifyDNResponse, | modDNResponse ModifyDNResponse, | |||
compareRequest CompareRequest, | compareRequest CompareRequest, | |||
compareResponse CompareResponse, | compareResponse CompareResponse, | |||
abandonRequest AbandonRequest, | abandonRequest AbandonRequest, | |||
extendedReq ExtendedRequest, | extendedReq ExtendedRequest, | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 4 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
extendedResp ExtendedResponse, | extendedResp ExtendedResponse, | |||
... }, | ... }, | |||
controls [0] Controls OPTIONAL } | controls [0] Controls OPTIONAL } | |||
MessageID ::= INTEGER (0 .. maxInt) | MessageID ::= INTEGER (0 .. maxInt) | |||
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- | maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- | |||
The function of the LDAPMessage is to provide an envelope containing | The function of the LDAPMessage is to provide an envelope containing | |||
common fields required in all protocol exchanges. At this time the | common fields required in all protocol exchanges. At this time the | |||
skipping to change at line 267 | skipping to change at line 277 | |||
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 session of | the values of any other requests outstanding in the LDAP session of | |||
which this message is a part. The zero value is reserved for the | which this message is a part. The zero value is reserved for the | |||
unsolicited notification message. | unsolicited notification message. | |||
A client MUST NOT send a second request with the same message ID as | Typical clients increment a counter for each request. | |||
an earlier request on the same connection if the client has not | ||||
received the final response from the earlier request. Otherwise the | ||||
behavior is undefined. Typical clients increment a counter for each | ||||
request. | ||||
A client MUST NOT reuse the message id of an abandonRequest or of the | ||||
abandoned operation until it has received a response from the server | ||||
Sermersheim Internet-Draft - Expires Dec 2002 Page 5 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
for another request invoked subsequent to the abandonRequest, as the | A client MUST NOT send a request with the same message ID as an | |||
abandonRequest itself does not have a response. | earlier request on the same connection unless it can be determined | |||
that the server is no longer servicing the earlier request. Otherwise | ||||
the behavior is undefined. For operations that do not return | ||||
responses (unbind, abandon, and abandoned operations), the client | ||||
SHOULD assumes the operation is in progress until a subsequent bind | ||||
request completes. | ||||
4.1.2. String Types | 4.1.2. String Types | |||
The LDAPString is a notational convenience to indicate that, although | The LDAPString is a notational convenience to indicate that, although | |||
strings of LDAPString type encode as OCTET STRING types, the | strings of LDAPString type encode as OCTET STRING types, the | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 5 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
[ISO10646] character set (a superset of Unicode) is used, encoded | [ISO10646] character set (a superset of Unicode) is used, encoded | |||
following the UTF-8 algorithm [RFC2044]. Note that in the UTF-8 | following the UTF-8 algorithm [RFC2044]. Note that in the UTF-8 | |||
algorithm characters which are the same as ASCII (0x0000 through | algorithm characters which are the same as ASCII (0x0000 through | |||
0x007F) are represented as that same ASCII character in a single | 0x007F) are represented as that same ASCII character in a single | |||
byte. The other byte values are used to form a variable-length | byte. The other byte values are used to form a variable-length | |||
encoding of an arbitrary character. | encoding of an arbitrary character. | |||
LDAPString ::= OCTET STRING -- UTF-8 encoded, | LDAPString ::= OCTET STRING -- UTF-8 encoded, | |||
-- ISO 10646 characters | -- ISO 10646 characters | |||
skipping to change at line 330 | skipping to change at line 339 | |||
4.1.4. Attribute Descriptions | 4.1.4. Attribute Descriptions | |||
The definition and encoding rules for attribute descriptions are | The definition and encoding rules for attribute descriptions are | |||
defined in Section 2.5 of [Models]. Briefly, an attribute description | defined in Section 2.5 of [Models]. Briefly, an attribute description | |||
is an attribute type and zero or more options. | is an attribute type and zero or more options. | |||
AttributeDescription ::= LDAPString | AttributeDescription ::= LDAPString | |||
-- Constrained to attributedescription | -- Constrained to attributedescription | |||
-- [Models] | -- [Models] | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 6 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Not all options can be associated with attributes held in the | Not all options can be associated with attributes held in the | |||
directory. A server will treat an AttributeDescription with any | directory. A server will treat an AttributeDescription with any | |||
options it does not implement or support as unrecognized. The order | options it does not implement or support as unrecognized. The order | |||
in which options appear in the list MUST NOT be used to impart any | in which options appear in the list MUST NOT be used to impart any | |||
semantic meaning. Servers MUST treat any two AttributeDescription | semantic meaning. Servers MUST treat any two AttributeDescription | |||
with the same attribute type and options as equivalent. | with the same attribute type and options as equivalent. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 6 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
AttributeDescriptionList describes a list of 0 or more attribute | AttributeDescriptionList describes a list of 0 or more attribute | |||
descriptions. (A list of zero elements has special significance in | descriptions. (A list of zero elements has special significance in | |||
the Search request.) | the Search request.) | |||
AttributeDescriptionList ::= SEQUENCE OF | AttributeDescriptionList ::= SEQUENCE OF | |||
AttributeDescription | AttributeDescription | |||
4.1.5. Attribute Value | 4.1.5. Attribute Value | |||
A field of type AttributeValue is an OCTET STRING containing an | A field of type AttributeValue is an OCTET STRING containing an | |||
skipping to change at line 384 | skipping to change at line 393 | |||
and a matching rule assertion value suitable for that type. | and a matching rule assertion value suitable for that type. | |||
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 | |||
operation being performed. For example, the syntax of the EQUALITY | operation being performed. For example, the syntax of the EQUALITY | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 7 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
matching rule for an attribute is used when performing a Compare | matching rule for an attribute is used when performing a Compare | |||
operation. Often this is the same syntax used for values of the | operation. Often this is the same syntax used for values of the | |||
attribute type, but in some cases the assertion syntax differs from | attribute type, but in some cases the assertion syntax differs from | |||
the value syntax. See objectIdentiferFirstComponentMatch in | the value syntax. See objectIdentiferFirstComponentMatch in | |||
[Syntaxes] for an example. | [Syntaxes] for an example. | |||
4.1.7. Attribute | 4.1.7. Attribute | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 7 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
An attribute consists of an attribute description and one or more | An attribute consists of an attribute description and one or more | |||
values of that attribute description. (Though attributes MUST have at | values of that attribute description. (Though attributes MUST have at | |||
least one value when stored, due to access control restrictions the | least one value when stored, due to access control restrictions the | |||
set may be empty when transferred from the server to the client. This | set may be empty when transferred from the server to the client. This | |||
is described in section 4.5.2, concerning the PartialAttributeList | is described in section 4.5.2, concerning the PartialAttributeList | |||
type.) | type.) | |||
Attribute ::= SEQUENCE { | Attribute ::= SEQUENCE { | |||
type AttributeDescription, | type AttributeDescription, | |||
vals SET OF AttributeValue } | vals SET OF AttributeValue } | |||
skipping to change at line 425 | skipping to change at line 433 | |||
either its numericoid, or one of its short name descriptors, e.g. | either its numericoid, or one of its short name descriptors, e.g. | |||
"caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33". | "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33". | |||
MatchingRuleId ::= LDAPString | MatchingRuleId ::= LDAPString | |||
Servers which support matching rules for use in the extensibleMatch | Servers which support matching rules for use in the extensibleMatch | |||
search filter MUST list the matching rules they implement in | search filter MUST list the matching rules they implement in | |||
subschema entries, using the matchingRules attributes. The server | subschema entries, using the matchingRules attributes. The server | |||
SHOULD also list there, using the matchingRuleUse attribute, the | SHOULD also list there, using the matchingRuleUse attribute, the | |||
attribute types with which each matching rule can be used. More | attribute types with which each matching rule can be used. More | |||
Comment | ||||
: | ||||
mov | ||||
e | ||||
t | ||||
o | ||||
mo | ||||
d | ||||
e | ||||
l | ||||
s | ||||
information is given in section 4.5 of [Syntaxes]. | information is given in section 4.5 of [Syntaxes]. | |||
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 LDAPResponse to indicate the final | containing the components of LDAPResponse to indicate the final | |||
status of a protocol operation request. | status of a protocol operation request. | |||
LDAPResult ::= SEQUENCE { | LDAPResult ::= SEQUENCE { | |||
resultCode ENUMERATED { | resultCode ENUMERATED { | |||
success (0), | success (0), | |||
operationsError (1), | operationsError (1), | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 8 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
protocolError (2), | protocolError (2), | |||
timeLimitExceeded (3), | timeLimitExceeded (3), | |||
sizeLimitExceeded (4), | sizeLimitExceeded (4), | |||
compareFalse (5), | compareFalse (5), | |||
compareTrue (6), | compareTrue (6), | |||
authMethodNotSupported (7), | authMethodNotSupported (7), | |||
strongAuthRequired (8), | strongAuthRequired (8), | |||
-- 9 reserved -- | -- 9 reserved -- | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 8 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
referral (10), | referral (10), | |||
adminLimitExceeded (11), | adminLimitExceeded (11), | |||
unavailableCriticalExtension (12), | unavailableCriticalExtension (12), | |||
confidentialityRequired (13), | confidentialityRequired (13), | |||
saslBindInProgress (14), | saslBindInProgress (14), | |||
noSuchAttribute (16), | noSuchAttribute (16), | |||
undefinedAttributeType (17), | undefinedAttributeType (17), | |||
inappropriateMatching (18), | inappropriateMatching (18), | |||
constraintViolation (19), | constraintViolation (19), | |||
attributeOrValueExists (20), | attributeOrValueExists (20), | |||
skipping to change at line 497 | skipping to change at line 518 | |||
... }, | ... }, | |||
-- 81-90 reserved for APIs -- | -- 81-90 reserved for APIs -- | |||
matchedDN LDAPDN, | matchedDN LDAPDN, | |||
errorMessage LDAPString, | errorMessage LDAPString, | |||
referral [3] Referral OPTIONAL } | referral [3] Referral OPTIONAL } | |||
The result codes enumeration is extensible as defined in Section 3.5 | The result codes enumeration is extensible as defined in Section 3.5 | |||
of [LDAPIANA]. The meanings of the result codes are given in Appendix | of [LDAPIANA]. The meanings of the result codes are given in Appendix | |||
A. | A. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 9 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The errorMessage field of this construct may, at the server's option, | The errorMessage field of this construct may, at the server's option, | |||
be used to return a string containing a textual, human-readable | be used to return a string containing a textual, human-readable | |||
(terminal control and page formatting characters should be avoided) | (terminal control and page formatting characters should be avoided) | |||
error diagnostic. As this error diagnostic is not standardized, | error diagnostic. As this error diagnostic is not standardized, | |||
implementations MUST NOT rely on the values returned. If the server | implementations MUST NOT rely on the values returned. If the server | |||
chooses not to return a textual diagnostic, the errorMessage field of | chooses not to return a textual diagnostic, the errorMessage field of | |||
the LDAPResult type MUST contain a zero length string. | the LDAPResult type MUST contain a zero length string. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 9 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
For result codes of noSuchObject, aliasProblem, invalidDNSyntax and | For result codes of noSuchObject, aliasProblem, invalidDNSyntax and | |||
aliasDereferencingProblem, the matchedDN field is set to the name of | aliasDereferencingProblem, the matchedDN field is set to the name of | |||
the lowest entry (object or alias) in the directory that was matched. | the lowest entry (object or alias) in the directory that was matched. | |||
If no aliases were dereferenced while attempting to locate the entry, | If no aliases were dereferenced while attempting to locate the entry, | |||
this will be a truncated form of the name provided, or if aliases | this will be a truncated form of the name provided, or if aliases | |||
were dereferenced, of the resulting name, as defined in section 12.5 | were dereferenced, of the resulting name, as defined in section 12.5 | |||
of [X.511]. The matchedDN field contains a zero length string with | of [X.511]. The matchedDN field contains a zero length string with | |||
all other result codes. | all other result codes. | |||
4.1.10. Referral | 4.1.10. Referral | |||
skipping to change at line 553 | skipping to change at line 574 | |||
present, the client assumes that any URL may be used to progress the | present, the client assumes that any URL may be used to progress the | |||
operation. | operation. | |||
URLs for servers implementing the LDAP protocol are written according | URLs for servers implementing the LDAP protocol are written according | |||
to [LDAPDN]. If an alias was dereferenced, the <dn> part of the URL | to [LDAPDN]. If an alias was dereferenced, the <dn> part of the URL | |||
MUST be present, with the new target object name. If the <dn> part is | MUST be present, with the new target object name. If the <dn> part is | |||
present, the client MUST use this name in its next request to | present, the client MUST use this name in its next request to | |||
progress the operation, and if it is not present the client will use | progress the operation, and if it is not present the client will use | |||
the same name as in the original request. Some servers (e.g. | the same name as in the original request. Some servers (e.g. | |||
participating in distributed indexing) may provide a different filter | participating in distributed indexing) may provide a different filter | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 10 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
in a referral for a search operation. If the filter part of the URL | in a referral for a search operation. If the filter part of the URL | |||
is present in an LDAPURL, the client MUST use this filter in its next | is present in an LDAPURL, the client MUST use this filter in its next | |||
request to progress this search, and if it is not present the client | request to progress this search, and if it is not present the client | |||
MUST use the same filter as it used for that search. Other aspects of | MUST use the same filter as it used for that search. Other aspects of | |||
the new request may be the same or different as the request which | the new request may be the same or different as the request which | |||
generated the referral. | generated the referral. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 10 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Note that UTF-8 characters appearing in a DN or search filter may not | Note that UTF-8 characters appearing in a DN or search filter may not | |||
be legal for URLs (e.g. spaces) and MUST be escaped using the % | be legal for URLs (e.g. spaces) and MUST be escaped using the % | |||
method in [RFC2396]. | method in [RFC2396]. | |||
Other kinds of URLs may be returned, so long as the operation could | Other kinds of URLs may be returned, so long as the operation could | |||
be performed using that protocol. | be performed using that protocol. | |||
4.1.11. Controls | 4.1.11. Controls | |||
A control is a way to specify extension information. Controls which | A control is a way to specify extension information for an LDAP | |||
are sent as part of a request apply only to that request and are not | message. A control only alters the semantics of the message it is | |||
saved. | attached to. | |||
Controls ::= SEQUENCE OF Control | Controls ::= SEQUENCE OF 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 MUST be a UTF-8 encoded dotted-decimal | The controlType field MUST be a UTF-8 encoded dotted-decimal | |||
representation of an OBJECT IDENTIFIER which uniquely identifies the | representation of an OBJECT IDENTIFIER which uniquely identifies the | |||
control. This prevents conflicts between control names. | control. This prevents conflicts between control names. | |||
The criticality field is either TRUE or FALSE and is only used when a | The criticality field is either TRUE or FALSE and only applies to | |||
control accompanies one of the following requests: bindRequest, | request messages that have a corresponding response message. For all | |||
searchRequest, modifyRequest, addRequest, delRequest, modDNRequest, | other messages (such as abandonRequest, unbindRequest and all | |||
compareRequest, or extendedReq. The use of the criticality field for | response messages), the criticality field is treated as FALSE. | |||
a control that is part of any other operation is ignored and treated | ||||
as FALSE. | ||||
If the server recognizes the control type and it is appropriate for | If the server recognizes the control type and it is appropriate for | |||
the operation, the server will make use of the control when | the operation, the server will make use of the control when | |||
performing the operation. | performing the operation. | |||
If the server does not recognize the control type or it is not | If the server does not recognize the control type or it is not | |||
appropriate for the operation, and the criticality field is TRUE, the | appropriate for the operation, and the criticality field is TRUE, the | |||
server MUST NOT perform the operation, and MUST instead return the | server MUST NOT perform the operation, and MUST instead return the | |||
resultCode unavailableCriticalExtension. | resultCode unavailableCriticalExtension. | |||
If the control is unrecognized or inappropriate but the criticality | If the control is unrecognized or inappropriate but the criticality | |||
field is FALSE, the server MUST ignore the control. | field is FALSE, the server MUST ignore the control. | |||
The controlValue contains any information associated with the | The controlValue contains any information associated with the | |||
control, and its format is defined for the control. Implementations | control, and its format is defined for the control. Implementations | |||
MUST be prepared to handle arbitrary contents of the controlValue | MUST be prepared to handle arbitrary contents of the controlValue | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 11 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
octet string, including zero bytes. It is absent only if there is no | octet string, including zero bytes. It is absent only if there is no | |||
value information which is associated with a control of its type. | value information which is associated with a control of its type. | |||
This document does not define any controls. Controls may be defined | This document does not specify any controls. Controls may be | |||
in other documents. The definition of a control consists of: | specified in other documents. The specification of a control consists | |||
of: | ||||
- the OBJECT IDENTIFIER assigned to the control, | - the OBJECT IDENTIFIER assigned to the control, | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 11 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- whether the control is always noncritical, always critical, or | - whether the control is always noncritical, always critical, or | |||
critical at the client's option, | critical at the client's option, | |||
- the format of the controlValue contents of the control. | - the format of the controlValue contents of the control, | |||
Servers list the controlType of all recognized controls in the | - the semantics of the control, | |||
supportedControl attribute in the root DSE. | ||||
- and optionally, semantics regarding the combination of the control | ||||
with other controls. | ||||
Servers list the controlType of all controls they recognize in the | ||||
supportedControl attribute [Models] in the root DSE. | ||||
Controls should not be combined unless the semantics of the | ||||
combination has been specified. The semantics of control | ||||
combinations, if specified, are generally found in the control | ||||
specification most recently published. In the absence of combination | ||||
semantics, the behavior of the operation is undefined. | ||||
Additionally, the order of a combination of controls in the SEQUENCE | ||||
is ignored unless the control specification(s) describe(s) | ||||
combination semantics. | ||||
4.2. Bind Operation | 4.2. Bind Operation | |||
The function of the Bind Operation is to allow authentication | The function of the Bind Operation is to allow authentication | |||
information to be exchanged between the client and server. Prior to | information to be exchanged between the client and server. Prior to | |||
the BindRequest, the implied identity is anonymous. Refer to | the BindRequest, the implied identity is anonymous. Refer to | |||
[AuthMeth] for the authentication-related semantics of this | [AuthMeth] for the authentication-related semantics of this | |||
operation. | operation. | |||
The Bind Request is defined as follows: | The Bind Request is defined as follows: | |||
skipping to change at line 661 | skipping to change at line 693 | |||
SaslCredentials ::= SEQUENCE { | SaslCredentials ::= SEQUENCE { | |||
mechanism LDAPString, | mechanism LDAPString, | |||
credentials OCTET STRING OPTIONAL } | credentials OCTET STRING OPTIONAL } | |||
Parameters of the Bind Request are: | Parameters 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 protocol session. This document describes | to be used in this protocol session. This document describes | |||
version 3 of the LDAP protocol. Note that there is no version | version 3 of the LDAP protocol. Note that there is no version | |||
negotiation, and the client just sets this parameter to the | negotiation, and the client just sets this parameter to the | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 12 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
version it desires. If the server does not support the specified | version it desires. If the server does not support the specified | |||
version, it responds with protocolError in the resultCode field of | version, it responds with protocolError in the resultCode field of | |||
the BindResponse. | the BindResponse. | |||
- 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 | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 12 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
string) for the purposes of anonymous binds, when authentication | string) for the purposes of anonymous binds, when authentication | |||
has been performed at a lower layer, or when using SASL | has been performed at a lower layer, or when using SASL | |||
credentials with a mechanism that includes the name in the | credentials with a mechanism that includes the name in the | |||
credentials. Server behavior is undefined when the name is a null | credentials. Server behavior is undefined when the name is a null | |||
value, simple authentication is used, and a password is specified. | value, simple authentication is used, and a password is specified. | |||
The server SHOULD NOT perform any alias dereferencing in | The server SHOULD NOT perform any alias dereferencing in | |||
determining the object to bind as. | determining the object to bind as. | |||
- authentication: information used to authenticate the name, if any, | - authentication: information used to authenticate the name, if any, | |||
provided in the Bind Request. This type is extensible as defined | provided in the Bind Request. This type is extensible as defined | |||
skipping to change at line 717 | skipping to change at line 749 | |||
If the client sends a BindRequest with the sasl mechanism field as an | If the client sends a BindRequest with the sasl mechanism field as an | |||
empty string, the server MUST return a BindResponse with | empty string, the server MUST return a BindResponse with | |||
authMethodNotSupported as the resultCode. This will allow clients to | authMethodNotSupported as the resultCode. This will allow clients to | |||
abort a negotiation if it wishes to try again with the same SASL | abort a negotiation if it wishes to try again with the same SASL | |||
mechanism. | mechanism. | |||
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, it may then send a Bind Request. If this also fails | operationsError, it may then send a Bind Request. If this also fails | |||
or the client chooses not to bind on the existing connection, it will | or the client chooses not to bind on the existing connection, it will | |||
close the connection, reopen it and begin again by first sending a | close the connection, reopen it and begin again by first sending a | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 13 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
PDU with a Bind Request. This will aid in interoperating with servers | PDU with a Bind Request. This will aid in interoperating with servers | |||
implementing other versions of LDAP. | implementing other versions of LDAP. | |||
4.2.2. Bind Response | 4.2.2. Bind Response | |||
The Bind Response is defined as follows. | The Bind Response is defined as follows. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 13 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
BindResponse ::= [APPLICATION 1] SEQUENCE { | BindResponse ::= [APPLICATION 1] SEQUENCE { | |||
COMPONENTS OF LDAPResult, | COMPONENTS OF LDAPResult, | |||
serverSaslCreds [7] OCTET STRING OPTIONAL } | serverSaslCreds [7] OCTET STRING OPTIONAL } | |||
BindResponse consists simply of an indication from the server of the | BindResponse consists simply of an indication from the server of the | |||
status of the client's request for authentication. | status of the client's request for authentication. | |||
If the bind was successful, the resultCode will be success, otherwise | If the bind was successful, the resultCode will be success, otherwise | |||
it will be one of: | Comment | |||
: | ||||
Re | ||||
c | ||||
o | ||||
n | ||||
c | ||||
i | ||||
l | ||||
e | ||||
w | ||||
i | ||||
t | ||||
h | ||||
r | ||||
e | ||||
s | ||||
u | ||||
l | ||||
t | ||||
c | ||||
o | ||||
d | ||||
e | ||||
s | ||||
it MAY be one of: | ||||
d | ||||
r | ||||
a | ||||
f | ||||
t | ||||
. | ||||
- operationsError: server encountered an internal error. | - operationsError: server encountered an internal error. | |||
- protocolError: unrecognized version number or incorrect PDU | - protocolError: unrecognized version number or incorrect PDU | |||
structure. | structure. | |||
- authMethodNotSupported: unrecognized SASL mechanism name. | - authMethodNotSupported: unrecognized SASL mechanism name. | |||
- strongAuthRequired: the server requires authentication be | - strongAuthRequired: the server requires authentication be | |||
performed with a SASL mechanism. | performed with a SASL mechanism. | |||
skipping to change at line 772 | skipping to change at line 841 | |||
If the server does not support the client's requested protocol | If the server does not support the client's requested protocol | |||
version, it MUST set the resultCode to protocolError. | version, it MUST set the resultCode to protocolError. | |||
If the client receives a BindResponse response where the resultCode | If the client receives a BindResponse response where the resultCode | |||
was protocolError, it MUST close the connection as the server will be | was protocolError, it MUST close the connection as the server will be | |||
unwilling to accept further operations. (This is for compatibility | unwilling to accept further operations. (This is for compatibility | |||
with earlier versions of LDAP, in which the bind was always the first | with earlier versions of LDAP, in which the bind was always the first | |||
operation, and there was no negotiation.) | operation, and there was no negotiation.) | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 14 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The serverSaslCreds are used as part of a SASL-defined bind mechanism | The serverSaslCreds are used as part of a SASL-defined bind mechanism | |||
to allow the client to authenticate the server to which it is | to allow the client to authenticate the server to which it is | |||
communicating, or to perform "challenge-response" authentication. If | communicating, or to perform "challenge-response" authentication. If | |||
the client bound with the simple choice, or the SASL mechanism does | the client bound with the simple choice, or the SASL mechanism does | |||
not require the server to return information to the client, then this | not require the server to return information to the client, then this | |||
field is not to be included in the result. | field is not to be included in the result. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 14 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
4.3. Unbind Operation | 4.3. Unbind Operation | |||
The function of the Unbind Operation is to terminate a protocol | The function of the Unbind Operation is to terminate a protocol | |||
session. The Unbind Operation is defined as follows: | session. The Unbind Operation is defined as follows: | |||
UnbindRequest ::= [APPLICATION 2] NULL | UnbindRequest ::= [APPLICATION 2] NULL | |||
The Unbind Operation has no response defined. Upon transmission of an | The Unbind Operation has no response defined. Upon transmission of an | |||
UnbindRequest, a protocol client MUST assume that the protocol | UnbindRequest, a protocol client MUST assume that the protocol | |||
session is terminated. Upon receipt of an UnbindRequest, a protocol | session is terminated. Upon receipt of an UnbindRequest, a protocol | |||
skipping to change at line 826 | skipping to change at line 895 | |||
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. Note that this notification is NOT a response to an unbind | condition. Note that this notification is NOT a response to an unbind | |||
requested by the client: the server MUST follow the procedures of | requested by the client: the server MUST follow the procedures of | |||
section 4.3. This notification is intended to assist clients in | section 4.3. This notification is intended to assist clients in | |||
distinguishing between an error condition and a transient network | distinguishing between an error condition and a transient network | |||
failure. As with a connection close due to network failure, the | failure. As with a connection close due to network failure, the | |||
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. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 15 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
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. | |||
Comment | ||||
: | ||||
mov | ||||
e | ||||
t | ||||
o | ||||
r | ||||
e | ||||
s | ||||
u | ||||
l | ||||
t | ||||
c | ||||
o | ||||
d | ||||
e | ||||
The following resultCode values are to be used in this notification: | The following resultCode values are to be used in this notification: | |||
a | ||||
p | ||||
p | ||||
e | ||||
n | ||||
d | ||||
i | ||||
x | ||||
? | ||||
- protocolError: The server has received data from the client in | - protocolError: The server has received data from the client in | |||
which the LDAPMessage structure could not be parsed. | which the LDAPMessage structure could not be parsed. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 15 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- strongAuthRequired: The server has detected that an established | - strongAuthRequired: The server has detected that an established | |||
underlying security association protecting communication between | underlying security association protecting communication between | |||
the client and server has unexpectedly failed or been compromised. | the client and server has unexpectedly failed or been compromised. | |||
- unavailable: This server will stop accepting new connections and | - unavailable: This server will stop accepting new connections and | |||
operations on all existing connections, and be unavailable for an | operations on all existing connections, and be unavailable for an | |||
extended period of time. The client may make use of an alternative | extended period of time. The client may make use of an alternative | |||
server. | server. | |||
After sending this notice, the server MUST close the connection. | After sending this notice, the server MUST close the connection. | |||
skipping to change at line 881 | skipping to change at line 980 | |||
derefFindingBaseObj (2), | derefFindingBaseObj (2), | |||
derefAlways (3) }, | derefAlways (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 AttributeDescriptionList } | attributes AttributeDescriptionList } | |||
Filter ::= CHOICE { | Filter ::= CHOICE { | |||
and [0] SET SIZE (1..MAX) OF Filter, | and [0] SET SIZE (1..MAX) OF Filter, | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 16 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
or [1] SET SIZE (1..MAX) OF Filter, | or [1] SET SIZE (1..MAX) OF Filter, | |||
not [2] Filter, | not [2] Filter, | |||
equalityMatch [3] AttributeValueAssertion, | equalityMatch [3] AttributeValueAssertion, | |||
substrings [4] SubstringFilter, | substrings [4] SubstringFilter, | |||
greaterOrEqual [5] AttributeValueAssertion, | greaterOrEqual [5] AttributeValueAssertion, | |||
lessOrEqual [6] AttributeValueAssertion, | lessOrEqual [6] AttributeValueAssertion, | |||
present [7] AttributeDescription, | present [7] AttributeDescription, | |||
approxMatch [8] AttributeValueAssertion, | approxMatch [8] AttributeValueAssertion, | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 16 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
extensibleMatch [9] MatchingRuleAssertion } | extensibleMatch [9] MatchingRuleAssertion } | |||
SubstringFilter ::= SEQUENCE { | SubstringFilter ::= SEQUENCE { | |||
type AttributeDescription, | type AttributeDescription, | |||
-- at least one must be present, | -- at least one must be present, | |||
-- initial and final can occur at most once | -- initial and final can occur at most once | |||
substrings SEQUENCE OF CHOICE { | substrings SEQUENCE OF CHOICE { | |||
initial [0] AssertionValue, | initial [0] AssertionValue, | |||
any [1] AssertionValue, | any [1] AssertionValue, | |||
final [2] AssertionValue } } | final [2] AssertionValue } } | |||
skipping to change at line 928 | skipping to change at line 1027 | |||
- derefAliases: An indicator as to how alias objects (as defined in | - derefAliases: An indicator as to how alias objects (as defined in | |||
X.501) are to be handled in searching. The semantics of the | X.501) 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 | neverDerefAliases: do not dereference aliases in searching | |||
or in locating the base object of the search; | or in locating the base object of the search; | |||
derefInSearching: dereference aliases in subordinates of | derefInSearching: dereference aliases in subordinates of | |||
the base object in searching, but not in locating the base | the base object in searching, but not in locating the base | |||
Comment | ||||
: | ||||
When | ||||
s | ||||
c | ||||
o | ||||
p | ||||
e | ||||
i | ||||
s | ||||
b | ||||
a | ||||
s | ||||
e | ||||
o | ||||
r | ||||
object of the search; | object of the search; | |||
s | ||||
u | ||||
b | ||||
t | ||||
r | ||||
e | ||||
e | ||||
, | ||||
t | ||||
h | ||||
e | ||||
b | ||||
a | ||||
s | ||||
e | ||||
o | ||||
b | ||||
j | ||||
e | ||||
c | ||||
t | ||||
i | ||||
s | ||||
b | ||||
o | ||||
t | ||||
h | ||||
l | ||||
o | ||||
c | ||||
a | ||||
t | ||||
e | ||||
d | ||||
, | ||||
a | ||||
n | ||||
d | ||||
s | ||||
e | ||||
a | ||||
r | ||||
c | ||||
h | ||||
e | ||||
d | ||||
. | ||||
" | ||||
s | ||||
u | ||||
b | ||||
o | ||||
r | ||||
d | ||||
i | ||||
n | ||||
a | ||||
t | ||||
e | ||||
s | ||||
" | ||||
p | ||||
r | ||||
e | ||||
v | ||||
e | ||||
n | ||||
t | ||||
s | ||||
derefFindingBaseObj: dereference aliases in locating the | derefFindingBaseObj: dereference aliases in locating the | |||
t | ||||
h | ||||
i | ||||
s | ||||
o | ||||
b | ||||
j | ||||
e | ||||
c | ||||
t | ||||
f | ||||
r | ||||
om | ||||
b | ||||
e | ||||
i | ||||
n | ||||
g | ||||
d | ||||
e | ||||
r | ||||
e | ||||
f | ||||
e | ||||
r | ||||
e | ||||
n | ||||
c | ||||
e | ||||
d | ||||
wh | ||||
i | ||||
l | ||||
e | ||||
s | ||||
e | ||||
a | ||||
r | ||||
c | ||||
h | ||||
i | ||||
n | ||||
g | ||||
. | ||||
base object of the search, but not when searching | base object of the search, but not when searching | |||
subordinates of the base object; | subordinates of the base object; | |||
derefAlways: dereference aliases both in searching and in | derefAlways: dereference aliases both in searching and in | |||
locating the base object of the search. | locating the base object of the search. | |||
- sizeLimit: A size limit that restricts the maximum number of | - sizeLimit: A size limit that restricts the maximum number of | |||
entries to be returned as a result of the search. A value of 0 in | entries to be returned as a result of the search. A value of 0 in | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 17 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
this field indicates that no client-requested size limit | this field indicates that no client-requested size limit | |||
restrictions are in effect for the search. Servers may enforce a | restrictions are in effect for the search. Servers may enforce a | |||
maximum number of entries to return. | maximum number of entries to return. | |||
- timeLimit: A time limit that restricts the maximum time (in | - timeLimit: A time limit that restricts the maximum time (in | |||
seconds) allowed for a search. A value of 0 in this field | seconds) allowed for a search. A value of 0 in this field | |||
indicates that no client-requested time limit restrictions are in | indicates that no client-requested time limit restrictions are in | |||
effect for the search. | effect for the search. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 17 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- typesOnly: An indicator as to whether search results will contain | - typesOnly: An indicator as to whether search results will contain | |||
both attribute types and values, or just attribute types. Setting | both attribute types and values, or just attribute types. Setting | |||
this field to TRUE causes only attribute types (no values) to be | this field to TRUE causes only attribute types (no values) to be | |||
returned. Setting this field to FALSE causes both attribute types | returned. Setting this field to FALSE causes both attribute types | |||
and values to be returned. | and values to be 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 | |||
skipping to change at line 997 | skipping to change at line 1247 | |||
unrecognized attribute description.) | unrecognized attribute description.) | |||
The matching rule and assertion syntax for equalityMatch filter | The matching rule and assertion syntax for equalityMatch filter | |||
items is defined by the EQUALITY matching rule for the attribute | items is defined by the EQUALITY matching rule for the attribute | |||
type. | type. | |||
The matching rule and assertion syntax for AssertionValues in a | The matching rule and assertion syntax for AssertionValues in a | |||
substrings filter item is defined by the SUBSTR matching rule for | substrings filter item is defined by the SUBSTR matching rule for | |||
the attribute type. | the attribute type. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 18 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The matching rule and assertion syntax for greaterOrEqual and | The matching rule and assertion syntax for greaterOrEqual and | |||
lessOrEqual filter items is defined by the ORDERING matching rule | lessOrEqual filter items is defined by the ORDERING matching rule | |||
for the attribute type. | for the attribute type. | |||
The matching rule and assertion syntax for approxMatch filter | The matching rule and assertion syntax for approxMatch filter | |||
items is implementation-defined. If approximate matching is not | items is implementation-defined. If approximate matching is not | |||
supported by the server, the filter item should be treated as an | supported by the server, the filter item should be treated as an | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 18 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
equalityMatch. | equalityMatch. | |||
The extensibleMatch is new in this version of LDAP. If the | The extensibleMatch is new in this version of LDAP. If the | |||
matchingRule field is absent, the type field MUST be present, and | matchingRule field is absent, the type field MUST be present, and | |||
the equality match is performed for that type. If the type field | the equality match is performed for that type. If the type field | |||
is absent and matchingRule is present, the matchValue is compared | is absent and matchingRule is present, the matchValue is compared | |||
against all attributes in an entry which support that | against all attributes in an entry which support that | |||
matchingRule, and the matchingRule determines the syntax for the | matchingRule, and the matchingRule determines the syntax for the | |||
assertion value (the filter item evaluates to TRUE if it matches | assertion value (the filter item evaluates to TRUE if it matches | |||
with at least one attribute in the entry, FALSE if it does not | with at least one attribute in the entry, FALSE if it does not | |||
skipping to change at line 1054 | skipping to change at line 1303 | |||
Servers MUST NOT return errors if attribute descriptions or | Servers MUST NOT return errors if attribute descriptions or | |||
matching rule ids are not recognized, or assertion values cannot | matching rule ids are not recognized, or assertion values cannot | |||
be parsed. More details of filter processing are given in section | be parsed. More details of filter processing are given in section | |||
7.8 of [X.511]. | 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. There are two special | entry which matches the search filter. There are two special | |||
values which may be used: an empty list with no attributes, and | values which may be used: an empty list with no attributes, and | |||
the attribute description string "*". Both of these signify that | the attribute description string "*". Both of these signify that | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 19 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
all user attributes are to be returned. (The "*" allows the client | all user attributes are to be returned. (The "*" allows the client | |||
to request all user attributes in addition to any specified | to request all user attributes in addition to any specified | |||
operational attributes). | operational attributes). | |||
Attributes MUST be named at most once in the list, and are | Attributes MUST be named at most once in the list, and are | |||
returned at most once in an entry. If there are attribute | returned at most once in an entry. If there are attribute | |||
descriptions in the list which are not recognized, they are | descriptions in the list which are not recognized, they are | |||
ignored by the server. | ignored by the server. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 19 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
If the client does not want any attributes returned, it can | If the client does not want any attributes returned, it can | |||
specify a list containing only the attribute with OID "1.1". This | specify a list containing only the attribute with OID "1.1". This | |||
OID was chosen arbitrarily and does not correspond to any | OID was chosen arbitrarily and does not correspond to any | |||
attribute in use. | attribute in use. | |||
Client implementors should note that even if all user attributes | Client implementors should note that even if all user attributes | |||
are requested, some attributes of the entry may not be included in | are requested, some attributes of the entry may not be included in | |||
search results due to access controls or other restrictions. | search results due to access controls or other restrictions. | |||
Furthermore, servers will not return operational attributes, such | Furthermore, servers will not return operational attributes, such | |||
as objectClasses or attributeTypes, unless they are listed by | as objectClasses or attributeTypes, unless they are listed by | |||
skipping to change at line 1110 | skipping to change at line 1360 | |||
PartialAttributeList ::= SEQUENCE OF SEQUENCE { | PartialAttributeList ::= SEQUENCE OF SEQUENCE { | |||
type AttributeDescription, | type AttributeDescription, | |||
vals SET OF AttributeValue } | vals SET OF AttributeValue } | |||
-- implementors should note that the PartialAttributeList may | -- implementors should note that the PartialAttributeList may | |||
-- have zero elements (if none of the attributes of that entry | -- have zero elements (if none of the attributes of that entry | |||
-- were requested, or could be returned), and that the vals set | -- were requested, or could be returned), and that the vals set | |||
-- may also have zero elements (if types only was requested, or | -- may also have zero elements (if types only was requested, or | |||
-- all values were excluded from the result.) | -- all values were excluded from the result.) | |||
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL | SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 20 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
-- at least one LDAPURL element must be present | -- at least one LDAPURL element must be present | |||
SearchResultDone ::= [APPLICATION 5] LDAPResult | SearchResultDone ::= [APPLICATION 5] LDAPResult | |||
Upon receipt of a Search Request, a server will perform the necessary | Upon receipt of a Search Request, a server will perform the necessary | |||
search of the DIT. | search of the DIT. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 20 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
If the LDAP session is operating over a connection-oriented transport | If the LDAP session is operating over a connection-oriented transport | |||
such as TCP, the server will return to the client a sequence of | such as TCP, the server will return to the client a sequence of | |||
responses in separate LDAP messages. There may be zero or more | responses in separate LDAP messages. There may be zero or more | |||
responses containing SearchResultEntry, one for each entry found | responses containing SearchResultEntry, one for each entry found | |||
during the search. There may also be zero or more responses | during the search. There may also be zero or more responses | |||
containing SearchResultReference, one for each area not explored by | containing SearchResultReference, one for each area not explored by | |||
this server during the search. The SearchResultEntry and | this server during the search. The SearchResultEntry and | |||
SearchResultReference PDUs may come in any order. Following all the | SearchResultReference PDUs may come in any order. Following all the | |||
SearchResultReference responses and all SearchResultEntry responses | SearchResultReference responses and all SearchResultEntry responses | |||
to be returned by the server, the server will return a response | to be returned by the server, the server will return a response | |||
skipping to change at line 1167 | skipping to change at line 1418 | |||
set of servers for continuing the operation. A server MUST NOT return | set of servers for continuing the operation. A server MUST NOT return | |||
any SearchResultReference if it has not located the baseObject and | any SearchResultReference if it has not located the baseObject and | |||
thus has not searched any entries; in this case it would return a | thus has not searched any entries; in this case it would return a | |||
SearchResultDone containing a referral resultCode. | SearchResultDone containing a referral resultCode. | |||
In the absence of indexing information provided to a server from | In the absence of indexing information provided to a server from | |||
servers holding subordinate naming contexts, SearchResultReference | servers holding subordinate naming contexts, SearchResultReference | |||
responses are not affected by search filters and are always returned | responses are not affected by search filters and are always returned | |||
when in scope. | when in scope. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 21 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The SearchResultReference is of the same data type as the Referral. | The SearchResultReference is of the same data type as the Referral. | |||
URLs for servers implementing the LDAP protocol are written according | URLs for servers implementing the LDAP protocol are written according | |||
to [LDAPDN]. The <dn> part MUST be present in the URL, with the new | to [LDAPDN]. The <dn> part MUST be present in the URL, with the new | |||
target object name. The client MUST use this name in its next | target object name. The client MUST use this name in its next | |||
request. Some servers (e.g. part of a distributed index exchange | request. Some servers (e.g. part of a distributed index exchange | |||
system) may provide a different filter in the URLs of the | system) may provide a different filter in the URLs of the | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 21 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
SearchResultReference. If the filter part of the URL is present in an | SearchResultReference. If the filter part of the URL is present in an | |||
LDAP URL, the client MUST use the new filter in its next request to | LDAP URL, the client MUST use the new filter in its next request to | |||
progress the search, and if the filter part is absent the client will | progress the search, and if the filter part is absent the client will | |||
use again the same filter. If the originating search scope was | use again the same filter. If the originating search scope was | |||
singleLevel, the scope part of the URL will be baseObject. Other | singleLevel, the scope part of the URL will be baseObject. Other | |||
aspects of the new search request may be the same or different as the | aspects of the new search request may be the same or different as the | |||
search which generated the continuation references. | search which generated the continuation references. | |||
Other kinds of URLs may be returned so long as the operation could be | Other kinds of URLs may be returned so long as the operation could be | |||
performed using that protocol. | performed using that protocol. | |||
Comment | ||||
: | ||||
why | ||||
n | ||||
o | ||||
t | ||||
? | ||||
P | ||||
r | ||||
o | ||||
b | ||||
a | ||||
b | ||||
l | ||||
y | ||||
b | ||||
e | ||||
c | ||||
a | ||||
u | ||||
s | ||||
e | ||||
The name of an unexplored subtree in a SearchResultReference need not | The name of an unexplored subtree in a SearchResultReference need not | |||
o | ||||
f | ||||
a | ||||
l | ||||
i | ||||
a | ||||
s | ||||
d | ||||
e | ||||
r | ||||
e | ||||
f | ||||
e | ||||
r | ||||
e | ||||
n | ||||
c | ||||
i | ||||
n | ||||
g | ||||
be subordinate to the base object. | be subordinate to the base object. | |||
In order to complete the search, the client MUST issue a new search | In order to complete the search, the client MUST issue a new search | |||
operation for each SearchResultReference that is returned. Note that | operation for each SearchResultReference that is returned. Note that | |||
the abandon operation described in section 4.11 applies only to a | the abandon operation described in section 4.11 applies only to a | |||
particular operation sent on a connection between a client and | particular operation sent on a connection between a client and | |||
server, and if the client has multiple outstanding search operations, | server, and if the client has multiple outstanding search operations, | |||
it MUST abandon each operation individually. | it MUST abandon each operation individually. | |||
4.5.3.1. Example | 4.5.3.1. Example | |||
skipping to change at line 1222 | skipping to change at line 1521 | |||
ldap://hostc/OU=People,DC=Example,DC=NET | ldap://hostc/OU=People,DC=Example,DC=NET | |||
} | } | |||
SearchResultReference { | SearchResultReference { | |||
ldap://hostd/OU=Roles,DC=Example,DC=NET | ldap://hostd/OU=Roles,DC=Example,DC=NET | |||
} | } | |||
SearchResultDone (success) | SearchResultDone (success) | |||
Client implementors should note that when following a | Client implementors should note that when following a | |||
SearchResultReference, additional SearchResultReference may be | SearchResultReference, additional SearchResultReference may be | |||
generated. Continuing the example, if the client contacted the server | generated. Continuing the example, if the client contacted the server | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 22 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
(hostb) and issued the search for the subtree | (hostb) and issued the search for the subtree | |||
"OU=People,DC=Example,DC=NET", the server might respond as follows: | "OU=People,DC=Example,DC=NET", the server might respond as follows: | |||
SearchResultEntry for OU=People,DC=Example,DC=NET | SearchResultEntry for OU=People,DC=Example,DC=NET | |||
SearchResultReference { | SearchResultReference { | |||
ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET | ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET | |||
} | } | |||
SearchResultReference { | SearchResultReference { | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 22 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET | ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET | |||
} | } | |||
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. | |||
SearchResultDone (referral) { | SearchResultDone (referral) { | |||
skipping to change at line 1279 | skipping to change at line 1578 | |||
contains the DN of the entry to be modified. The server will not | contains the DN of the entry to be modified. The server will not | |||
perform any alias dereferencing in determining the object to be | perform any alias dereferencing in determining the object to be | |||
modified. | modified. | |||
- modification: A list of modifications to be performed on the | - modification: A list of modifications to be performed on the | |||
entry. The entire list of entry modifications MUST be performed in | entry. The entire list of entry modifications MUST be performed in | |||
the order they are listed, as a single atomic operation. While | the order they are listed, as a single atomic operation. While | |||
individual modifications may violate the directory schema, the | individual modifications may violate the directory schema, the | |||
resulting entry after the entire list of modifications is | resulting entry after the entire list of modifications is | |||
performed MUST conform to the requirements of the directory | performed MUST conform to the requirements of the directory | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 23 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
schema. The values that may be taken on by the 'operation' field | schema. The values that may be taken on by the 'operation' field | |||
in each modification construct have the following semantics | in each modification construct have the following semantics | |||
respectively: | respectively: | |||
add: add values listed to the given attribute, creating the | add: add values listed to the given attribute, creating the | |||
attribute if necessary; | attribute if necessary; | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 23 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
delete: delete values listed from the given attribute, | delete: delete values listed from the given attribute, | |||
removing the entire attribute if no values are listed, or | removing the entire attribute if no values are listed, or | |||
if all current values of the attribute are listed for | if all current values of the attribute are listed for | |||
deletion; | deletion; | |||
replace: replace all existing values of the given attribute | replace: replace all existing values of the given attribute | |||
with the new values listed, creating the attribute if it | with the new values listed, creating the attribute if it | |||
did not already exist. A replace with no value will delete | did not already exist. A replace with no value will delete | |||
the entire attribute if it exists, and is ignored if the | the entire attribute if it exists, and is ignored if the | |||
Comment | ||||
: | ||||
Doe | ||||
s | ||||
n | ||||
o | ||||
t | ||||
e | ||||
x | ||||
i | ||||
s | ||||
t | ||||
o | ||||
n | ||||
t | ||||
h | ||||
e | ||||
e | ||||
n | ||||
t | ||||
r | ||||
y | ||||
, | ||||
attribute does not exist. | attribute does not exist. | |||
t | ||||
h | ||||
e | ||||
The result of the modify attempted by the server upon receipt of a | o | |||
Modify Request is returned in a Modify Response, defined as follows: | b | |||
j | ||||
e | ||||
c | ||||
t | ||||
c | ||||
l | ||||
a | ||||
s | ||||
s | ||||
, | ||||
o | ||||
r | ||||
t | ||||
h | ||||
e | ||||
s | ||||
c | ||||
h | ||||
ema | ||||
? | ||||
App | ||||
l | ||||
y | ||||
s | ||||
ame | ||||
t | ||||
o | ||||
d | ||||
e | ||||
l | ||||
e | ||||
t | ||||
e | ||||
The result of the modification attempted by the server upon receipt | ||||
of a Modify Request is returned in a Modify Response, defined as | ||||
follows: | ||||
ModifyResponse ::= [APPLICATION 7] LDAPResult | ModifyResponse ::= [APPLICATION 7] LDAPResult | |||
Upon receipt of a Modify Request, a server will perform the necessary | Upon receipt of a Modify Request, a server will perform the necessary | |||
modifications to the DIT. | modifications to the DIT. | |||
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. Note that due to the | or the reason that the modification failed. Note that due to the | |||
requirement for atomicity in applying the list of modifications in | requirement for atomicity in applying the list of modifications in | |||
skipping to change at line 1325 | skipping to change at line 1701 | |||
performed if the Modify Response indicates successful completion of | performed if the Modify Response indicates successful completion of | |||
the Modify Operation. If the connection fails, whether the | the Modify Operation. If the connection fails, whether the | |||
modification occurred or not is indeterminate. | modification occurred or not is indeterminate. | |||
The Modify Operation cannot be used to remove from an entry any of | The Modify Operation cannot be used to remove from an entry any of | |||
its distinguished values, those values which form the entry's | its distinguished values, those values which form the entry's | |||
relative distinguished name. An attempt to do so will result in the | relative distinguished name. An attempt to do so will result in the | |||
server returning the error notAllowedOnRDN. The Modify DN Operation | server returning the error notAllowedOnRDN. The Modify DN Operation | |||
described in section 4.9 is used to rename an entry. | described in section 4.9 is used to rename an entry. | |||
If an equality match filter has not been defined for an attribute | If an EQUALITY matching rule has not been defined for an attribute | |||
type, clients MUST NOT attempt to add or delete individual values of | type, clients MUST NOT attempt to add or delete individual values of | |||
that attribute from an entry using the "add" or "delete" form of a | that attribute from an entry using the "add" or "delete" form of a | |||
modification, and MUST instead use the "replace" form. | modification, and MUST instead use the "replace" form. | |||
Note that due to the simplifications made in LDAP, there is not a | Note that due to the simplifications made in LDAP, there is not a | |||
direct mapping of the modifications in an LDAP ModifyRequest onto the | direct mapping of the modifications in an LDAP ModifyRequest onto the | |||
EntryModifications of a DAP ModifyEntry operation, and different | EntryModifications of a DAP ModifyEntry operation, and different | |||
implementations of LDAP-DAP gateways may use different means of | implementations of LDAP-DAP gateways may use different means of | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 24 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
representing the change. If successful, the final effect of the | representing the change. If successful, the final effect of the | |||
operations on the entry MUST be identical. | operations on the entry MUST be identical. | |||
4.7. Add Operation | 4.7. Add Operation | |||
The Add Operation allows a client to request the addition of an entry | The Add Operation allows a client to request the addition of an entry | |||
into the directory. The Add Request is defined as follows: | into the directory. The Add Request is defined as follows: | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 24 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
AddRequest ::= [APPLICATION 8] SEQUENCE { | AddRequest ::= [APPLICATION 8] SEQUENCE { | |||
entry LDAPDN, | entry LDAPDN, | |||
attributes AttributeList } | attributes AttributeList } | |||
AttributeList ::= SEQUENCE OF SEQUENCE { | AttributeList ::= SEQUENCE OF SEQUENCE { | |||
type AttributeDescription, | type AttributeDescription, | |||
vals SET OF AttributeValue } | vals SET OF AttributeValue } | |||
Parameters of the Add Request are: | Parameters of the Add Request are: | |||
skipping to change at line 1391 | skipping to change at line 1768 | |||
Upon receipt of an Add Request, a server will attempt to perform the | Upon receipt of an Add Request, a server will attempt to perform the | |||
add requested. The result of the add attempt will be returned to the | add requested. The result of the add attempt will be returned to the | |||
client in the Add Response, defined as follows: | client in the Add Response, defined as follows: | |||
AddResponse ::= [APPLICATION 9] LDAPResult | AddResponse ::= [APPLICATION 9] LDAPResult | |||
A response of success indicates that the new entry is present in the | A response of success indicates that the new entry is present in the | |||
directory. | directory. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 25 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
4.8. Delete Operation | 4.8. Delete Operation | |||
The Delete Operation allows a client to request the removal of an | The Delete Operation allows a client to request the removal of an | |||
entry from the directory. The Delete Request is defined as follows: | entry from the directory. The Delete Request is defined as follows: | |||
DelRequest ::= [APPLICATION 10] LDAPDN | DelRequest ::= [APPLICATION 10] LDAPDN | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 25 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The Delete Request consists of the Distinguished Name of the entry to | The Delete Request consists of the Distinguished Name of the entry to | |||
be deleted. Note that the server will not dereference aliases while | be deleted. Note that the server will not dereference aliases while | |||
resolving the name of the target entry to be removed, and that only | resolving the name of the target entry to be removed, and that only | |||
leaf entries (those with no subordinate entries) can be deleted with | leaf entries (those with no subordinate entries) can be deleted with | |||
this operation. | this operation. | |||
The result of the delete attempted by the server upon receipt of a | The result of the delete attempted by the server upon receipt of a | |||
Delete Request is returned in the Delete Response, defined as | Delete Request is returned in the Delete Response, defined as | |||
follows: | follows: | |||
skipping to change at line 1444 | skipping to change at line 1821 | |||
server will not dereference any aliases in locating the entry to | server will not dereference any aliases in locating the entry to | |||
be changed. | be changed. | |||
- newrdn: the RDN that will form the leftmost component of the new | - newrdn: the RDN that will form the leftmost component of the new | |||
name of the entry. | name of the entry. | |||
- deleteoldrdn: a boolean parameter that controls whether the old | - deleteoldrdn: a boolean parameter that controls whether the old | |||
RDN attribute values are to be retained as attributes of the | RDN attribute values are to be retained as attributes of the | |||
entry, or deleted from the entry. | entry, or deleted from the entry. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 26 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- newSuperior: if present, this is the Distinguished Name of the | - newSuperior: if present, this is the Distinguished Name of the | |||
entry which becomes the immediate superior of the existing entry. | entry which becomes the immediate superior of the existing entry. | |||
The result of the name change attempted by the server upon receipt of | The result of the name change attempted by the server upon receipt of | |||
a Modify DN Request is returned in the Modify DN Response, defined as | a Modify DN Request is returned in the Modify DN Response, defined as | |||
follows: | follows: | |||
ModifyDNResponse ::= [APPLICATION 13] LDAPResult | ModifyDNResponse ::= [APPLICATION 13] LDAPResult | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 26 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Upon receipt of a ModifyDNRequest, a server will attempt to perform | Upon receipt of a ModifyDNRequest, a server will attempt to perform | |||
the name change. The result of the name change attempt will be | the name change. The result of the name change attempt will be | |||
returned to the client in the Modify DN Response. | returned to the client in the Modify DN Response. | |||
For example, if the entry named in the "entry" parameter was "cn=John | For example, if the entry named in the "entry" parameter was "cn=John | |||
Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the | Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the | |||
newSuperior parameter was absent, then this operation would attempt | newSuperior parameter was absent, then this operation would attempt | |||
to rename the entry to be "cn=John Cougar Smith,c=US". If there was | to rename the entry to be "cn=John Cougar Smith,c=US". If there was | |||
already an entry with that name, the operation would fail with error | already an entry with that name, the operation would fail with error | |||
code entryAlreadyExists. | code entryAlreadyExists. | |||
skipping to change at line 1500 | skipping to change at line 1877 | |||
Parameters of the Compare Request are: | Parameters of the Compare Request are: | |||
- entry: the name of the entry to be compared with. Note that the | - entry: the name of the entry to be compared with. Note that the | |||
server SHOULD NOT dereference any aliases in locating the entry to | server SHOULD NOT dereference any aliases in locating the entry to | |||
be compared with. | be compared with. | |||
- ava: the assertion with which an attribute in the entry is to be | - ava: the assertion with which an attribute in the entry is to be | |||
compared. | compared. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 27 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The result of the compare attempted by the server upon receipt of a | The result of the compare attempted by the server upon receipt of a | |||
Compare Request is returned in the Compare Response, defined as | Compare Request is returned in the Compare Response, defined as | |||
follows: | follows: | |||
CompareResponse ::= [APPLICATION 15] LDAPResult | CompareResponse ::= [APPLICATION 15] LDAPResult | |||
Upon receipt of a Compare Request, a server will attempt to perform | Upon receipt of a Compare Request, a server will attempt to perform | |||
the requested comparison. The result of the comparison will be | the requested comparison using the EQUALITY matching rule for the | |||
attribute type. The result of the comparison will be returned to the | ||||
Comment | ||||
: | ||||
Sermersheim Internet-Draft - Expires Dec 2002 Page 27 | s | |||
Lightweight Directory Access Protocol Version 3 | h | |||
o | ||||
u | ||||
l | ||||
d | ||||
w | ||||
e | ||||
returned to the client in the Compare Response. Note that errors and | t | |||
the result of comparison are all returned in the same construct. | a | |||
l | ||||
k | ||||
a | ||||
b | ||||
o | ||||
u | ||||
t | ||||
w | ||||
h | ||||
a | ||||
t | ||||
client in the Compare Response. Note that errors and the result of | ||||
t | ||||
o | ||||
d | ||||
o | ||||
w | ||||
h | ||||
e | ||||
n | ||||
t | ||||
e | ||||
h | ||||
a | ||||
t | ||||
t | ||||
r | ||||
i | ||||
s | ||||
m | ||||
i | ||||
s | ||||
s | ||||
i | ||||
n | ||||
g | ||||
v | ||||
s | ||||
a | ||||
t | ||||
t | ||||
r | ||||
i | ||||
s | ||||
n | ||||
' | ||||
t | ||||
comparison are all returned in the same construct. | ||||
i | ||||
n | ||||
s | ||||
c | ||||
h | ||||
ema | ||||
? | ||||
Shou | ||||
l | ||||
d | ||||
w | ||||
e | ||||
d | ||||
e | ||||
s | ||||
c | ||||
r | ||||
i | ||||
b | ||||
e | ||||
w | ||||
h | ||||
a | ||||
t | ||||
h | ||||
a | ||||
p | ||||
p | ||||
e | ||||
n | ||||
s | ||||
i | ||||
f | ||||
t | ||||
h | ||||
e | ||||
r | ||||
e | ||||
' | ||||
s | ||||
n | ||||
o | ||||
e | ||||
q | ||||
u | ||||
a | ||||
l | ||||
i | ||||
t | ||||
y | ||||
m | ||||
a | ||||
t | ||||
c | ||||
h | ||||
i | ||||
n | ||||
g | ||||
r | ||||
u | ||||
l | ||||
e | ||||
? | ||||
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 read. | compared but not read. | |||
4.11. Abandon Operation | 4.11. Abandon Operation | |||
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 MUST be that of an operation which was requested | The MessageID MUST be that of an operation which was requested | |||
earlier in this connection. | earlier in this connection. The abandon request itself has its own | |||
message id. This is distinct from the id of the earlier operation | ||||
(The abandon request itself has its own message id. This is distinct | being abandoned. | |||
from the id of the earlier operation being abandoned.) | ||||
There is no response defined in the Abandon Operation. Upon | There is no response defined in the Abandon Operation. Upon | |||
transmission of an Abandon Operation, a client may expect that the | transmission of an Abandon Operation, the server MAY abandon the | |||
operation identified by the Message ID in the Abandon Request will be | operation identified by the Message ID in the Abandon Request. | |||
abandoned. In the event that a server receives an Abandon Request on | Operation responses are not sent for successfully abandoned | |||
a Search Operation in the midst of transmitting responses to the | operations. Clients can determine that an operation has been | |||
search, that server MUST cease transmitting entry responses to the | abandoned by performing a subsequent bind operation. | |||
abandoned request immediately, and MUST NOT send the | ||||
SearchResponseDone. Of course, the server MUST ensure that only | Abandon and Unbind operations cannot be abandoned. The ability to | |||
properly encoded LDAPMessage PDUs are transmitted. | abandon other (particularly update) operations is at the discretion | |||
of the server. | ||||
In the event that a server receives an Abandon Request on a Search | ||||
Operation in the midst of transmitting responses to the search, that | ||||
server MUST cease transmitting entry responses to the abandoned | ||||
request immediately, and MUST NOT send the SearchResponseDone. Of | ||||
course, the server MUST ensure that only properly encoded LDAPMessage | ||||
PDUs are transmitted. | ||||
Clients MUST NOT send abandon requests for the same operation | Clients MUST NOT send abandon requests for the same operation | |||
multiple times, and MUST also be prepared to receive results from | multiple times, and MUST also be prepared to receive results from | |||
operations it has abandoned (since these may have been in transit | operations it has abandoned (since these may have been in transit | |||
when the abandon was requested). | when the abandon was requested, or are not able to be abandoned). | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 28 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
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 | |||
An extension mechanism has been added in this version of LDAP, in | An extension mechanism has been added in this version of LDAP, in | |||
order to allow additional operations to be defined for services not | order to allow additional operations to be defined for services not | |||
available elsewhere in this protocol, for instance digitally signed | available elsewhere in this protocol, for instance digitally signed | |||
operations and results. | operations and results. | |||
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. Each | defined in RFCs or be private to particular implementations. Each | |||
request MUST have a unique OBJECT IDENTIFIER assigned to it. | request MUST have a unique OBJECT IDENTIFIER assigned to it. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 28 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { | ExtendedRequest ::= [APPLICATION 23] SEQUENCE { | |||
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 OBJECT | The requestName is a dotted-decimal representation of the OBJECT | |||
IDENTIFIER corresponding to the request. The requestValue is | 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 the | The server will respond to this with an LDAPMessage containing the | |||
skipping to change at line 1603 | skipping to change at line 2128 | |||
5.1. Protocol Encoding | 5.1. Protocol Encoding | |||
The protocol elements of LDAP are encoded for exchange using the | The protocol elements of LDAP are encoded for exchange using the | |||
Basic Encoding Rules (BER) [X.690] of ASN.1 [X.680]. However, due to | Basic Encoding Rules (BER) [X.690] of ASN.1 [X.680]. However, due to | |||
the high overhead involved in using certain elements of the BER, the | the high overhead involved in using certain elements of the BER, the | |||
following additional restrictions are placed on BER-encodings of LDAP | following additional restrictions are placed on BER-encodings of LDAP | |||
protocol elements: | protocol elements: | |||
(1) Only the definite form of length encoding will be used. | (1) Only the definite form of length encoding will be used. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 29 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
(2) OCTET STRING values will be encoded in the primitive form only. | (2) OCTET STRING values will be encoded in the primitive form only. | |||
(3) If the value of a BOOLEAN type is true, the encoding MUST have | (3) If the value of a BOOLEAN type is true, the encoding MUST have | |||
its contents octets set to hex "FF". | its contents octets set to hex "FF". | |||
(4) If a value of a type is its default value, it MUST be absent. | (4) If a value of a type is its default value, it MUST be absent. | |||
Only some BOOLEAN and INTEGER types have default values in this | Only some BOOLEAN and INTEGER types have default values in this | |||
protocol definition. | protocol definition. | |||
These restrictions do not apply to ASN.1 types encapsulated inside of | These restrictions do not apply to ASN.1 types encapsulated inside of | |||
OCTET STRING values, such as attribute values, unless otherwise | OCTET STRING values, such as attribute values, unless otherwise | |||
Comment | ||||
: | ||||
Wha | ||||
t | ||||
a | ||||
b | ||||
o | ||||
u | ||||
t | ||||
c | ||||
o | ||||
n | ||||
t | ||||
r | ||||
o | ||||
l | ||||
v | ||||
a | ||||
l | ||||
u | ||||
e | ||||
s | ||||
noted. | noted. | |||
a | ||||
n | ||||
d | ||||
5.2. Transfer Protocols | e | |||
x | ||||
t | ||||
e | ||||
n | ||||
s | ||||
i | ||||
o | ||||
n | ||||
Sermersheim Internet-Draft - Expires Dec 2002 Page 29 | v | |||
Lightweight Directory Access Protocol Version 3 | a | |||
l | ||||
u | ||||
e | ||||
s | ||||
? | ||||
5.2. Transfer Protocols | ||||
This protocol is designed to run over connection-oriented, reliable | This protocol is designed to run over connection-oriented, reliable | |||
transports, with all 8 bits in an octet being significant in the data | transports, with all 8 bits in an octet being significant in the data | |||
stream. | stream. | |||
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. It is recommended that server implementations running | bytestream using the BER-based encoding described in section 5.1. It | |||
over the TCP provide a protocol listener on the assigned port, 389. | is recommended that server implementations running over the TCP | |||
Servers may instead provide a listener on a different port number. | provide a protocol listener on the assigned port, 389. Servers may | |||
Clients MUST support contacting servers on any valid TCP port. | instead provide a listener on a different port number. Clients MUST | |||
support contacting servers on any valid TCP port. | ||||
6. Implementation Guidelines | 6. Implementation Guidelines | |||
This document describes an Internet protocol. | This document describes an Internet protocol. | |||
6.1. Server Implementations | 6.1. Server Implementations | |||
The server MUST be capable of recognizing all the mandatory attribute | The server MUST be capable of recognizing all the mandatory attribute | |||
type names and implement the syntaxes specified in [Syntaxes]. | type names and implement the syntaxes specified in [Syntaxes]. | |||
Servers MAY also recognize additional attribute type names. | Servers MAY also recognize additional attribute type names. | |||
skipping to change at line 1653 | skipping to change at line 2227 | |||
6.2. Client Implementations | 6.2. Client Implementations | |||
Clients which request referrals MUST ensure that they do not loop | Clients which request referrals MUST ensure that they do not loop | |||
between servers. They MUST NOT repeatedly contact the same server for | between servers. They MUST NOT repeatedly contact the same server for | |||
the same request with the same target entry name, scope and filter. | the same request with the same target entry name, scope and filter. | |||
Some clients may be using a counter that is incremented each time | Some clients may be using a counter that is incremented each time | |||
referral handling occurs for an operation, and these kinds of clients | referral handling occurs for an operation, and these kinds of clients | |||
MUST be able to handle a DIT with at least ten layers of naming | MUST be able to handle a DIT with at least ten layers of naming | |||
contexts between the root and a leaf entry. | contexts between the root and a leaf entry. | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 30 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
In the absence of prior agreements with servers, clients SHOULD NOT | In the absence of prior agreements with servers, clients SHOULD NOT | |||
assume that servers support any particular schemas beyond those | assume that servers support any particular schemas beyond those | |||
referenced in section 6.1. Different schemas can have different | referenced in section 6.1. Different schemas can have different | |||
attribute types with the same names. The client can retrieve the | attribute types with the same names. The client can retrieve the | |||
subschema entries referenced by the subschemaSubentry attribute in | subschema entries referenced by the subschemaSubentry attribute in | |||
the server's root DSE or in entries held by the server. | the server's root DSE or in entries held by the server. | |||
7. Security Considerations | 7. Security Considerations | |||
When used with a connection-oriented transport, this version of the | When used with a connection-oriented transport, this version of the | |||
protocol provides facilities for simple authentication using a | protocol provides facilities for simple authentication using a | |||
cleartext password, as well as any SASL mechanism [RFC2222]. SASL | cleartext password, as well as any SASL mechanism [RFC2222]. SASL | |||
allows for integrity and privacy services to be negotiated. | allows for integrity and privacy services to be 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. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 30 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
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. | |||
When used with SASL, it should be noted that the name field of the | When used with SASL, it should be noted that the name field of the | |||
BindRequest is not protected against modification. Thus if the | BindRequest is not protected against modification. Thus if the | |||
distinguished name of the client (an LDAPDN) is agreed through the | distinguished name of the client (an LDAPDN) is agreed through the | |||
negotiation of the credentials, it takes precedence over any value in | negotiation of the credentials, it takes precedence over any value in | |||
the unprotected name field. | the unprotected name field. | |||
skipping to change at line 1707 | skipping to change at line 2281 | |||
9. Normative References | 9. Normative References | |||
[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. | |||
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road | [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road | |||
Map", draft-ietf-ldapbis-roadmap-xx.txt (a work in | Map", draft-ietf-ldapbis-roadmap-xx.txt (a work in | |||
progress). | progress). | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 31 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, March 1997. | Requirement Levels", RFC 2119, March 1997. | |||
[X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 | [X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 | |||
Information Technology - Abstract Syntax Notation One | Information Technology - Abstract Syntax Notation One | |||
(ASN.1): Specification of basic notation | (ASN.1): Specification of basic notation | |||
[X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: | [X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: | |||
Basic, Canonical, and Distinguished Encoding Rules", 1994. | Basic, Canonical, and Distinguished Encoding Rules", 1994. | |||
[LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf- | [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf- | |||
ldapbis-xx.txt (a work in progress). | ldapbis-xx.txt (a work in progress). | |||
[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. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 31 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode | [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode | |||
and ISO 10646", RFC 2044, October 1996. | and ISO 10646", RFC 2044, October 1996. | |||
[Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis- | [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis- | |||
models-xx.txt (a work in progress). | models-xx.txt (a work in progress). | |||
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of | [LDAPDN] K. Zeilenga (editor), "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). | |||
skipping to change at line 1764 | skipping to change at line 2338 | |||
10. Editor's Address | 10. 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 Dec 2002 Page 32 | Sermersheim Internet-Draft - Expires Apr 2003 Page 32 | |||
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.10. | LDAP result code enumerated in Section 4.1.10. | |||
Additional result codes MAY be defined for use with extensions. | Additional result codes MAY be defined for use with extensions. | |||
Client implementations SHALL treat any result code which they do not | Client implementations SHALL treat any result code which they do not | |||
skipping to change at line 1821 | skipping to change at line 2395 | |||
6) Protocol Problem (codes 1, 2) | 6) Protocol Problem (codes 1, 2) | |||
- a problem related to protocol structure or semantics. | - a problem related to protocol structure or semantics. | |||
Server implementations SHALL NOT continue processing an operation | Server implementations SHALL NOT continue processing an operation | |||
after it has determined that an error is to be reported. If the | after it has determined that an error is to be reported. If the | |||
server detects multiple errors simultaneously, the server SHOULD | server detects multiple errors simultaneously, the server SHOULD | |||
report the error with the highest precedence. | report the error with the highest precedence. | |||
Existing LDAP result codes are described as follows: | Existing LDAP result codes are described as follows: | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 33 | Sermersheim Internet-Draft - Expires Apr 2003 Page 33 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
success (0) | success (0) | |||
Indicates successful completion of an operation. | Indicates successful completion of an operation. | |||
This result code is normally not returned by the compare | This result code is normally not returned by the compare | |||
operation, see compareFalse (5) and compareTrue (6). | operation, see compareFalse (5) and compareTrue (6). | |||
operationsError (1) | operationsError (1) | |||
Indicates that the operation is not properly sequenced with | Indicates that the operation is not properly sequenced with | |||
relation to other operations (of same or different type). | relation to other operations (of same or different type). | |||
For example, this code is returned if the client attempts to | For example, this code is returned if the client attempts to | |||
Start TLS [RFC2830] while there are other operations | Start TLS [RFC2830] while there are other operations | |||
outstanding or if TLS was already established. | outstanding or if TLS was already established. | |||
For the bind operation only, the code indicates the server | For the bind operation only, the code indicates the server | |||
Comment | ||||
: | ||||
Do | ||||
w | ||||
e | ||||
r | ||||
e | ||||
a | ||||
l | ||||
l | ||||
y | ||||
w | ||||
a | ||||
n | ||||
t | ||||
t | ||||
o | ||||
c | ||||
a | ||||
r | ||||
r | ||||
y | ||||
encountered an internal error. | encountered an internal error. | |||
t | ||||
h | ||||
i | ||||
s | ||||
o | ||||
n | ||||
? | ||||
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, the code may be resulted to indicate | For bind operation only, the code may be resulted to indicate | |||
Comment | ||||
: | ||||
Do | ||||
w | ||||
e | ||||
r | ||||
e | ||||
a | ||||
l | ||||
l | ||||
y | ||||
w | ||||
a | ||||
n | ||||
t | ||||
t | ||||
o | ||||
c | ||||
a | ||||
r | ||||
r | ||||
y | ||||
the server does not support the requested protocol version. | the server does not support the requested protocol version. | |||
t | ||||
h | ||||
i | ||||
s | ||||
o | ||||
n | ||||
? | ||||
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 1871 | skipping to change at line 2515 | |||
compareFalse (5) | compareFalse (5) | |||
Indicates that the operation successfully completes and the | Indicates that the operation successfully completes and the | |||
assertion has evaluated to TRUE. | assertion has evaluated to TRUE. | |||
This result code is normally only returned by the compare | This result code is normally only returned by the compare | |||
operation. | operation. | |||
compareTrue (6) | compareTrue (6) | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 34 | Sermersheim Internet-Draft - Expires Apr 2003 Page 34 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Indicates that the operation successfully completes and the | Indicates that the operation successfully completes and the | |||
assertion has evaluated to FALSE. | assertion has evaluated to FALSE. | |||
This result code is normally only returned by the compare | This result code is normally only returned by the compare | |||
operation. | operation. | |||
authMethodNotSupported (7) | authMethodNotSupported (7) | |||
skipping to change at line 1920 | skipping to change at line 2564 | |||
Indicates the server requires the client to send a new bind | Indicates the server requires the client to send a new bind | |||
request, with the same sasl mechanism, to continue the | request, with the same sasl mechanism, to continue the | |||
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. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 35 | Sermersheim Internet-Draft - Expires Apr 2003 Page 35 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
undefinedAttributeType (17) | undefinedAttributeType (17) | |||
Indicates that a request field contains an undefined | Indicates that a request field contains an undefined | |||
attribute type. | attribute type. | |||
inappropriateMatching (18) | inappropriateMatching (18) | |||
Indicates that a request cannot be completed due to an | Indicates that a request cannot be completed due to an | |||
skipping to change at line 1969 | skipping to change at line 2613 | |||
Indicates that an alias problem has occurred. | Indicates that an alias problem has occurred. | |||
invalidDNSyntax (34) | invalidDNSyntax (34) | |||
Indicates that a LDAPDN or RelativeLDAPDN field (e.g. search | Indicates that a LDAPDN or RelativeLDAPDN field (e.g. search | |||
base, target entry, ModifyDN newrdn, etc.) of a request does | base, target entry, ModifyDN newrdn, etc.) of a request does | |||
not conform to the required syntax or contains attribute | not conform to the required syntax or contains attribute | |||
values which do not conform to the syntax of the attribute's | values which do not conform to the syntax of the attribute's | |||
type. | type. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 36 | Sermersheim Internet-Draft - Expires Apr 2003 Page 36 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
aliasDereferencingProblem (36) | aliasDereferencingProblem (36) | |||
Indicates that a problem in dereferencing an alias. | Indicates that a problem in dereferencing an alias. | |||
inappropriateAuthentication (48) | inappropriateAuthentication (48) | |||
Indicates the server requires the client which had attempted | Indicates the server requires the client which had attempted | |||
to bind anonymously or without supplying credentials to | to bind anonymously or without supplying credentials to | |||
skipping to change at line 2017 | skipping to change at line 2661 | |||
Indicates that the server has detected an internal loop. | Indicates that the server has detected an internal loop. | |||
namingViolation (64) | namingViolation (64) | |||
Indicates that the entry name violates naming restrictions. | Indicates that the entry name violates naming restrictions. | |||
objectClassViolation (65) | objectClassViolation (65) | |||
Indicates that the entry violates object class restrictions. | Indicates that the entry violates object class restrictions. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 37 | Sermersheim Internet-Draft - Expires Apr 2003 Page 37 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
notAllowedOnNonLeaf (66) | notAllowedOnNonLeaf (66) | |||
Indicates that operation is inappropriately acting upon a | Indicates that operation is inappropriately acting upon a | |||
non-leaf entry. | non-leaf entry. | |||
notAllowedOnRDN (67) | notAllowedOnRDN (67) | |||
Indicates that the operation is inappropriately attempting to | Indicates that the operation is inappropriately attempting to | |||
skipping to change at line 2053 | skipping to change at line 2697 | |||
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 Dec 2002 Page 38 | Sermersheim Internet-Draft - Expires Apr 2003 Page 38 | |||
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 DEFINITIONS | Lightweight-Directory-Access-Protocol-V3 DEFINITIONS | |||
IMPLICIT TAGS | IMPLICIT TAGS | |||
EXTENSIBILITY IMPLIED ::= | EXTENSIBILITY IMPLIED ::= | |||
skipping to change at line 2111 | skipping to change at line 2755 | |||
LDAPDN ::= LDAPString | LDAPDN ::= LDAPString | |||
RelativeLDAPDN ::= LDAPString | RelativeLDAPDN ::= LDAPString | |||
AttributeDescription ::= LDAPString | AttributeDescription ::= LDAPString | |||
-- Constrained to attributedescription | -- Constrained to attributedescription | |||
-- [Models] | -- [Models] | |||
AttributeDescriptionList ::= SEQUENCE OF | AttributeDescriptionList ::= SEQUENCE OF | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 39 | Sermersheim Internet-Draft - Expires Apr 2003 Page 39 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
AttributeDescription | AttributeDescription | |||
AttributeValue ::= OCTET STRING | AttributeValue ::= OCTET STRING | |||
AttributeValueAssertion ::= SEQUENCE { | AttributeValueAssertion ::= SEQUENCE { | |||
attributeDesc AttributeDescription, | attributeDesc AttributeDescription, | |||
assertionValue AssertionValue } | assertionValue AssertionValue } | |||
skipping to change at line 2169 | skipping to change at line 2813 | |||
-- 37-47 unused -- | -- 37-47 unused -- | |||
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 -- | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 40 | Sermersheim Internet-Draft - Expires Apr 2003 Page 40 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
namingViolation (64), | namingViolation (64), | |||
objectClassViolation (65), | objectClassViolation (65), | |||
notAllowedOnNonLeaf (66), | notAllowedOnNonLeaf (66), | |||
notAllowedOnRDN (67), | notAllowedOnRDN (67), | |||
entryAlreadyExists (68), | entryAlreadyExists (68), | |||
objectClassModsProhibited (69), | objectClassModsProhibited (69), | |||
-- 70 reserved for CLDAP -- | -- 70 reserved for CLDAP -- | |||
affectsMultipleDSAs (71), | affectsMultipleDSAs (71), | |||
skipping to change at line 2227 | skipping to change at line 2871 | |||
serverSaslCreds [7] OCTET STRING OPTIONAL } | serverSaslCreds [7] OCTET STRING OPTIONAL } | |||
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), | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 41 | Sermersheim Internet-Draft - Expires Apr 2003 Page 41 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
wholeSubtree (2) }, | wholeSubtree (2) }, | |||
derefAliases ENUMERATED { | derefAliases ENUMERATED { | |||
neverDerefAliases (0), | neverDerefAliases (0), | |||
derefInSearching (1), | derefInSearching (1), | |||
derefFindingBaseObj (2), | derefFindingBaseObj (2), | |||
derefAlways (3) }, | derefAlways (3) }, | |||
sizeLimit INTEGER (0 .. maxInt), | sizeLimit INTEGER (0 .. maxInt), | |||
timeLimit INTEGER (0 .. maxInt), | timeLimit INTEGER (0 .. maxInt), | |||
skipping to change at line 2285 | skipping to change at line 2929 | |||
vals SET OF AttributeValue } | vals SET OF AttributeValue } | |||
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL | SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL | |||
SearchResultDone ::= [APPLICATION 5] LDAPResult | SearchResultDone ::= [APPLICATION 5] LDAPResult | |||
ModifyRequest ::= [APPLICATION 6] SEQUENCE { | ModifyRequest ::= [APPLICATION 6] SEQUENCE { | |||
object LDAPDN, | object LDAPDN, | |||
modification SEQUENCE OF SEQUENCE { | modification SEQUENCE OF SEQUENCE { | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 42 | Sermersheim Internet-Draft - Expires Apr 2003 Page 42 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
operation ENUMERATED { | operation ENUMERATED { | |||
add (0), | add (0), | |||
delete (1), | delete (1), | |||
replace (2) }, | replace (2) }, | |||
modification AttributeTypeAndValues } } | modification AttributeTypeAndValues } } | |||
AttributeTypeAndValues ::= SEQUENCE { | AttributeTypeAndValues ::= SEQUENCE { | |||
type AttributeDescription, | type AttributeDescription, | |||
skipping to change at line 2341 | skipping to change at line 2985 | |||
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, | |||
response [11] OCTET STRING OPTIONAL } | response [11] OCTET STRING OPTIONAL } | |||
END | END | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 43 | Sermersheim Internet-Draft - Expires Apr 2003 Page 43 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Appendix C - Change History | Appendix C - Change History | |||
<Note to RFC editor: This section is to be removed prior to RFC | <Note to RFC editor: This section is to be removed prior to RFC | |||
publication> | publication> | |||
C.1 Changes made to RFC 2251: | C.1 Changes made to RFC 2251: | |||
C.1.1 Editorial | C.1.1 Editorial | |||
skipping to change at line 2398 | skipping to change at line 3042 | |||
the transfer encoding is present in attributeDesc, the | the transfer encoding is present in attributeDesc, the | |||
AssertionValue is encoded as specified by the option...". | AssertionValue is encoded as specified by the option...". | |||
Previously, only the ;binary option was mentioned. | Previously, only the ;binary option was mentioned. | |||
C.2.3 Sections 4.2, 4.9, 4.10 | C.2.3 Sections 4.2, 4.9, 4.10 | |||
- Added alias dereferencing specifications. In the case of modDN, | - Added alias dereferencing specifications. In the case of modDN, | |||
followed precedent set on other update operations (... alias is | followed precedent set on other update operations (... alias is | |||
not dereferenced...) In the case of bind and compare stated that | not dereferenced...) In the case of bind and compare stated that | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 44 | Sermersheim Internet-Draft - Expires Apr 2003 Page 44 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
servers SHOULD NOT dereference aliases. Specifications were added | servers SHOULD NOT dereference aliases. Specifications were added | |||
because they were missing from the previous version and caused | because they were missing from the previous version and caused | |||
interoperability problems. Concessions were made for bind and | interoperability problems. Concessions were made for bind and | |||
compare (neither should have ever allowed alias dereferencing) by | compare (neither should have ever allowed alias dereferencing) by | |||
using SHOULD NOT language, due to the behavior of some existing | using SHOULD NOT language, due to the behavior of some existing | |||
implementations. | implementations. | |||
C.2.4 Sections 4.5 and Appendix A | C.2.4 Sections 4.5 and Appendix A | |||
skipping to change at line 2454 | skipping to change at line 3098 | |||
by a lower layer" to "the underlying transport service cannot | by a lower layer" to "the underlying transport service cannot | |||
guarantee confidentiality" | guarantee confidentiality" | |||
C.3.6 Section 4.5.2 | C.3.6 Section 4.5.2 | |||
- Removed all mention of ExtendedResponse due to lack of | - Removed all mention of ExtendedResponse due to lack of | |||
implementation. | implementation. | |||
C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt: | C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt: | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 45 | Sermersheim Internet-Draft - Expires Apr 2003 Page 45 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
C.4.1 Section 4 | C.4.1 Section 4 | |||
- Removed "typically" from "and is typically transferred" in the | - Removed "typically" from "and is typically transferred" in the | |||
first paragraph. We know of no (and can conceive of no) case where | first paragraph. We know of no (and can conceive of no) case where | |||
this isn't true. | this isn't true. | |||
- Added "Section 5.1 specifies how the LDAP protocol is encoded." To | - Added "Section 5.1 specifies how the LDAP protocol is encoded." To | |||
the first paragraph. Added this cross reference for readability. | the first paragraph. Added this cross reference for readability. | |||
- Changed "version 3 " to "version 3 or later" in the second | - Changed "version 3 " to "version 3 or later" in the second | |||
skipping to change at line 2510 | skipping to change at line 3154 | |||
controls). | controls). | |||
C.4.6 Section 4.4 | C.4.6 Section 4.4 | |||
- Changed "One unsolicited notification is defined" to "One | - Changed "One unsolicited notification is defined" to "One | |||
unsolicited notification (Notice of Disconnection) is defined" in | unsolicited notification (Notice of Disconnection) is defined" in | |||
the third paragraph. For clarity and readability. | the third paragraph. For clarity and readability. | |||
C.4.7 Section 4.5.1 | C.4.7 Section 4.5.1 | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 46 | Sermersheim Internet-Draft - Expires Apr 2003 Page 46 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Changed "checking for the existence of the objectClass attribute" | - Changed "checking for the existence of the objectClass attribute" | |||
to "checking for the presence of the objectClass attribute" in the | to "checking for the presence of the objectClass attribute" in the | |||
last paragraph. This was done as a measure of consistency (we use | last paragraph. This was done as a measure of consistency (we use | |||
the terms present and presence rather than exists and existence in | the terms present and presence rather than exists and existence in | |||
search filters). | search filters). | |||
C.4.8 Section 4.5.3 | C.4.8 Section 4.5.3 | |||
skipping to change at line 2566 | skipping to change at line 3210 | |||
whether there can be more than one value of an attribute of that | whether there can be more than one value of an attribute of that | |||
type in an entry, the syntax to which the values must conform, the | type in an entry, the syntax to which the values must conform, the | |||
kinds of matching which can be performed on values of that | kinds of matching which can be performed on values of that | |||
attribute, and other functions." to " An attribute is a | attribute, and other functions." to " An attribute is a | |||
description (a type and zero or more options) with one or more | description (a type and zero or more options) with one or more | |||
associated values. The attribute type governs whether the | associated values. The attribute type governs whether the | |||
attribute can have multiple values, the syntax and matching rules | attribute can have multiple values, the syntax and matching rules | |||
used to construct and compare values of that attribute, and other | used to construct and compare values of that attribute, and other | |||
functions. Options indicate modes of transfer and other | functions. Options indicate modes of transfer and other | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 47 | Sermersheim Internet-Draft - Expires Apr 2003 Page 47 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
functions.". This points out that an attribute consists of both | functions.". This points out that an attribute consists of both | |||
the type and options. | the type and options. | |||
C.5.2 Section 4 | C.5.2 Section 4 | |||
- Changed "Section 5.1 specifies the encoding rules for the LDAP | - Changed "Section 5.1 specifies the encoding rules for the LDAP | |||
protocol" to "Section 5.1 specifies how the protocol is encoded | protocol" to "Section 5.1 specifies how the protocol is encoded | |||
and transferred." | and transferred." | |||
skipping to change at line 2623 | skipping to change at line 3267 | |||
- Changed the wording regarding 'equally capable' referrals to "If | - Changed the wording regarding 'equally capable' referrals to "If | |||
multiple URLs are present, the client assumes that any URL may be | multiple URLs are present, the client assumes that any URL may be | |||
used to progress the operation.". The previous language implied | used to progress the operation.". The previous language implied | |||
that the server MUST enforce rules that it was practically | that the server MUST enforce rules that it was practically | |||
incapable of. The new language highlights the original intent-- | incapable of. The new language highlights the original intent-- | |||
that is, that any of the referrals may be used to progress the | that is, that any of the referrals may be used to progress the | |||
operation, there is no inherent 'weighting' mechanism. | operation, there is no inherent 'weighting' mechanism. | |||
C.5.7 Section 4.5.1 and Appendix A | C.5.7 Section 4.5.1 and Appendix A | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 48 | Sermersheim Internet-Draft - Expires Apr 2003 Page 48 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Added the comment "-- initial and final can occur at most once", | - Added the comment "-- initial and final can occur at most once", | |||
to clarify this restriction. | to clarify this restriction. | |||
C.5.8 Section 5.1 | C.5.8 Section 5.1 | |||
- Changed heading from "Mapping Onto BER-based Transport Services" | - Changed heading from "Mapping Onto BER-based Transport Services" | |||
to "Protocol Encoding". | to "Protocol Encoding". | |||
skipping to change at line 2679 | skipping to change at line 3323 | |||
doc now specifies a difference between transfer and tagging | doc now specifies a difference between transfer and tagging | |||
options and describes the semantics of each, and how and when | options and describes the semantics of each, and how and when | |||
subtyping rules apply. Now allow options to be transmitted in any | subtyping rules apply. Now allow options to be transmitted in any | |||
order but disallow any ordering semantics to be implied. These | order but disallow any ordering semantics to be implied. These | |||
changes are the result of ongoing input from an engineering team | changes are the result of ongoing input from an engineering team | |||
designed to deal with ambiguity issues surrounding attribute | designed to deal with ambiguity issues surrounding attribute | |||
options. | options. | |||
C.7.3 Sections 4.1.5.1 and 4.1.6 | C.7.3 Sections 4.1.5.1 and 4.1.6 | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 49 | Sermersheim Internet-Draft - Expires Apr 2003 Page 49 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Refer to non "binary" transfer encodings as "native encoding" | - Refer to non "binary" transfer encodings as "native encoding" | |||
rather than "string" encoding to clarify and avoid confusion. | rather than "string" encoding to clarify and avoid confusion. | |||
C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt: | C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt: | |||
C.8.1 Title | C.8.1 Title | |||
- Changed to "LDAP: The Protocol" to be consisted with other working | - Changed to "LDAP: The Protocol" to be consisted with other working | |||
skipping to change at line 2735 | skipping to change at line 3379 | |||
C.8.7 Relationship to X.500 | C.8.7 Relationship to X.500 | |||
- Removed section. It has been moved to [Roadmap] | - Removed section. It has been moved to [Roadmap] | |||
C.8.8 Server Specific Data Requirements | C.8.8 Server Specific Data Requirements | |||
- Removed section. It has been moved to [Models] | - Removed section. It has been moved to [Models] | |||
C.8.9 Elements of Protocol | C.8.9 Elements of Protocol | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 50 | Sermersheim Internet-Draft - Expires Apr 2003 Page 50 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Added "Section 5.1 specifies how the protocol is encoded and | - Added "Section 5.1 specifies how the protocol is encoded and | |||
transferred." to the end of the first paragraph for reference. | transferred." to the end of the first paragraph for reference. | |||
- Reworded notes about extensibility, and now talk about implied | - Reworded notes about extensibility, and now talk about implied | |||
extensibility and the use of ellipses in the ASN.1 | extensibility and the use of ellipses in the ASN.1 | |||
- Removed references to LDAPv2 in third and fourth paragraphs. | - Removed references to LDAPv2 in third and fourth paragraphs. | |||
skipping to change at line 2792 | skipping to change at line 3436 | |||
- Clarified intent regarding exactly what is to be BER encoded. | - Clarified intent regarding exactly what is to be BER encoded. | |||
- Clarified that clients must not expect ;binary when not asking for | - Clarified that clients must not expect ;binary when not asking for | |||
it (;binary, as opposed to ber encoded data). | it (;binary, as opposed to ber encoded data). | |||
C.8.17 Attribute | C.8.17 Attribute | |||
- Use the term "attribute description" in lieu of "type" | - Use the term "attribute description" in lieu of "type" | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 51 | Sermersheim Internet-Draft - Expires Apr 2003 Page 51 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Clarified the fact that clients cannot rely on any apparent | - Clarified the fact that clients cannot rely on any apparent | |||
ordering of attribute values. | ordering of attribute values. | |||
C.8.18 LDAPResult | C.8.18 LDAPResult | |||
- To resultCode, added ellipses "..." to the enumeration to indicate | - To resultCode, added ellipses "..." to the enumeration to indicate | |||
extensibility. and added a note, pointing to [LDAPIANA] | extensibility. and added a note, pointing to [LDAPIANA] | |||
skipping to change at line 2849 | skipping to change at line 3493 | |||
- Added as normative appendix A | - Added as normative appendix A | |||
C.8.25 ASN.1 | C.8.25 ASN.1 | |||
- Added EXTENSIBILITY IMPLIED | - Added EXTENSIBILITY IMPLIED | |||
- Added a number of comments holding referenced to [Models] and | - Added a number of comments holding referenced to [Models] and | |||
[ISO10646]. | [ISO10646]. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 52 | Sermersheim Internet-Draft - Expires Apr 2003 Page 52 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Removed AttributeType. It is not used. | - Removed AttributeType. It is not used. | |||
C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt: | C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt: | |||
- Removed all mention of transfer encodings and the binary attribute | - Removed all mention of transfer encodings and the binary attribute | |||
option | option | |||
- Further alignment with [Models]. | - Further alignment with [Models]. | |||
- Added extensibility ellipsis to protocol op choice | - Added extensibility ellipsis to protocol op choice | |||
- In 4.1.1, clarified when connections may be dropped due to | - In 4.1.1, clarified when connections may be dropped due to | |||
malformed PDUs | malformed PDUs | |||
- Specified which matching rules and syntaxes are used for various | - Specified which matching rules and syntaxes are used for various | |||
filter items | filter items | |||
C.10 Changes made to draft-ietf-ldapbis-protocol-07.txt: | ||||
C.10.1 Section 4.1.1.1: | ||||
- Clarified when it is and isn't appropriate to return an already | ||||
used result code. | ||||
C.10.2 Section 4.1.11: | ||||
- Clarified that a control only applies to the message it's attached | ||||
to. | ||||
- Explained that the criticality field is only applicable to certain | ||||
request messages. | ||||
- Added language regarding the combination of controls. | ||||
C.10.3 Section 4.11: | ||||
- Explained that Abandon and Unbind cannot be abandoned, and | ||||
illustrated how to determine whether an operation has been | ||||
abandoned. | ||||
Appendix D - Outstanding Work Items | Appendix D - Outstanding Work Items | |||
D.0 Integrate notational consistency agreements | D.0 Integrate notational consistency agreements | |||
- WG will discuss notation consistency. Once agreement happens, | - WG will discuss notation consistency. Once agreement happens, | |||
reconcile draft. | reconcile draft. | |||
D.1 Integrate result codes draft. | D.1 Integrate result codes draft. | |||
- The result codes draft should be reconciled with this draft. | - The result codes draft should be reconciled with this draft. | |||
Operation-specific instructions will reside with operations while | Operation-specific instructions will reside with operations while | |||
the error-specific sections will be added as an appendix. Note | the error-specific sections will be added as an appendix. Note | |||
Sermersheim Internet-Draft - Expires Apr 2003 Page 53 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
that there is a result codes appendix now. Still need to reconcile | that there is a result codes appendix now. Still need to reconcile | |||
with each operation. | with each operation. | |||
D.2 Verify references. | D.2 Verify references. | |||
- Many referenced documents have changed. Ensure references and | - Many referenced documents have changed. Ensure references and | |||
section numbers are correct. | section numbers are correct. | |||
D.3 Usage of Naming Context | D.3 Usage of Naming Context | |||
- Make sure occurrences of "namingcontext" and "naming context" are | - Make sure occurrences of "namingcontext" and "naming context" are | |||
consistent with [Models]. | consistent with [Models]. | |||
D.5 Section 4.1.1.1 | ||||
- Remove "or of the abandoned operation until it has received a | ||||
response from the server for another request invoked subsequent to | ||||
the abandonRequest," from the fourth paragraph as this imposes | ||||
synchronous behavior on the server. | ||||
D.14 Section 4.1.12 | D.14 Section 4.1.12 | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 53 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- Specify whether or not servers are to advertise the OIDs of known | - Specify whether or not servers are to advertise the OIDs of known | |||
response controls. | response controls. | |||
D.18 Section 4.2.3 | D.18 Section 4.2.3 | |||
- Change "If the bind was successful, the resultCode will be | - Change "operationsError" to "other" as a bind result code. | |||
success, otherwise it will be one of" to "If the bind was | ||||
successful, the resultCode will be success, otherwise it MAY be | ||||
one of" in the third paragraph. <May need further refinement when | ||||
reconciled with resultCode draft>. | ||||
- Change "operationsError" to "other" as a result code. | ||||
D.21 Section 4.5.1 | D.21 Section 4.5.1 | |||
- Make sure the use of "subordinates" in the derefInSearching | - Make sure the use of "subordinates" in the derefInSearching | |||
definition is correct. See "derefInSearching" on list. | definition is correct. See "derefInSearching" on list. | |||
D.23 Section 4.5.3 | D.23 Section 4.5.3 | |||
- Add "Similarly, a server MUST NOT return a SearchResultReference | - Add "Similarly, a server MUST NOT return a SearchResultReference | |||
when the scope of the search is baseObject. If a client receives | when the scope of the search is baseObject. If a client receives | |||
skipping to change at line 2944 | skipping to change at line 3601 | |||
D.25 Section 4.6 | D.25 Section 4.6 | |||
- Resolve the meaning of "and is ignored if the attribute does not | - Resolve the meaning of "and is ignored if the attribute does not | |||
exist". See "modify: "non-existent attribute"" on the list. | exist". See "modify: "non-existent attribute"" on the list. | |||
D.27 Section 4.10 | D.27 Section 4.10 | |||
- Specify what happens when the attr is missing vs. attr isn't in | - Specify what happens when the attr is missing vs. attr isn't in | |||
schema. Also what happens if there's no equality matching rule. | schema. Also what happens if there's no equality matching rule. | |||
D.28 Section 4.11 | D.30 Section 5.1 | |||
- Change "(since these may have been in transit when the abandon was | ||||
requested)." to "(since these may either have been in transit when | ||||
the abandon was requested, or are not able to be abandoned)." in | ||||
the fifth paragraph. | ||||
- Add "Abandon and Unbind operations are not able to be abandoned. | ||||
Other operations, in particular update operations, or operations | ||||
that have been chained, may not be abandonable (or immediately | ||||
abandonable)." as the sixth paragraph. | ||||
Sermersheim Internet-Draft - Expires Dec 2002 Page 54 | Sermersheim Internet-Draft - Expires Apr 2003 Page 54 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
D.30 Section 5.1 | ||||
- Add "control and extended operation values" to last paragraph. See | - Add "control and extended operation values" to last paragraph. See | |||
"LBER (BER Restrictions)" on list. | "LBER (BER Restrictions)" on list. | |||
D.31 Section 5.2.1 | ||||
- Add "using the BER-based described in section 5.1". | ||||
D.32 Section 6.1 | D.32 Section 6.1 | |||
- Add "that are used by those attributes" to the first paragraph. | - Add "that are used by those attributes" to the first paragraph. | |||
- Add "Servers which support update operations MUST, and other | - Add "Servers which support update operations MUST, and other | |||
servers SHOULD, support strong authentication mechanisms described | servers SHOULD, support strong authentication mechanisms described | |||
in [RFC2829]." as a second paragraph. | in [RFC2829]." as a second paragraph. | |||
- Add "Servers which provide access to sensitive information MUST, | - Add "Servers which provide access to sensitive information MUST, | |||
and other servers SHOULD support privacy protections such as those | and other servers SHOULD support privacy protections such as those | |||
described in [RFC2829] and [RFC2830]." as a third paragraph. | described in [RFC2829] and [RFC2830]." as a third paragraph. | |||
skipping to change at line 2997 | skipping to change at line 3639 | |||
obscurity should implement appropriate access controls to | obscurity should implement appropriate access controls to | |||
restricts access to operational attributes per local policy." as | restricts access to operational attributes per local policy." as | |||
an eighth paragraph. | an eighth paragraph. | |||
- Add "This document provides a mechanism which clients may use to | - Add "This document provides a mechanism which clients may use to | |||
discover operational attributes. Those relying on security by | discover operational attributes. Those relying on security by | |||
obscurity should implement appropriate access controls to | obscurity should implement appropriate access controls to | |||
restricts access to operational attributes per local policy." as | restricts access to operational attributes per local policy." as | |||
an eighth paragraph. | an eighth paragraph. | |||
- Add notes regarding DoS attack found by CERT advisories. | - Add notes regarding DoS attack found by CERT advisories. | |||
Sermersheim Internet-Draft - Expires Dec 2002 Page 55 | Sermersheim Internet-Draft - Expires Apr 2003 Page 55 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
skipping to change at line 3028 | skipping to change at line 3670 | |||
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 Dec 2002 Page 56 | Sermersheim Internet-Draft - Expires Apr 2003 Page 56 | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |