Re: Variant IDs

Jeffrey Mogul:
[...]
>Consider a single resource with multiple variants (e.g., a document that
>has been translated into several dozen languages).  Consider a proxy which
>already has several variants in its cache (for concreteness, let's
>say it has three such variants: English, French, and German).  Let's
>also assume that the server sent "Vary: Accept-Language" because it
>didn't want to encode all of the possible variants in a URI: header.

I find this a strange assumption: I can't think of any frequently
occurring cases where the server does not want to encode the available
variants in an URI header.  (See my `New content negotiation sections'
text at http://weeble.lut.ac.uk/lists/http-caching/0241.html for a
definition, with examples, of the kind of URI header I mean.)

In my opinion, it makes little sense to include a
variant-ID/variant-set mechanism in HTTP unless we can find some
frequently occurring case where the server does not want to use the
URI header.  We would just be duplicating the
`variant-if-modified-since' mechanism of URI content negotiation with
no good reason.

Can you think of a frequently occurring case?

[....]
>The server goes through its normal content-negotiation algorithm
>to decide which variant to return 

Ugh.  Please do not use the term `normal content-negotiation
algorithm' when referring to an algorithm that selects a variant
response.  We will get very nasty terminology clashes.

May I suggest the terms
 `variant computation' and `variant response'
as counterparts to the terms
 `content negotiation' and `variant resource'
in the `New content negotiation sections' text at
http://weeble.lut.ac.uk/lists/http-caching/0241.html ?
(Hm, maybe the description of content negotiation with URI headers
sould not use `variant' but another term.  `Version' doesn't work.
Alternative?  Representation?)

>-Jeff

Koen.

Received on Tuesday, 6 February 1996 14:04:31 UTC