W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Problem with q values in Accept-Language

From: Brian Smith <brian@briansmith.org>
Date: Tue, 6 May 2008 19:51:37 -0700
Message-ID: <E2585DD5915D42E2841CE04CDD5674D5@T60>
To: "Mark Davis" <mark.davis@icu-project.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>

Mark Davis wrote:
> The specs do not distinguish between at least two different possible
> reasonable interpretations of what the q values of c, e, and g are:
>   1. c;q=1.0, e;q=1.0, g;q=1   // always 1
>   2. c;q=0.7, e;q=0.5, g;q=0.9 // always same as previous

The specification states explicitly that the quality value defaults to 
"q=1". Only interpretation #1 is correct. The specification does not assign 
any significance to the ordering of the alternatives in the Accept headers, 
and there is no implicit relationship between the parameters of one choice 
and the parameters of another choice.

> 2. And even once that ambiguity is cleared up, nobody knows what the 
> meaning
> of the numbers really is. My native tongue is English, I can understand
> Swiss German and German, my French is rusty, and Italian basic. Which of
> these should I use?
>   1. en;q=1, gsw;q=0.9,  de;q=0.9,  fr;q=0.8,  it;q=0.7
>   2. en;q=1, gsw;q=0.5,  de;q=0.4,  fr;q=0.3,  it;q=0.2
>   3. en;q=1, gsw;q=0.99, de;q=0.95, fr;q=0.03, it;q=0.02
> All are descending order, but depending on what algorithm the consumer of
> the tags uses, they could have far different results. Without being able 
> to
> have any consistent expectations for what the q numbers mean, producers of
> tags don't know what settings to provide or what difference it will make,
> and consumers of tags don't know what the producers meant, in order to 
> meet
> any expectations.

This is server-side content-negotiation, not client-side 
content-negotiation. The client will not be able to predict what the server 
will respond with. The requirements for the Vary header require the server 
to respond consistently with its previous responses for that resource 
(except for Vary: *), but there is no consistency required between servers 
or resources.

If the client application needs precise control over variant selection, then 
it should use some kind of client-side content negotiation, where the server 
lists relevant choices and the client picks a specific one.

Received on Wednesday, 7 May 2008 02:52:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC