Re: associating constant feature sets with URLs

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 protected]