[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 2/28/01 8:00:35 PM >>>
>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'?

It should be 'or of'. This is a stray typo introduced by pulling out a previous change.

>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?

How about "containing an encoded attribute value data type"?

>Before 4.1.8
>
>        Clients may
>   use attribute values as assertion values in compare requests and
>   search filters.
>
>How can this be?

I'm not sure what the intent of that sentence is. I'll ask Mark.

>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'?

Some responses return LDAPResult, another returns COMPONENTS OF LDAPResult. We could reword to: "...servers will return responses of LDAPResult or responses containing the componsnts of LDAPResponse to indicate...".

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

We could do that.

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

I think this is just extra information. We could choose to pull it out, and doing so wouldn't affect the protocol, but I don't see it as misleading or confusing. Do you think it causes problems?

I'll add the above items to the tracking list.

Jim

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