Re: Variant IDs

Jeffrey Mogul:
>
>    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.)

[...]

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

Here it comes:

URI: {variant "home.l1.html" 1 {language "l1"}},
	{variant "home.l2.html" 1 {language "l2"}},
	{variant "home.l3.html" 1 {language "l3"}},
	{variant "home.l4.html" 1 {language "l4"}},
	{variant "home.l5.html" 1 {language "l5"}},
	{variant "home.l6.html" 1 {language "l6"}},
	{variant "home.l7.html" 1 {language "l7"}},
	{variant "home.l8.html" 1 {language "l8"}},
	{variant "home.l9.html" 1 {language "l9"}},
	{variant "home.l10.html" 1 {language "l10"}},
	{variant "home.l11.html" 1 {language "l11"}},
	{variant "home.l12.html" 1 {language "l12"}},
	{variant "home.l13.html" 1 {language "l13"}},
	{variant "home.l14.html" 1 {language "l14"}},
	{variant "home.l15.html" 1 {language "l15"}},
	{variant "home.l16.html" 1 {language "l16"}},
	{variant "home.l17.html" 1 {language "l17"}},
	{variant "home.l18.html" 1 {language "l18"}},
	{variant "home.l19.html" 1 {language "l19"}},
	{variant "home.l20.html" 1 {language "l20"}}

>One issue is "how many bytes does this encoding require"?

925 bytes.  Show me a homepage title image that is smaller.  I don't
really see a problem with 1K URI headers.  If you do see a problem:
don't you have the same problem with 1K Variant-Set request headers?

You _could_ send short but varying URI headers like

URI: {variant "home.l1.html" 1 {language "l1"}},
	{variant "home.l8.html" 1 {language "l8"}},
	{variant "home.l14.html" 1 {language "l14"}},
        {vary Accept-Language}
    
under my proposal, but I do not really see the point of doing so: it
only limits the ability of the user to request versions in other
languages.

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

My proposal does intend to support opaque validators: it intends to
take the complete caching mechanism for un-negotiated resources and
apply it in some way to negotiated resources.

I would have included a
 Variant-if-validator-valid: <variant-URI> <validator>
along with the
 Variant-if-modified-since:  <variant-URI> <HTTP-date>
header if we had had consensus about how Variant-if-validator-valid:
is supposed to look like.

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

I'm looking forward to a complete proposal.

[...]
>    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?",

The mechanism we are discussing offers an optimisation.  The question
to ask is: `how much extra traffic is generated if the optimisation
cannot be made'?  `frequently occurring' is (part of) the right
question.

Another part of the question is: what is the best possible
optimization if we do not have variant-set?  You can optimize the case
by generating cachable(*) redirection (302) responses that redirect to
cachable resources.  This is simple and gives optimal traffic savings,
though at the expense of using two RTTs in the case that the cache is
empty.

(*) Note that 302 responses are never cachable under the current 1.1
draft, but this can (will?) change.

>-Jeff

Koen.

Received on Wednesday, 7 February 1996 09:38:05 UTC