Subject: Re: referrals/continuations and LDAPUrl (WG last call on theJavaAPI)

From: "Steve Sonntag" <[email-masked]>
Date: Fri, 16 Mar 2001 12:17:45 -0700

Kurt,

In reviewing my previous statement, I realize I spoke hastily.
There are actually three cases here, and the current 
draft is adequate with respect to referrals/continuation
references when automatically following referrals.

1) if automatically following  referrals, the application does not
need to know whether the URL list is from a referral or a search
continuation reference. When following the referral, the API
handles, under the covers, the setting of the appropriate scope
and reissues the modified command on the new connection.

2) When not automatically following referrals on a synchronous
request, if the application gets an LDAPReferralException as the
only result, the LDAPReferralException is a referral.  If the
application receives other results, then the LDAPReferralException
is a search reference.  In any case whether it is a referral or continuation
reference has no effect on the referral handlers as they are not used
when not following referrals.  To not follow referrals is the default
behavior.

3) Automatic referral following is not allowed on an asynchronous
request, and the application knows if the response is a referral
or a search reference by the returned message type.

I hope this clarifies the issue.

-Steve

>>> "Steve Sonntag" <[email-masked]> 16-Mar-01 9:01:52 AM >>>

You are correct. with respect to referrals/continuation references.
The API should inform the user whether the URL
array is for following a referral or a search continuation.  Probably a
boolean argument is adequate to convey this information.

-Steve

>>> "Kurt D. Zeilenga" <[email-masked]> 15-Mar-01 5:10:26 PM >>>
>   The API doesn't distinguish between LDAP search continuation 
>   references and LDAP referrals, presenting a unified interface to the 
>   client for handling the two. 

I would think that an referral/continuation handler provided
the application would need to distinguish the between a
search continuation and a referral. I note that chasing
requirements for referrals and continuations differ, for
example how the client needs to process an LDAP URL with
an absent base differs.

Also, I note it would be useful if methods of LDAPUrl
(4.41.1) distinguished between an explicit and default
parameters of an LDAP URL.  For example getScope() could return
SCOPE_DEFAULT if an explicit scope wasn't provided.  As
this behavior is likely only useful to applications
doing their own referral/reference chasing, likely
best to have some means to enable/disable this behavior.

What does "explicit URL string" imply?  Does it imply
that URLs with implicit parameters are not allowed? 
e.g. LDAPUrl("ldap://")

What does "full-blown LDAP URL" imply?

And "nearest X.500/LDAP"?  nearest?  X.500?

Also, I suggest the default port be 389 so that:
    LDAPUrl("ldap://localhost")
and
    LDAPUrl("localhost", null, null);
are equivalent.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 16 Mar 2001 12:06:07 -0800

At 12:17 PM 3/16/01 -0700, Steve Sonntag wrote:
>is a search reference.

Consider two of many possible responses to a search request:
        a) first response PDU is a search reference result message
        a) first response PDU is a search result done message

How does the API distinguish whether the LDAPReferralException
is a continuation or a referral?

>In any case whether it is a referral or continuation

Assume the application wants to manually chase all referrals and
continuations.  The application needs a means to distinguish what
type of response PDU caused the exception otherwise it is forced
to use the async API to accomplish this.  If that's the case,
then the API TS should state so.

>I hope this clarifies the issue.

So, in this case, the API DOES distinguish between the two.