Re: associating constant feature sets with URLs

Graham Klyne <[email protected]>
Newsgroups gmane.ietf.medfree
Message-ID <[email protected]>
At 22:39 19/01/99 +0100, Koen Holtman wrote:
[...]
>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 think we are still trying to come to a common understanding.

I did attend the meeting, but I did not have a clear understanding there of
what was being proposed.

>[...]  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 think I broadly agree with what you are saying, here and below, but...

I don't have a clear understanding of what is meant by "delegation
protocol", but I don't see it necessarily being a "negotiation protocol".

>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.

To stand back from these terms, I think this group should focus on
*representation*, not *transfer*, of capability information.

I think is is a fair target to discuss representations of feature sets that
can be used to avoid sending every individual feature constraint
separately, and can be combined with additional constraints that describe
variations from the common set.

I can see that this might be viewed as "delegation", without any discussion
of how the information is actually transferred.

>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.

In a previous message, I called for some scenarios to be set out.  I think
we could also do with some common terminology, because I sense that we are
in danger of "talking past" each other rather than agreeing some common goals.

For starters, what do we mean by "delegation"?  (Other terms are in the
-conneg-requirements- draft.)

#g


------------
Graham Klyne
([email protected])
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.