Subject: I-D ACTION:draft-ietf-ldapbis-url-05.txt

From: [email-masked]
Date: Mon, 16 Feb 2004 15:41:59 -0500

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		: LDAP: Uniform Resource Locator
	Author(s)	: M. Smith, T. Howes
	Filename	: draft-ietf-ldapbis-url-05.txt
	Pages		: 14
	Date		: 2004-2-16
	
This document describes a format for an LDAP Uniform Resource Locator
(URL).  An LDAP URL describes an LDAP search operation that is used
to retrieve information from an LDAP directory, or, in the context of
an LDAPv3 referral or reference, an LDAP URL describes a service
where an LDAP operation may be progressed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-url-05.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-url-05.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapbis-url-05.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.

---

From: "Andrew Sciberras" <[email-masked]>
Date: Tue, 17 Feb 2004 09:04:57 +1100

G'day,

Just some comments:

Section 4. Introduction.
Include "MUST NOT" and "SHOULD NOT" in the final paragraph.

Section 5. URL Definition

>SLASH = %x5C; forward slash ("/")
%x5C is the backslash, use %x2F instead.

>The "ldap" prefix indicates an entry or entries residing in the LDAP
>server running on the given hostname at the given portnumber.
Does this imply that it would be wrong to chain the request, if the server
is able to do so?

>An extension prefixed with a '!'character (ASCII 33)
>is critical.
Wouldn't it be better to maintain consistency and use hex (0x21) instead of
decimal (33)?

>If an LDAP URL extension is recognised by an implementation, the
>implementation MUST make use of it.
What if you recognise it, but don't implement it?
If it is not critical then I see no reason why the operation should not
proceed.

Regards,

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Feb 2004 18:05:23 -0500

> Include "MUST NOT" and "SHOULD NOT" in the final paragraph.

Good catch.  I will add those.

> %x5C is the backslash, use %x2F instead.

Oops.  Thanks; I will fix it.

> Does this imply that it would be wrong to chain the request, if the server

No, I do not think so.  The phrase "residing in" is probably too 
restrictive.  Perhaps replace with "accessible from" so it reads:

   The "ldap" prefix indicates an entry or entries accessible from
   the LDAP server running on the given hostname at the given portnumber.

?

> Wouldn't it be better to maintain consistency and use hex (0x21) instead of

OK; good suggestion.

> If it is not critical then I see no reason why the operation should not

Kurt can probably explain this better than I can... but the goal is to 
be consistent the philopsophy used for LDAP controls in the Protocol 
document.  I think "recognized" implies "ability to use" an extension; 
that is, if an implementation recognizes an extension it is able to use it.

-Mark

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 16 Feb 2004 22:23:27 -0800

At 03:05 PM 2/16/2004, Mark Smith wrote:
>Kurt can probably explain this better than I can... but the goal is to be consistent the philopsophy used for LDAP controls in the Protocol document. 
>I think "recognized" implies "ability to use" an extension; that is, if an implementation recognizes an extension it is able to use it.

I prefer "implement" here over "recognize".  Like a number of
other protocol tokens, it is possible to "recognize" an
token without actually implementing the syntax and semantics
associated with that token.   For instance, a implementation
could recognize the bindname extension but not implement it
(maybe the implementation only supports the mandatory-to-implement
authentication mechanism (e.g., DIGEST-MD5)).

Ron asked:
>Why are they called extensions and not controls?  It looks a bit misleading to me. (LDAP can be extended in a number of ways.)

I think it would be misleading to call them LDAP URL Controls
as they would confused with LDAP Controls.  LDAP URL Extensions
are not necessarily LDAP Controls.

Kurt