RE: Variant-ID proposal

I object to caches assigning variant-ids. If they're needed for
pre-emptive content negotiation by caches based on what is the
Alternates header, then the origin-server should generate variant-ids
for each alternate and return them in the alternates header.

It'll be a lot simpler that way.

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Sent: 	Tuesday, April 16, 1996 12:31 AM
>To: 	Paul Leach
>Cc: 	fielding@avron.ICS.UCI.EDU; koen@win.tue.nl;
>http-caching@pa.dec.com; jg@w3.org
>Subject: 	Re: Variant-ID proposal
>
>Paul Leach:
>  [Koen Holtman:]
>>>If you have two orthogonal mechanisms, you can't have them share the
>>>same space in the Cval: header.
>
>>This sounds to me like you're confusing protocol mechanisms and
>>implementation mechanisms.  There are two orthogonal protocol mechanisms
>>here, but in any server, I would imagine only one implementation
>           ^^^^^^^^^^^^^                  ^^^^^^^^     
>>mechanism, which would _indeed_ share the same variant-id scheme. Hence,
>>I don't agree that the design principle you invoke applies to this case.
>
>I think the response I just sent to Roy explains why this reasoning is
>wrong: there will _not_ be one implementation mechanism, placed in the
>origin server, assigning variant-ids for responses of a particular
>resource.  Such mechanisms can also be present in all proxies in front
>of the origin server, because these will want to do preemptive
>negotiation on behalf of the origin server.
>
>If only the server assigned variant-ids, we could allow it to mix the
>data of the alternates-part and the variant-part into an opaque token
>in an undefined way.  But this is not the case.
>
>>Paul
>
>Koen.
>

Received on Tuesday, 16 April 1996 21:02:42 UTC