Re: URL dn part [revised]

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:29 AM 5/10/01, Mark Smith wrote:
>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.

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


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

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