Re: #428 Accept-Language ordering for identical qvalues

[Amos Jeffries <[e-mail]>]

On 24/01/2013 9:26 p.m., Julian Reschke wrote:
> On 2013-01-24 02:17, Mark Nottingham wrote:
>> So, does anyone have an issue with making ordering significant when 
>> there's no qvalue for *all* headers that use qvalues?
>> ..
>
> I still do, and I'd prefer we go back to what the spec has been saying 
> for well over a decade.
>
> What *real* problem are we solving with this change that justifies 
> making current implementations broken?

Problem 1) a lot of agents (~57% by unique U-A string) are using 
q-values to specify ordering where the spec says "unordered".

Problem 2) a majority of the remaining agents appear to be treating the 
field-value as an ordered list of preferences even without q-values.

Problem 3)  ~1% of agents are incorectly implementing q-values. (see my 
earlier post responding to your request for examples).

Problem 4) q-values being mandatory when preference order is wanted adds 
complexity on both ends of the transaction, causing unnecessary CPU 
burden on the recipient. Misunderstandings and a host of needless 
mistakes by end-users and developers alike. (again see my earlier post 
for examples).

Problem 5) On the Accept-Language header the bandwidth required to 
transmit q-values inflates the header size by at least 55% (ISO code: 
2-5 bytes, q-v component: 6 bytes).

Amos