Subject: URL dn part [revised]

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 May 2001 00:04:51 -0700

[rewritten for clarity, please ignore previous version]

As previously discussed,
	ldap://host
	ldap://host/

should be viewed as equivalent.  While the section 4 statement
	If no dn is given, the default is the zero-length DN, ""

is clear that the DN is optional, the ANBF:

       ldapurl    = scheme "://" [hostport] ["/"
                    [dn ["?" [attributes] ["?" [scope]
                    ["?" [filter] ["?" extensions]]]]]]

is somewhat ambiguous.  The URL:
	ldap://host/

can be parsed as dn absent OR dn present but empty.  The fact
that the grammar also allows
	ldap://host

implies that this distinction is somehow important.

This ambiguity could be removed with:
       ldapurl    = scheme "://" [hostport] ["/" dn
                    ["?" [attributes] ["?" [scope]
                    ["?" [filter] ["?" extensions]]]]]]

That is, ldap::/// can only be parsed as having a present
but empty dn part.  I prefer this ABNF production as
it appears to handle optional features more consistently.

To provide additional clarity, I also suggest adding an
additional example:

 The following URLs are equivalent:
	ldap://ldap.example.net
	ldap://ldap.example.net/
	ldap://ldap.example.net/?

 Each refers to the Root DSE on the ldap.example.net server.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 May 2001 14:29:58 -0400

> it appears to handle optional features more consistently.

I agree.  Any objections?  I will make this change to the document
unless someone objects.

>  Each refers to the Root DSE on the ldap.example.net server.

I am sure you know that these URLs are not equivalent when interpreted
as LDAP referrals because the first one does not include a DN (per
section 4.1.11 of 2251).  But I will add these examples and a note that
they are all equivalent if the defaulting rules described in section 4
of the URL document are used.

Thanks for the suggestions.  I plan to submit a revised I-D today.

-Mark Smith
 Netscape

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 10 May 2001 11:51:42 -0700

At 11:29 AM 5/10/01, Mark Smith wrote:
>But I will add these examples and a note that

That seems appropriate for 2255bis.  The rest is really a 2251bis issue.

>section 4.1.11 of 2251).

Note that second can be parsed as DN absent as well (per 2255's
ambiguous ABNF).

One could argue that both refer to some entry given the last example
in section 4.5.3.1:
   If the contacted server does not hold the base object for the search,
   then it will return a referral to the client.  For example, if the
   client requests a subtree search of "O=XYZ,C=US" to hosta, the server
   may return only a SearchResultDone containing a referral.

     SearchResultDone (referral) {
       ldap://hostg/
     }

That is,
        ldap://hostg/

does not refer to the root DSE but to O=XYZ,C=US.  Hence, in the
context of a referral
        ldap://hostg
        ldap://hostg/

both equivalent to:
        host://hostg/O=XYZ,C=US

in this context.

That is, I believe that the sentence (4.1.11):
   If the <dn> part is present, the client MUST use this name
   in its next request to progress the operation, and if it is
   not present the client will use the same name as in the
   original request.

should read:
   If the <dn> part is present and not empty, the client MUST
   use this name in its next request to progress the operation,
   otherwise the client will use the same name as in the original
   request.

Now, one could argue the example is wrong, the ABNF meant for
the slash to be significant, and the text should "win".

We have three alternatives:
        1) ldap://host and ldap://host/ are equivalent, fix text.
        2) ldap://host and ldap://host/ are not equivalent, fix example.
        3) referral specific DN defaulting is broken, remove special
        case (treat all URLs per RFC 2255bis).

Kurt