Re: associating constant feature sets with URLs

Bill Newman:
>
>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. 

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.

[...]
>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:

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.

>  Bill Newman
>  [email protected]

Koen.