Re: #428 Accept-Language ordering for identical qvalues

Mark Nottingham <> Thu, 24 January 2013 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E927321F84D8 for <>; Thu, 24 Jan 2013 15:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.831
X-Spam-Status: No, score=-9.831 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2yFxmLcIUXav for <>; Thu, 24 Jan 2013 15:39:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 140F721F84D7 for <>; Thu, 24 Jan 2013 15:39:24 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TyWMz-0005FV-4K for; Thu, 24 Jan 2013 23:38:09 +0000
Resent-Date: Thu, 24 Jan 2013 23:38:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TyWMt-0005Eq-Ti for; Thu, 24 Jan 2013 23:38:03 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1TyWMr-0003TS-A6 for; Thu, 24 Jan 2013 23:38:03 +0000
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7D84022E1FA; Thu, 24 Jan 2013 18:37:38 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 25 Jan 2013 10:37:34 +1100
Cc: "Roy T. Fielding" <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Julian Reschke <>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.291, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1TyWMr-0003TS-A6 450f9a5a6f64764d8d12ea5d51d31c0b
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16199
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Removing the text does seem like the most expedient path forward. 

That said, I don't find it particularly satisfying; our job is to improve interop, and when there are latent semantics that aren't documented, we have to consider whether we're doing it well.

I propose:

Note that some recipients treat language tags that have the same quality values (including when they are both missing) to be listed in descending order of priority. However, this behaviour cannot be relied upon, and if their relative priority is important, it ought to be communicated by using different quality values.

... because I think it best captures where we're at.

Roy and Julian? And, especially, anyone else?

On 25/01/2013, at 1:50 AM, Julian Reschke <> wrote:

> On 2013-01-24 06:40, Roy T. Fielding wrote:
>> On Jan 23, 2013, at 5:17 PM, Mark Nottingham wrote:
>>> So, does anyone have an issue with making ordering significant when there's no qvalue for *all* headers that use qvalues?
>>> Roy, I'm interpreting your answer as "we don't do anything with this information today," but as per below I don't think this stops us from defining it that way.
>> Sorry, I wasn't clear.  There is no code out there today that would
>> correspond to such a change.  I don't like making changes to HTTP
>> just for the sake of imaginary consistency of definitions.
>> Making them for the sake of consistency with implementations is fine.
>> If it is a choice, I'd rather remove the line from Accept-Language
>> than introduce new (unproven) things to Accept.
>> ...
> +1
> In the meantime I had another look at RFC 4647:
>> 2.3. The Language Priority List
>>   A user's language preferences will often need to specify more than
>>   one language range, and thus users often need to specify a
>>   prioritized list of language ranges in order to best reflect their
>>   language preferences.  This is especially true for speakers of
>>   minority languages.  A speaker of Breton in France, for example, can
>>   specify "br" followed by "fr", meaning that if Breton is available,
>>   it is preferred, but otherwise French is the best alternative.  It
>>   can get more complex: a different user might want to fall back from
>>   Skolt Sami to Northern Sami to Finnish.
>>   A "language priority list" is a prioritized or weighted list of
>>   language ranges.  One well-known example of such a list is the
>>   "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section
>>   14.4) and RFC 3282 [RFC3282].
>>   The various matching operations described in this document include
>>   considerations for using a language priority list.  This document
>>   does not define the syntax for a language priority list; defining
>>   such a syntax is the responsibility of the protocol, application, or
>>   specification that uses it.  When given as examples in this document,
>>   language priority lists will be shown as a quoted sequence of ranges
>>   separated by commas, like this: "en, fr, zh-Hant" (which is read
>>   "English before French before Chinese as written in the Traditional
>>   script").
>>   A simple list of ranges is considered to be in descending order of
>>   priority.  Other language priority lists provide "quality weights"
>>   for the language ranges in order to specify the relative priority of
>>   the user's language preferences.  An example of this is the use of
>>   "q" values in the syntax of the "Accept-Language" header (defined in
>>   [RFC2616], Section 14.4, and [RFC3282]).
> So in fact what the spec used to say is indeed consistent with 4647; there is no consistency problem that needs to be solved.
> Best regards, Julian

Mark Nottingham