Re: Variant-ID proposal

Roy T. Fielding:
>
>> - for cache refreshing: the contents of the Cval header (in this case
>>   "3212419" can be put in the If-Invalid header sent to
>>   the origin server.  A typical if-Invalid header sent, if 3 variants
>>   are caches, would be
>>      If-Invalid: "3212419", "453232", "756456"
>>   (Note that the origin server must ensure that all opaque validators
>>   for the three variants are indeed different, because there is no
>>   variant-id attached to disambiguate them.)
>
>No, it can't do that.  It needs to either include a variant-id of
>some kind or not use this mechanism at all.

Ugh.  We are going around in circles.

If you indeed insist that a variant-ID must be supplied if the
If-Invalid mechanism is to be used, then I insist that the variant-IDs
must have some structure.

I have thought some more about the minimal set of structural elements
for variant-IDs that would fit my requirements, and I concluded that
we won't get into huge problems later if variant-IDs are quoted
strings, not tokens. (The huge problems would be connected to in
proxies transparently negotiating on behalf of the origin server all
having to construct the same variant-ID)

That is, I would agree to either a scheme that allows

      If-Invalid: "3212419", "453232", "756456"

where the variant identifiers are encoded opaquely into the cache
validators, or to a scheme that allows

      If-Invalid: "3212419";".en.html", "453232";"de.html", 
                      "756456";"http://other.org/xx.gif"

with the variant-IDs being required, and being quoted strings.

Proxies will have to generate variant-IDs like
"http://other.org/xx.gif" using a cached Alternates header sometimes,
this is why I do not want variant-ids to be tokens.  If they were
tokens, we would need horrible string-to-token conversion rules in the
content negotiation spec.

>  That is, as I recall,
>why I started with variant-id being a MUST even for transparently
>negotiated URIs.

I started with a MUST that opaque validators are world-unique.  This
may explain why it takes us so long to reach a common ground.

>  There is absolutely no difference between having
>an origin server ensure that all opaque validators are unique across
>variants, and having an origin server always include a variant-id;

Agreed.

>in fact, the latter is much simpler.

The latter is simpler for plain 1.1 proxies, and simplifies cache
replacement somewhat because you do not have to use the
Content-Location header anymore.

On the other hand, the latter is more complex for 1.1 proxies that
want to support transparent negotiation on behalf of the origin
server.  Plus it gives more bytes over the wire.

But the latter also seems to be easier to define in the 1.1 draft.  So
I guess we should go for the latter (required variant-IDs which are
quoted strings).  I have no idea what state Jeff's text is in now with
respect to this, though.  I believe he can just delete the selecting
opaque validator sections and change token into quoted-string
somewhere.

>......Roy

Koen.

Received on Friday, 19 April 1996 12:20:48 UTC