[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.