Subject: Problem with q values in Accept-Language

From: "Mark Davis" <[email-masked]>
Date: Tue, 6 May 2008 19:31:43 -0700

Unfortunately, the spec is ill-defined regarding the q values, as used in
Accept-Language (http://tools.ietf.org/html/rfc2616#section-14.4).

1. Take the following example, where a..g stand for languages:

a, b;q=0.7, c, d;q=0.5, e, f;q=0.9, g

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

Our guess is that the user meant #2, but it is only a guess.

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.

-- 
Mark

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 6 May 2008 19:51:37 -0700

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

> and consumers of tags don't know what the producers meant, in order to 

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.

Regards,
Brian

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 6 May 2008 20:22:19 -0700

My mistake on the 1, sorry.

While the spec doesn't attach any meaning to the ordering, real-life
programs do. Accept-Language values "en fr" and "fr en" give very different
results. Eg for Apache " When you specify a language preference in your Web
browser, it uses the designated language in a HTTP header it sends to the
Web server whenever a request is made; this header is Accept_Language and
will typically be the list of language keywords the user specifies (in
descending order of preference), so our Web browser will be
sendingAccept-Language: fr de en"

Saying that the weights and/or ordering is entirely up to the server doesn't
give any guidance for clients or servers. Is the expectation that my
browser, for example, would set up some kind of negotiation with every
different server it hits in order to determine what the meanings of the
weights ought to be? Or that each server should simply guess at what the
values from the client mean? Or is the only thing the server can surmise, in
the absence of negotiation, that smaller weights (no matter what the
magnitude) mean lesser preference (eg that "en, fr;q=0.99999" is equivalent
to "en, fr;q=0.00001"?

Mark

> 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.
>
> Regards,
> Brian
>

-- 
Mark

---

From: Roberto Javier Godoy <[email-masked]>
Date: Wed, 7 May 2008 00:29:31 -0300

Hi Mark,
 
Mark Davis wrote: 
 
> Unfortunately, the spec is ill-defined regarding the q values, as > used in Accept-Language (http://tools.ietf.org/html/rfc2616#section-14.4). >>1. Take the following example, where a..g stand for languages:>> a, b;q=0.7, c, d;q=0.5, e, f;q=0.9, g>>The specs do not distinguish between at least two different >possible reasonable interpretations of what the q values of c, e, >and g are:>
> c;q=1.0, e;q=1.0, g;q=1   // always 1
> c;q=0.7, e;q=0.5, g;q=0.9 // always same as previous
 
IMHO the spec is clear enough [[
  The quality value defaults to "q=1".
]] http://www3.tools.ietf.org/html/draft-ietf-httpbis-p3-payload-02#section-6.4
 
>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?>
> en;q=1, gsw;q=0.9,  de;q=0.9,  fr;q=0.8,  it;q=0.7
> en;q=1, gsw;q=0.5,  de;q=0.4,  fr;q=0.3,  it;q=0.2
> 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.
 
I think your use case is best described by the third option, because q values "represent a relative degradation in desired quality", and you said you strongly prefer English, Swiss German or German while Italian and Frech are best-than-nothing choices.
 
Of course, measuring the exact float number (aka "q value")associated with each variant (for instance, whether the "quality" of the Italian version of a resource is 0.02, 0.8 or 0.001 w.r.t. the English version) should be out of scope for the HTTP specification.
 
Best Regards
 
Javier Godoy
rjgodoy at fich.unl.edu.ar
_________________________________________________________________
¿Aburrido? Ingresá ya y divertite como nunca en MSN Juegos.
http://juegos.ar.msn.com/

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 6 May 2008 21:31:26 -0700

Mark Davis wrote:
> Or is the only thing the server can surmise, in
> magnitude) mean lesser preference

Yes. The specification doesn't assign any significance to the magnitude of 
the difference between stated preferences; servers can (and do) interpret 
them differently. Further, the server is not obligated in any way to pay 
attention to the client's stated language preference; the server can do 
exactly the opposite of what the client requests and still be compliant.

- Brian