Subject: Re: Protocol: referrals and other URIs

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 13 Nov 2003 13:28:29 -0700

A couple IETF 58 attendees are proposing the following wording to
replace the existing wording:

Other kinds of URIs may be returned. The syntax and symantics of such
URIs is left to future specifications. Clients ignore URIs that they
don't support.

Jim

>>> "Jong" <[email-masked]> 11/13/03 9:38:52 AM >>>
> >The server's knowledge on the other opaque protocols is an
implementational one
> >and hence needs to be treated as such in the protocol
specification.
>
> Yes, and as such, no server protocol implementation can be expected
to
> understand the relationship between operations and non-LDAP
protocols.
> And since no provision is given to allow an administrator to specify
> such a relationship, the current language is impossible to adhere
to.
>
> If there were some "applicable operations" field in referral URIs,
then
> the current language would be possible to adhere to. But there is
not.

The configuration of referrals in the server is implementation
depedent.
Should such relationships bw. operations and non-LDAP protocols
are needed, it can be specified in an implementation dependent way
without touching referral URIs. I agree to the need for a wording
change,
in that the server may return other kinds of URIs subject to its
knowledge
of that protocol, and the client may follow it also subject to its
knowledge.

> >The client needs to be prepared for the server which has imprecise
information
> >on the other protocols, but IMHO, this seems to be outside of the
protocol
specification.
> >- Jong
>
> I agree. Currently, there is no wording that assures a client that
it
> will receive a URI which it will know how to follow. This is good.

---

From: "Jong" <[email-masked]>
Date: Thu, 13 Nov 2003 17:07:58 -0500

> URIs is left to future specifications. Clients ignore URIs that they

Looks fine.
We have another in section 4.5.3 for continuation references.
- Jong

---

From: [email-masked] (Mark C Smith)
Date: Thu, 13 Nov 2003 21:04:08 -0500

>>URIs is left to future specifications. Clients ignore URIs that they

I am not sure we should say that clients ignore URIs that they do not 
understand. A client may want to display them to the user or report an 
error in some way if a referral was returned that could not be followed 
(or understood).

-Mark

---

From: "Jong" <[email-masked]>
Date: Fri, 14 Nov 2003 21:58:23 -0500

> error in some way if a referral was returned that could not be followed

The same also seems to apply to other paragraphs of 4.1.10 :
   If the client wishes to progress the operation, it MUST follow the
   referral by contacting one of the services. If multiple URIs are
   present, the client assumes that any URI may be used to progress the
   operation.
=>
   If the client wishes to progress the operation, it MUST follow the
   referral by contacting one of the supported services. If multiple URIs are
   present, the client assumes that any supported URI may be used to progress the
   operation.

Likewise, instead of saying "Clients ignore URIs that they don't support",
how about saying "clients MUST follow referrals they support if it wishes to progress"
here as well ?

- Jong