Subject: Re: associating constant feature sets with URLs

From: Graham Klyne <[email-masked]>
Date: Wed, 20 Jan 1999 13:32:58 +0000

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-masked])

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Jan 1999 11:34:39 -0800 (PST)

> *representation*, not *transfer*, of capability information.

Obviously, I did not get across what I meant to in my first statement,
because I did not mean to imply that this group should tackle a
delegation protocol.  I meant that we needed to tackle the problem
of representing constant feature groupings.

			regards,
				Ted Hardie

---

From: [email-masked] (Koen Holtman)
Date: Fri, 22 Jan 1999 19:37:43 +0100 (MET)

>>develop a negotiation protocol unless we have at least one negotiation
            ^^^^^^^^^^^^^^^^^^^^
>protocol", but I don't see it necessarily being a "negotiation protocol".

Oops!  I meant 'delegation protocol' where I wrote 'negotiation
protocol' above.  Sorry for the confusion caused.

[....]
>*representation*, not *transfer*, of capability information.

I would agree with this.  It is OK with me if we talk about the
semantics of how a represention of a (partial) feature set can be
merged into another feature set, once it has been transported.

>#g

Koen.