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