- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Wed, 19 Feb 1997 15:24:36 -0800
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg@cuckoo.hpl.hp.com
>>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