[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Continuation reference to root DN
Good point. 4.1.10 is broken when an alias points to the empty DN. One could easily loop on this problem.
To fix this we'd either need a well-known "root dn", or we need to slightly revise LDAPURL and Protocol.
I propose we change LDAPURL to define ldapurl as:
ldapurl = scheme "://" [hostport] [specification]
specification = "/" dn
["?" [attributes] ["?" [scope]
["?" [filter] ["?" extensions]]]]
Then, the protocol could state that the <specification> part MUST be present... This allows (by virtue of the inclusion or exclusion of the "/") one to explicitly name and distinguish the root DN.
Jim
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 11/17/02 09:06AM >>>
Kurt D. Zeilenga writes:
>At 05:38 AM 2002-11-15, Hallvard B Furuseth wrote:
>>The protocol draft says:
>>> 4.5.3 "Continuation References in the Search Result" says:
>>> The SearchResultReference is of the same data type as the Referral.
>>> URLs for servers implementing the LDAP protocol are written according
>>> to [LDAPDN]. The <dn> part MUST be present in the URL,
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> What if one wants to specify a search from basedn ""?
>
> Provide an present but empty <dn> part.
Well, maybe. Since there is no difference between the two, I have
difficulty reading the sentence as something else than "the DN may MUST
NOT be empty." How about replacing that sentence with:
If the DN has length zero, it means the root DN "" and not a default
DN.
This makes the contrast with 4.1.10. Referral clear. There, an absent
DN means use the old DN. (Which BTW means that referrals cannot refer
to the root DN.)
--
Hallvard