Subject: Re: associating constant feature sets with URLs

From: Bill Newman <[email-masked]>
Date: Fri, 15 Jan 1999 08:51:49 -0800 (PST)

Koen wrote

> - Do you have any specific application in mind which needs such a
> delegation mechanism soon?  I don't think this group should develop a
> standard for delegation unless there is some `market demand' for it.

The primary motivation is for mobile device users with complex
capability expressions to be able to describe them concisely over
their low-bandwidth connections by sending a URL instead of the full
text. Graham's message on "Feature set registration scenarios" gives
some other possible scenarios where people might take advantage of the
indirection, and it would be good to make sure those work too, but it
was the mobile device users that Ted talked about at the IETF meeting
and that motivated me.

> - If the server of the <URL> is down then one could recover by having
> the sender of the filter string expand the <URL>s.  Do you mean for
> this type of recovery to be a standard feature of your mechanism?  If
> so it is probably best provided for by requiring that the protocol
> between the sender and recipient has a feature which allows the
> recipient to ask the sender for an expansion.  (For example, if the
> HTTP protocol is used between the sender and the receiver, then the
> mechanism could be an error code which causes the sender to retry the
> request with all <URL>s expanded.)

My intent was that an application running on a mobile device could be
guaranteed that it would have enough information to recover from
failure of the server that it had delegated as the location of its
capability information. If my mobile device's capability expression is
e.g. 800 bytes, I may not want to send it over the slow link, so I'll
send a URL pointing to it instead (pointing to somewhere that the
server can retrieve it over a fast land line). But if for some reason
that fails, it might be better to redo the request with the entire
capability expression expanded out in full -- it'd be slow to transmit
it, but it might be better than not being able to do the operation at
all.

I'd prefer not to specify what the error code tells the client to do
-- I think the error code should just say what went wrong. If we tell
the client that the link to the delegated feature set server is down,
there are at least five sensible things I can imagine the client doing
with the information:
  (1) Give up on the request permanently.
  (2) Try the same request again immediately.
  (3) Try the same request again later.
  (4) Try the same request again with the URLs expanded out in full.
  (5) Try the same request again with the URLs replaced by URLs pointing
      to a mirror of the feature set server.
I don't think we as protocol writers can specify a single behavior 
which is most appropriate in all applications.

  Bill Newman
  [email-masked]

---

From: [email-masked] (Koen Holtman)
Date: Tue, 19 Jan 1999 22:39:45 +0100 (MET)

Bill Newman:
>text. 

Sorry, I think I was not clear enough.  Mobile devices are an obvious
use case but I was wondering whether you had any specific _negotiation
protocol_ which would use it in mind.

Reading some other comments in this thread I gather that, in the last
IETF meeting, the need for a delegation mechanism was discussed, with
the conclusion that it was needed.  I did not attend the meeting, and
I now think that I have the opposite opinion.  I believe we should not
develop a negotiation protocol unless we have at least one negotiation
(transport) protocol which needs it in mind.  When one defines a
negotiation (transport) protocol, it is relatively trivial to define a
suitable delegation protocol, if needed, along with it.

I see that Ted calls a delegation protocol 'the hardest problem this
group has left to solve' but I don't think we should touch delegation
at all unless we want to be a whole lot more concrete about specific
transport-level negotiation protocols than we have been up to now.

The interoperability benefits of a generic delegation protocol (which
is not part of a generic transport protocol) are small at best I
think.  And if we define such a protocol in a vacuum, we run a big
change of it having either the wrong mechanisms for specific transport
situations, or having a too bloated set of mechanisms.  All in all the
that risk/benefit ratio developing such a thing is not very good, so
I'd rather not do it.

[...]
>there are at least five sensible things I can imagine the client doing

I think you misunderstood me: it is my intention that the recipient of
the <URL>, not the client sending it, implements the decision logic
needed to recover from errors when the recipient tries to connect to
the delegated feature set server.  The client should not get involved
in error recovery, except that it must send the complete feature set
when asked to.  Error recovery logic is best placed at the location
where the error occurs, and were all information about the error is
readily available, without the need for an error code transport
protocol.

>  [email-masked]

Koen.