[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Summary of issues with the Java LDAP API and resolutions



At 11:12 PM 3/25/01 -0800, Rob Weltman wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 03:38 PM 3/25/01 -0800, Rob Weltman wrote:
>> >  An application is always free to do its own LDAP URL parsing, and there will undoubtedly always be applications that choose to do so. But all applications that implement their own chasing of referrals do not need to distinguish between explicit URL parameters and implied URL parameters.
>> 
>> The scope defaulting is different for search referrals than for
>> search continuations.  In a referral, no explicit scope implies
>> the client should reuse the prior scope.  In a continuation, no
>> explicit scope implies the client should use a base derived from
>> the prior base (base->base, one->base, subtree->base).
>
>  That has already been discussed on this list. The API implementation delivers the referral correctly rewritten so the client doesn't need to worry about it,

I must have missed this point, I was under the impression that this was
a low-level API which provided direct access to all values transferred
by the protocol.  Though I have concerns with this API not providing
a low-level API, the approach you suggest will work (but will limit
the user as all high-level APIs naturally do).  Anyways, I believe the
TS needs much more clarification as to what is expected of implementations
in this area.

>regardless of if using automatic referral following or automatic referral following.




> 
>> >As a matter of fact, in the years I've worked with the Java LDAP API and applications that did their own referral processing, I haven't seen a single such case.
>> 
>> You'll find such a case detailed in RFC 2251 examples!
>
>  The API we propose (and which has been is use for four years now) handles the rewriting of the scope exactly as per RFC 2251 so that there is no need for a client to do it.

That's not how I read the TS.