Re: Variant-ID proposal

Roy T. Fielding:
>[Paul Leach:]
>> 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.

Roy, I think I'm beginning to suspect why our mental models are out of
sync.  One problem seems to be that we have different ideas about what
the Alternates header does:

  Roy: lets user agents know all the different variants

  Koen: lets user agents know all the different variants, and tells to
        proxy caches how they can engage in preemptive content
        negotiation on behalf of the origin server.

So if you say `alternates is orthogonal to vary', you mean that even
if you do opaque negotiation with vary, you may want to tell the user
agent which other things you have.  I agree that this is a good thing
to want, by the way, but I would call a header that gives such
information `Variants', not Alternates.  The Alternates I put in the
1.1 spec is not designed as just a Variants header: unlike a Variants
header, it has implications for caching, because it contains
preemptive negotiation instructions for caches.  Note that we do not
need to add a `Variants' header to 1.1: as it has no implications for
caching, it can be safely defined later.

If I say `alternates is orthogonal to vary', I mean that a resource
http://bla.com/x may use transparent negotiation to return the (URI of
an) alternate resource http://bla.com/x.html.select which uses opaque
negotiation (the vary header), for example to select the right kind of
html based on the User-Agent header.  In my mental model, opaque and
transparent negotiation are orthogonal because they can safely be
layered on top of each other.

[Paul:]
>> I don't know if I buy the implication that Alternates is only for
>> reactive content negotiation.

I do certainly not buy this implication, as I specifically designed
Alternates in draft-holtman to allow preemptive negotiation by
proxies.

>> Once a cache has the list of alternates
>> for a resource, it should be able to use it in preemptive negotations,
>> right?

Right! This is exactly what Alternates, as it appears in draft-holtman,
was designed to allow caches to do.

[Roy:]
>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).

Yes. I want structure in the variant-id part of the Cval header
precisely because caches have to produce variant-IDs themselves
sometimes.  I wrote in my original proposal:

   [##I want this extra structure in variant-ids because, in order for
   transparent negotiation to be as efficient as it can be, _proxys_
   will sometimes have to assemble variant-IDs from various components
   on behalf of the origin server.  I can explain why proxies would
   need to do this with examples, but will not do so here.##]

If the origin server were the only party which produces variant-ids,
we would of course not need any structure in them.  But because
proxies have to assemble them from various components, and because all
proxies will have to do this in the same way, we need structure.

The examples I talked about above, by the way, have to do with a proxy
making a preemptive response, on behalf of the origin server resource
http://bla.com/x, on the basis of an Alternates header gotten from
this resource and a preemptive, varying (opaquely negotiated) response
from http://bla.com/x.html.select.

>  Such a thing would be fine if the
>user agent always went through the same caches, but that is not always
>the case.

My scheme will allow all caches to assign variant-ids in the same way,
which is your (b) below.

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

This gives huge logistics problems, as I have said before.

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

This is my proposed solution, and this is why I need structure in the
variant-id field.

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

This means round-trip penalties, which is bad.  It also means that
users of browsers incapable of automatic reactive negotiation will
need to handle 300 responses by hand much more often, which is even
worse.

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

Huh?  This was my earlier solution I thought you rejected.  I thought
you always wanted there to be a variant-id.

>    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 (:)

I prefer either (b) or (d).  They _will_ be semantically transparent
because I specifically designed the Alternates header handling
requirements for the 1.1 draft text to allow them to be.

> ...Roy T. Fielding

Koen.

Received on Tuesday, 16 April 1996 07:49:28 UTC