Subject: Re: Equally capable referrals

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 06 Nov 2001 17:01:43 -0700

This explains the intent of equally capable nicely, but my bigger question is: Who's responsibility is it to enforce the "MUSTness" of the statement? If it's the server's responsibility, I don't see how that's a reasonable requirement without the existence of a standardized set of mechanisms and semantics for server behavior in a distributed environment when dealing with the administration of referrals.

How will I be prevented from adding a referral object that points to a server that doesn't hold the base in the referral?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 11/06/01 04:25PM >>>
I think the sentence must be taken in consideration with the
preceding sentence.

I think the intent is fairly clear.  The server should return
a set of URLs which refer to servers which can complete the
operation.  No preference is implied by the order.  To chase,
the client needs only to contact one server.  If that server
is not available, the client can contact another.

By available, I mean that the client can establish a TCP
connect, issue a bind/starttls (as desired), and the
operation to be continued.  If the connect or preliminary
operations fail, the client can try other listed servers.
However, if the operation results in an error (other than
referral), the operation has been completed and hence the
client should not attempt to contact any of the other
servers.  If the result is a referral, then that operation
can be chased.

Kurt

At 02:26 PM 2001-11-06, Steve Sonntag wrote:
>I have some concerns about loosening the wording.
>
>This puts a burden on the application or the API when following referrals.
>It is not enough to find a server that exists, but the server must  
>--process the search with the referral dn and return
>   a non zero result code?
>   (the dn must exist and the application must be able to read the root
>    dn?)
>--If the application/API gets a non zero return code, should it try the
>  next referral in the list if there is one?
>
>But, I can see a case where the administrator gives a valid DN, but no
>Entries are on the server under the base DN.  It looks to the application
>like everything succeeded, but in reality the data was not on that server.
>I think loosening the wording dilutes the value of referrals.
>
>What behavior do we expect of applications  when servers
>are encountered that cannot process the referral, and how does the
>application determine that the server could not follow the referral.
>
>--Steve
>
>>>> Stig Venaas <[email-masked]> 06-Nov-01 3:07:56 PM >>>
>On Tue, Nov 06, 2001 at 03:36:37PM -0500, Timothy Hahn wrote:
>> Jim,
>> 
>> Could we possibly just "loosen up" the statement from 'equally capable' to 
>> 'possibly capable'?
>> 
>> If not, then we might as well strike the sentence.  This does leave 
>> implementers "hanging" though in terms of what is intended but not 
>> necessarily written.
>
>Agree completely, I don't like it the way it is currently.
>
>Stig

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 06 Nov 2001 17:02:42 -0800

At 04:01 PM 2001-11-06, Jim Sermersheim wrote:
>This explains the intent of equally capable nicely, but my bigger question is: Who's responsibility is it to enforce the "MUSTness" of the statement? 

Well, given the wording of this particular MUST, it appears to
be server obligation return "equally capable" URLs.  Of course,
if the server uses namedref or dnsref or some other administrative
mechanism, then it server implementation really defers this
obligation to the deployer / administrator.

I think MUST and "equally capable" are a bit strong.
The key is that there is no preferred order and regardless of
which one service is contacted, that service should be
capable of furthering the operation towards completion.
Note the distinction between "completing the operation"
as opposed to "furthering the operation towards completion".
One must allowed the referred to server to return a referral.