Re: Variant-ID proposal

> I agree that Alternates _should_ be completely orthogonal to Vary. For
> example, I would add "User-Agent" and "Cookie" as one of the
> discriminators in the Alternates header if needed to make them
> orthogonal.

Ummm, no, I wouldn't do that simply because there are variant possibilities
that Alternates is incapable of describing without regular expressions
(which would be too much).  The two mechanisms are still orthogonal in
that they should not affect one another, but that doesn't mean they are
equally applicable in all negotiation cases.

> I don't know if I buy the implication that Alternates is only for
> reactive content negotiation. Once a cache has the list of alternates
> for a resource, it should be able to use it in preemptive negotations,
> right?

That is a harder problem because it puts the cache in the position of
having to assign variant-ids if there are none already (i.e., if it
received its entities after reactive negotiation, but wanted to deliver
them via preemptive negotiation).  Such a thing would be fine if the
user agent always went through the same caches, but that is not always
the case.  We can solve that by one of

    a) requiring all variants to be given variant-ids which do not
       change based on the Request-URI used to access them.

    b) requiring a specific syntax be used for caches to derive a
       variant-id from the difference between the general and specific URIs.

    c) never allow a cache to preemptively respond with entities received
       via a prior, reactive negotiation; it can generate its own 300 or
       302 response instead and answer the client's second request.

    d) have recipients treat any entity received with a Content-Location
       other than the Request-URI, but without a variant-id, as if it were
       the response to a reactive request that was never sent.

    e) include Content-Location in the If-EID/Unless-EID if the original
       EID has a special marker for it, as in

          Content-Location: http://my/alternates/user
          EID: "kljhfhuwh";*

          If-EID: "kljhfhuwh";"http://my/alternates/user"

       which is really just a sloppy combination of (a) and (b).


Oddly enough, I think I prefer (c) because it is the only one that
remains semantically transparent (:) and is more in spirit with the idea
that it is better for the user agent to pick what is best from the
available choices than it is for the server to attempt to decide what
is best from the request profile.  

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 16 April 1996 05:00:03 UTC