Re: Comments on draft-ietf-http-negotiation-00.txt

>>I really don't care whether or not they are part of TCN -- what is important
>>is that TCN not screw-over other forms of negotiation (namely, agent-driven)
>>that also use the Alternates information, but without any need for
>>contortions due to transparency.
>
>Ah, so *that* is your problem.  Well, I see Alternates as intimately
>connected to TCN, while the concept of a variant list is more general.  In
>the TCN spec, the Alternates header acts as a flag to proxies that this
>response is transparently negotiated.  If you want to use variant lists
>outside of TCN, you should put them in another header.

Because it is unreasonable to expect implementations to send two
lists of Alternates when there are already concerns regarding performance
and bandwidth usage in only sending one list.  Besides, the content
of the two lists would be identical -- the only thing you have changed
is the set of required behavior for using Alternates and Content-Location,
and it is only those requirements that need to be dropped in order
for both forms of negotiation to use a single list.

In other words, define the header fields as a proper abstraction of
their meaning, and not how they fit within a particular algorithm.
If you do that, you can change the algorithm without necessarily
changing the field definitions.

>If you think that the 1.1 spec reserves Alternates for all forms of
>agent-driven negotiation, and that TCN should use some other kind of flag if
>it needs one, then say so.

I thought I already did, several times.

....Roy

Received on Wednesday, 19 February 1997 15:33:18 UTC