W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: #428 Accept-Language ordering for identical qvalues

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 24 Jan 2013 10:50:33 +0100
Message-ID: <510103E9.7060502@gmx.de>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: ietf-http-wg@w3.org
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
Received on Thursday, 24 January 2013 09:51:11 UTC

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