Re: Variant-ID proposal

    Sorry for the confusion.

Actually, Roy's message is the first compact and coherent description
of how content-negotiation works that I've seen so far.  It's missing
a few pieces, but I've been hoping that someone would write an
overview, rather than just defining the headers, because up to now
I've been trying to infer the nature of the animal while blindfolded,
and it's hard to judge this just from the shape of the head :-).

I'd suggest that someone (Roy, Koen, or the both of you) write up
such a description as soon as possible and send it to Jim for
use in the HTTP/1.1 draft.  Assuming, of course, that you now
agree with each other.

I should point out that when I actually went to write down a version
of the message that I sent earlier today, I didn't need to use the
terms "preemptive" or "reactive" anywhere.  I just wrote down what
a cache should do if it saw certain kinds of requests or responses.
So my draft for Jim actually was less half-baked than the one that
Roy critiqued.  I've revised it slightly to account for Roy's comments.

    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).

One question: how does a cache decide if 300 response with an
Alternates header can be returned in reply to a subsequent
request (a more precise way of saying "is cachable")?  Is this

    1. Always
    
    2. Only if the new request looks like [fill in the blank]

    3. Never

Roy's message seems to imply either #1 or #2.  The "10.1  Accept"
section of draft-ietf-http-v11-spec-01.txt says
						[then] the only
   appropriate value for Accept is "*/*", or an empty value if the
   user desires reactive negotiation.
which may seems to imply #2, but it's not clear to me if this
is the current consensus.

Koen's message of 12 Apr 1996, however, says:
   To ensure compatibility with future experimental or standardized
   software, caching HTTP/1.1 clients must treat all Alternates
   headers in a response as synonymous to the following Vary header:

         Vary: {accept-headers}

which seems to imply #3.  However, Koen's message elsewhere discusses
Alternates headers attached to 200 (OK) responses, rather than
to 300 (Multiple choices) responses.

Anyway, someone has to resolve this before I can finish writing
the relevant section.

    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).

Right.  Then this second request looks exactly like a request on a
non-varying resource, and so the response can be treated the same
as it would be in the case of a non-varying resource ... right?
So in this case, I agree that you don't need a variant-ID.

    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.

I guess I'd be happier if someone could tell me what a Content-Location
looked like.  It might also be nice if someone could explain how an
origin server decides whether to use opaque negotiation or transparent
negotiation.  However, I think from the point of view of caching, I
don't need to know.

At least, unless a proxy is allowed to take a 300 response, and then
on its own select a specific variant on behalf of the requesting client,
and generate the second request.  But if this is allowed, I would
consider this as a separate function of the proxy, and not part of
its caching function (i.e., not my department).

    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.

This is stuff for Koen to write about.  I wrote my caching-related
stuff in terms of what a cache should do *when* the origin server sends
a variant-ID, not whether the origin server should do so.

    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.

I would rephrase that as: The variant-ID is used as part of the cache
key only if the Request-URI is not sufficient to determine a specific
entity.  (And then only for conditional requests and for replacing 
existing cache entries.)

-Jeff

Received on Wednesday, 17 April 1996 02:50:45 UTC