Re: Variant IDs

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

The operating system on my workstation has "locale" support for
at least 20 different languages (although several of these are
variants of de/en/fr/nl).  And this does not include any languages
with non-Latin encodings (Japanese, Chinese, Russian, Arabic, etc.)
but I am sure we offer support for these as well; I just haven't
installed it.

So suppose we wanted to provide our corporate home page in each
of (say) 30 different natural languages, since we do business in
at least that many.  Can you give us an example of the most compact
possible encoding of that variant set in your proposed URI header?
One issue is "how many bytes does this encoding require"?
    
    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.

Since we have reached at least a tentative consensus that the
protocol should support both opaque validators and Last-Modified:
validators, your proposal really ought to support opaque validators
as well.  I believe that (subject to some revision, since the
variant-id proposal was designed during a committee discussion
and is not entirely mature) we will need to find some combination
of
	variant-if-modified-since:
	variant-if-valid:
	variant-set:

that is sufficient to cover the necessary set of circumstances.
If we can find a single header that solves this, that would
be nice, but I'm not sure that it makes sense to design a
bulky encoding simply to avoid defining a new header name.
    
    Can you think of a frequently occurring case?

I'm pretty sure that someone at the caching meeting came up
with a compelling case, but I can't remember what it was.  Can
anyone remember?

Note that "frequently occurring" is not necessarily the right
question.  The question is "does this case occur in situations
where the alternative would be infeasible to implement?", and
if so, are these situations likely to be important to a
significant number of people?

I have a seatbelt in my car not because I frequently run into
other cars, but because if I ever do run into another car,
the alternative solution (dying) is infeasible.

-Jeff

Received on Wednesday, 7 February 1996 01:28:27 UTC