RE: Variant-ID proposal

At 01:31 PM 4/16/96 -0700, Paul Leach wrote:
>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.

>>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>>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.

I agree with Paul, but only because that's the way I always understood
things.  I never understood what would result from the mixing of Vary: and
Alternates:, and I don't know that I or most other implementors ever will.

Origin servers generate opaque validator/variant Ids, and proxies save them
to ask the origin server later if they are acceptable.  It sounds so simple.
Until you try throwing Vary and Alternates together, then you start getting
all these weird algorithms where you preemptively negotiate down to a set
rather than an item, and do some opaque negotiation and cache validation
from that point, possibly attempting to not contact server by looking at
past request headers.  Or worse, you formulate some algorithm where the
proxy opaquely negotiates down to a set from past requests and stored
variant IDs(?!), and then transparently/preemptively negotiates from that
set.  Blech.  Yuck.  Foo.

At 10:35 PM 4/14/96 -0700, Roy T. Fielding wrote:
>the server.  A server that only supports Alternates will not be
>serving preemptive responses, and thus will not NEED any variant-ids.

I don't agree with this at all.  I agree that a server that only supports
Alternates will not NEED any variant-ids, but that server would certainly be
giving forth preemptive responses, i.e., the one with the highest Q value.
the 'functional' equivalent of EID: would be Location: (or Content-Location:
now I guess).

When did we diverge from the old URI/Content-Locaiton mode of thought to
dump everything into EID?  Is this because the editorial group decided to
leave Alternates out on this round, that we have to do this extra crud in
EID for transparent negotiation?


-----
the Programmer formerly known as Dan          
                                     http://www.spyglass.com/~ddubois/

Received on Tuesday, 16 April 1996 22:21:22 UTC