[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: I-D ACTION:draft-ietf-ldapbis-protocol-03.txt
This version contains a dozen or so changes--mostly issues with consistency, clarifications and items that we had previously reached consensus on. Please review the changelog items B.14 through B.24 (repeated here, but you really need to see them in the context of the I-D to make sense of them)
B.14 Section 4
- Removed "typically" from "and is typically transferred" in the
first paragraph. We know of no (and can conceive of no) case where
this isn't true.
- Added "Section 5.1 specifies how the LDAP protocol is encoded." To
the first paragraph. Added this cross reference for readability.
- Changed "version 3 " to "version 3 or later" in the second
paragraph. This was added to clarify the original intent.
- Changed "protocol version" to "protocol versions" in the third
paragraph. This attribute is multi-valued with the intent of
holding all supported versions, not just one.
B.15 Section 4.1.8
- Changed "when transferred in protocol" to "when transferred from
the server to the client" in the first paragraph. This is to
clarify that this behavior only happens when attributes are being
sent from the server.
B.16 Section 4.1.10
- Changed "servers will return responses containing fields of type
LDAPResult" to "servers will return responses of LDAPResult or
responses containing the components of LDAPResponse". This
statement was incorrect and at odds with the ASN.1. The fix here
reflects the original intent.
- Dropped '--new' from result codes ASN.1. This simplification in
comments just reduces unneeded verbiage.
B.17 Section 4.1.11
- Changed "It contains a reference to another server (or set of
servers)" to "It contains one or more references to one or more
servers or services" in the first paragraph. This reflects the
original intent and clarifies that the URL may point to non-LDAP
services.
B.18 Section 4.1.12
- Changed "The server MUST be prepared" to "Implementations MUST be
prepared" in the eighth paragraph to reflect that both client and
server implementations must be able to handle this (as both parse
controls).
B.19 Section 4.4
- Changed "One unsolicited notification is defined" to "One
unsolicited notification (Notice of Disconnection) is defined" in
the third paragraph. For clarity and readability.
B.20 Section 4.5.1
- Changed "checking for the existence of the objectClass attribute"
to "checking for the presence of the objectClass attribute" in the
last paragraph. This was done as a measure of consistency (we use
the terms present and presence rather than exists and existence in
search filters).
B.21 Section 4.5.3
- Changed "outstanding search operations to different servers," to
"outstanding search operations" in the fifth paragraph as they may
be to the same server. This is a point of clarification.
B.22 Section 4.6
- Changed "clients MUST NOT attempt to delete" to "clients MUST NOT
attempt to add or delete" in the second to last paragraph.
- Change "using the "delete" form" to "using the "add" or "delete"
form" in the second to last paragraph.
B.23 Section 4.7
- Changed "Clients MUST NOT supply the createTimestamp or
creatorsName attributes, since these will be generated
automatically by the server." to "Clients MUST NOT supply NO-USER-
MODIFICATION attributes such as createTimestamp or creatorsName
attributes, since these are provided by the server." in the
definition of the attributes field. This tightens the language to
reflect the original intent and to not leave a hole in which one
could interpret the two attributes mentioned as the only non-
writable attributes.
B.24 Section 4.11
- Changed "has been" to "will be" in the fourth paragraph. This
clarifies that the server will (not has) abandon the operation.
>>> <Internet-Drafts@ietf.org> 11/07/01 05:06AM >>>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP (v3) Revision Working Group of the IETF.
Title : Lightweight Directory Access Protocol (v3)
Author(s) : J. Sermersheim
Filename : draft-ietf-ldapbis-protocol-03.txt
Pages : 54
Date : 06-Nov-01
The protocol described in this document is designed to provide access
to directories supporting the [X.500] models, while not incurring the
resource requirements of the X.500 Directory Access Protocol (DAP).
This protocol is specifically targeted at management applications and
browser applications that provide read/write interactive access to
directories. When used with a directory supporting the X.500
protocols, it is intended to be a complement to the X.500 DAP.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-03.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ldapbis-protocol-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ldapbis-protocol-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.