--- 1/draft-ietf-ldapbis-protocol-04.txt 2006-02-05 00:11:46.000000000 +0100 +++ 2/draft-ietf-ldapbis-protocol-05.txt 2006-02-05 00:11:47.000000000 +0100 @@ -1,14 +1,14 @@ Internet-Draft Editor: J. Sermersheim Intended Category: Standard Track Novell, Inc -Document: draft-ietf-ldapbis-protocol-04.txt October 2001 +Document: draft-ietf-ldapbis-protocol-05.txt October 2001 Obsoletes: RFC 2251 Lightweight Directory Access Protocol (v3) 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering @@ -252,21 +252,21 @@ Some attributes, termed operational attributes, are used by servers for administering the directory system itself. They are not returned in search results unless explicitly requested by name. Attributes which are not operational, such as "mail", will have their schema and syntax constraints enforced by servers, but servers will generally not make use of their values. Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions, the - schema controlling that entry (specified in the subschema û see + schema controlling that entry (specified in the subschema “ see below), or are operational attributes known to that server and used for administrative purposes. Note that there is a particular objectClass 'extensibleObject' defined in [RFC2252] which permits all user attributes to be present in an entry. Entries MAY contain, among others, the following operational attributes, defined in [RFC2252]. These attributes are maintained automatically by the server and are not modifiable by clients: - creatorsName: the Distinguished Name of the user who added this @@ -765,21 +765,21 @@ components separated by periods, e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33". MatchingRuleId ::= LDAPString Servers which support matching rules for use in the extensibleMatch search filter MUST list the matching rules they implement in subschema entries, using the matchingRules attributes. The server SHOULD also list there, using the matchingRuleUse attribute, the attribute types with which each matching rule can be used. More - information is given in section 4.4 of [RFC2252]. + information is given in section 4.5 of [RFC2252]. 4.1.10. Result Message The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. To various requests, servers will return responses of LDAPResult or responses containing the components of LDAPResponse to indicate the final status of a protocol operation request. Lightweight Directory Access Protocol Version 3 @@ -1263,22 +1263,22 @@ derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeDescriptionList } Filter ::= CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, + and [0] SET SIZE (1..MAX) OF Filter, + or [1] SET SIZE (1..MAX) OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion } SubstringFilter ::= SEQUENCE { @@ -1445,22 +1445,22 @@ name, since there may be extremely large number of values for certain operational attributes. (A list of operational attributes for use in LDAP is given in [RFC2252].) Note that an X.500 "list"-like operation can be emulated by the client requesting a one-level LDAP search operation with a filter checking for the presence of the objectClass attribute, and that an X.500 "read"-like operation can be emulated by a base object LDAP search operation with the same filter. A server which provides a gateway to X.500 is not required to use the Read or List operations, - although it may choose to do so, and if it does must provide the same - semantics as the X.500 search operation. + although it may choose to do so, and if it does, it must provide the + same semantics as the X.500 search operation. Lightweight Directory Access Protocol Version 3 4.5.2. Search Result The results of the search attempted by the server upon receipt of a Search Request are returned in Search Responses, which are LDAP messages containing either SearchResultEntry, SearchResultReference, or SearchResultDone data types. @@ -1870,21 +1870,21 @@ values. 4.11. Abandon Operation The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation. The Abandon Request is defined as follows: AbandonRequest ::= [APPLICATION 16] MessageID - The MessageID MUST be that of a an operation which was requested + The MessageID MUST be that of an operation which was requested earlier in this connection. (The abandon request itself has its own message id. This is distinct from the id of the earlier operation being abandoned.) There is no response defined in the Abandon Operation. Upon transmission of an Abandon Operation, a client may expect that the operation identified by the Message ID in the Abandon Request will be abandoned. In the event that a server receives an Abandon Request on a Search Operation in the midst of transmitting responses to the @@ -2032,21 +2032,21 @@ distinguished name of the client (an LDAPDN) is agreed through the negotiation of the credentials, it takes precedence over any value in the unprotected name field. Implementations which cache attributes and entries obtained via LDAP MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies which prevent the return of entries or attributes in search results except to particular authenticated clients. For example, caches could serve result information only to the client - whose request caused it to be cache. + whose request caused it to be in the cache. 8. Acknowledgements This document is an update to RFC 2251, by Mark Wahl, Tim Howes, and Steve Kille. Their work along with the input of individuals of the IETF LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully acknowledged. 9. Bibliography @@ -2194,25 +2194,25 @@ success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), -- 9 reserved -- - referral (10), -- new - adminLimitExceeded (11), -- new - unavailableCriticalExtension (12), -- new - confidentialityRequired (13), -- new - saslBindInProgress (14), -- new + referral (10), + adminLimitExceeded (11), + unavailableCriticalExtension (12), + confidentialityRequired (13), + saslBindInProgress (14), noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), -- 22-31 unused -- noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), @@ -2230,21 +2230,21 @@ namingViolation (64), objectClassViolation (65), notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), Lightweight Directory Access Protocol Version 3 objectClassModsProhibited (69), -- 70 reserved for CLDAP -- - affectsMultipleDSAs (71), -- new + affectsMultipleDSAs (71), -- 72-79 unused -- other (80) }, -- 81-90 reserved for APIs -- matchedDN LDAPDN, errorMessage LDAPString, referral [3] Referral OPTIONAL } Referral ::= SEQUENCE OF LDAPURL LDAPURL ::= LDAPString -- limited to characters permitted in @@ -2291,22 +2291,22 @@ sizeLimit INTEGER (0 .. maxInt), Lightweight Directory Access Protocol Version 3 timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeDescriptionList } Filter ::= CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, + and [0] SET SIZE (1..MAX) OF Filter, + or [1] SET SIZE (1..MAX) OF Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion } SubstringFilter ::= SEQUENCE { @@ -2679,20 +2679,31 @@ - Changed heading from "Mapping Onto BER-based Transport Services" to "Protocol Encoding". B.5.9 Section 5.2.1 - Changed "The LDAPMessage PDUs" to "The encoded LDAPMessage PDUs" to point out that the PDUs are encoded before being streamed to TCP. +B.6 Changes made to draft-ietf-ldapbis-protocol-03.txt: + +B.6.1 Section 4.5.1 and Appendix A + + - Changed the ASN.1 for the and and or choices of Filter to have a + lower range of 1. This was an omission in the original ASN.1 + +B.6.2 Various + + - Fixed various typo's + Appendix C - Outstanding Work Items C.1 Integrate result codes draft. - The result codes draft should be reconciled with this draft. Operation-specific instructions will reside with operations while the error-specific sections will be added as an appendix. C.2 Section 3.1 @@ -2712,34 +2723,34 @@ - Change "the client may discard the PDU, or may abruptly close the connection." to "the client MAY discard the PDU, or MAY abruptly close the connection." in the fourth paragraph. C.5 Section 4.1.1.1 - Add "If an unsolicited notification as described in section 4.4 is sent from a server, the messageID value MUST be zero." to first paragraph. + + Lightweight Directory Access Protocol Version 3 + - Change "MUST have a value different" to "MUST have a non-zero value different" in the second paragraph. - Remove "or of the abandoned operation until it has received a response from the server for another request invoked subsequent to the abandonRequest," from the fourth paragraph as this imposes synchronous behavior on the server. C.7 Section 4.1.4 - Add "Note that due to the restriction above, and due to this allowance, servers MUST ensure that, within a controlling - - Lightweight Directory Access Protocol Version 3 - subschema, no two attributes be named the same." to the fifth paragraph. - Resolve issue on list with the subject "Attribute Type character set". C.8 Section 4.1.5 - Change "A server may treat" to "A server MUST treat" in the second to last paragraph. - Change "A server MUST treat an AttributeDescription with any @@ -2768,35 +2779,33 @@ C.11 Section 4.1.7 - Change "For all the string-valued user attributes described in [5], the assertion value syntax is the same as the value syntax." to "The assertion value syntax for all attributes using human- readable syntaxes as described in [RFC2252] is the same as the value syntax unless otherwise noted (an example being objectIdentifierFirstComponentMatch)." in the third paragraph. - Find out what the last sentence in third paragraph means (Clients may use attributes...) + + Lightweight Directory Access Protocol Version 3 + - Add a fourth paragraph: "Servers SHOULD NOT generate codes 81-90 as these are reserved for use by historical APIs [RFC 1823]. Later API specifications SHOULD avoid using the resultCode enumeration to represent anything other than a protocol result indication." C.13 Section 4.1.11 - - Resolve the intent of "All the URLs MUST be equally capable of - being used to progress the operation" This is being discussed as - "Following referrals" on the list. - Add "after locating the target entry" to the first paragraph. - Lightweight Directory Access Protocol Version 3 - C.14 Section 4.1.12 - Specify whether or not servers are to advertise the OIDs of known response controls. C.15 Section 4.2 - Change "LDAPDN" to "identity" in the definition of the name field. - Rework definition of the name field to enumerate empty password and name combinations. @@ -2826,32 +2835,33 @@ assume" in the second paragraph. - Change "and may close the connection" to "and MUST close the connection" in the second paragraph. C.20 Section 4.4 - Add "Servers SHOULD NOT assume LDAPv3 clients understand or recognize unsolicited notifications or unsolicited controls other than Notice of Disconnection defined below. Servers SHOULD avoid sending unsolicited notifications unless they know (by related + + Lightweight Directory Access Protocol Version 3 + request or other means) that the client can make use of the notification." as a fourth paragraph. C.21 Section 4.5.1 - Make sure the use of "subordinates" in the derefInSearching definition is correct. See "derefInSearching" on list. C.22 Section 4.5.2 - Lightweight Directory Access Protocol Version 3 - - Add "associated with a search operation" to the sixth paragraph. - Same problem as in C.5. C.23 Section 4.5.3 - Add "Similarly, a server MUST NOT return a SearchResultReference when the scope of the search is baseObject. If a client receives such a SearchResultReference it MUST interpret is as a protocol error and MUST NOT follow it." to the first paragraph. - Add "If the scope part of the LDAP URL is present, the client MUST @@ -2881,32 +2891,33 @@ schema. Also what happens if there's no equality matching rule. C.28 Section 4.11 - Change "(since these may have been in transit when the abandon was requested)." to "(since these may either have been in transit when the abandon was requested, or are not able to be abandoned)." in the fifth paragraph. - Add "Abandon and Unbind operations are not able to be abandoned. Other operations, in particular update operations, or operations + + Lightweight Directory Access Protocol Version 3 + that have been chained, may not be abandonable (or immediately abandonable)." as the sixth paragraph. C.29 Section 4.12 - Change "digitally signed operations and results" to "for instance StartTLS [RFC2830]" C.30 Section 5.1 - Lightweight Directory Access Protocol Version 3 - - Add "control and extended operation values" to last paragraph. See "LBER (BER Restrictions)" on list. C.31 Section 5.2.1 - Add "using the BER-based described in section 5.1". C.32 Section 6.1 - Add "that are used by those attributes" to the first paragraph.