- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 24 Jan 2013 21:54:36 +1300
- To: ietf-http-wg@w3.org
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
Received on Thursday, 24 January 2013 08:55:08 UTC