Re: Variant-ID proposal

> Since Jim wants me to nail down as much as possible of the caching
> stuff TODAY, and I need to have something concrete about variant-IDs
> to do this, I'm going follow the plan described in this message.
> This is not subject to debate today.  Once Jim issues his draft,
> then anyone who wants to can reopen the discussion.

Well, I don't care if it's subject to debate or not, you shouldn't 
be adding non-baked ideas to the spec.  It's okay to add what you
were planning to do this morning, but this new stuff is off-track.

> Roy (or perhaps someone before him) defined two basic kinds of
> negotiation:
> 	Preemptive negotiation, in which the client expresses
> 	preferences in a request on a resource, and the origin server
> 	chooses the most appropriate entity and returns that
> 
> 	Reactive negotiation, which is signalled somehow by the
> 	client [draft-ietf-http-v11-spec-01.txt says by an empty
> 	Accept header, but this may have changed].  The origin server
> 	in this case returns a description of the choices, and
> 	then the client chooses one and makes a specific request
> 	for that entity.

Its not that simple, because I also defined a mechanism for the server
to do both (i.e., respond with a preemptively negotiated entity, but
include all the information needed for reactive negotiation if the user
agent doesn't like what it got).

> Now we introduce caching.  Because caches store copies of
> specific entity instances, not of resources, a cache needs
> to use a specific entity identifier as a cache key; a URI
> for a varying resource is not a sufficient cache key.  We
> could construct an entity (variant) identifier in one of several
> ways:
> 	(1) a URI that is bound to a specific entity (variant).
> 	(2) a URI bound to the varying resource, plus a set of
> 	selection criteria that is guaranteed to completely
> 	determine the variant.
> 	(3) a URI bound to the varying resource, plus an
> 	opaque variant ID.

This is the non-baked part.  In truly reactive negotiation, the server
always responds with a cachable 300 response which includes the 
Alternates header (in addition to an entity describing the same thing
in, essentially, HTML menu form).  The client must then make a second
request (using a different Request-URI) for the variant it wants.
In this case, the cache key is ALWAYS the Request-URI because none
of the entities vary (except over time).

In preemptive negotiation, the server responds with an entity based on
either opaque negotiation (signalled by Vary) or transparent negotiation
(signalled by Alternates and Content-Location). [THIS IS THE PART WHERE
I GOT OFF-TRACK AS WELL].  In the former case, all subsequent conditional
requests on that resource are made on the original Request-URI and must
include a variant-id.  In the latter (transparent) case, all subsequent
conditional requests on that resource are made using the Content-Location
and NOT the original Request-URI, and thus there is no need for a
variant-id.

So, I guess Koen was right in the first place -- the only time when
variant-id MUST be included with the EID is when Vary is being used
as the negotiation mechanism.  Likewise, Content-Location MUST be
included with any response containing Alternates.

The variant-id is only used as a cache key in the sense that it enables
the cache to differentiate between entities varying by negotiation and
entities varying over time.  It doesn't get used at all for transparent
negotiation because the later requests all use specific Content-Location
instead.

Sorry for the confusion.

.....Roy

Received on Wednesday, 17 April 1996 01:52:08 UTC