[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: I-D ACTION:draft-ietf-ldapbis-protocol-01.txt
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.