Re: #428 Accept-Language ordering for identical qvalues

[Julian Reschke <[e-mail]>]

On 2013-01-24 09:54, Amos Jeffries wrote:
> 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".

Not sure what you're trying to say here. If they send q-values there is 
no doubt about the semantics, right?

Also, counting unique UA strings generates a totally distorted statistic.

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

Recipients, I assume? How is that a problem? They choose one plausible 
interpretation where the spec doesn't define one.

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

Are these agents widely used? Can they be fixed? Did you report bugs 
against them?

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

That is true, but we can't remove q values at this point. Note we are 
discussing HTTP/1.1.

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

For that field value, yes.

Best regards, Julian