RE: I-D ACTION:draft-ietf-ldapbis-protocol-01.txt

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi,

Before 4.1.2:

   A client MUST NOT reuse the message id of an abandonRequest of the
   abandoned operation until it has received a response from the server
   for another request invoked subsequent to the abandonRequest, as the
   abandonRequest itself does not have a response.

Should the second 'of' be an 'or'?

Start of 4.1.6

   A field of type AttributeValue is an OCTET STRING containing an
   encoded value of an AttributeValue data type.

Isn't this self-referential?

Before 4.1.8

        Clients may
   use attribute values as assertion values in compare requests and
   search filters.

How can this be?

4.1.10

        In response
   to various requests, servers will return responses containing fields
   of type LDAPResult to indicate the final status of a protocol
   operation request.

But LDAPResult is not a field? Should it actually say 'fields from the type
LDAPResult'?

What about dropping the '--new' from the result codes. It is not new in this
standard, it is new since LDAPv2, which now makes it old.

4.1.11

   The referral is not returned for a singleLevel or wholeSubtree search
   in which the search scope spans multiple naming contexts, and several
   different servers would need to be contacted to complete the
   operation. Instead, continuation references, described in section
   4.5.3, are returned.

Doesn't this rather miss the point. A referral is only returned if the base
object couldn't be located (navigated to). The response to a search 'in
which the search scope spans multiple naming contexts' may be a referral or
not - it doesn't depend on scope or naming contexts.


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, 27 February 2001 22:54
Cc: ietf-ldapbis@OpenLDAP.org
Subject: I-D ACTION:draft-ietf-ldapbis-protocol-01.txt


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-01.txt
	Pages		: 52
	Date		: 26-Feb-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-01.txt

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