Re: #428 Accept-Language ordering for identical qvalues

Amos Jeffries <> Fri, 18 January 2013 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 800A221F8935 for <>; Fri, 18 Jan 2013 03:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zHasR1Bsplkf for <>; Fri, 18 Jan 2013 03:00:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E162521F8936 for <>; Fri, 18 Jan 2013 03:00:51 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Tw9gF-0001fe-Bq for; Fri, 18 Jan 2013 11:00:15 +0000
Resent-Date: Fri, 18 Jan 2013 11:00:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Tw9g8-000159-63 for; Fri, 18 Jan 2013 11:00:08 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1Tw9g3-0003OR-Jg for; Fri, 18 Jan 2013 11:00:08 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id 9A650E712F; Fri, 18 Jan 2013 23:59:40 +1300 (NZDT)
Message-ID: <>
Date: Fri, 18 Jan 2013 23:59:37 +1300
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Julian Reschke <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.2
X-W3C-Hub-Spam-Report: AWL=-1.150, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Tw9g3-0003OR-Jg 296e5e921591457a6a047c15331e672d
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/15996
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 18/01/2013 10:07 p.m., Julian Reschke wrote:
> On 2013-01-18 09:46, Amos Jeffries wrote:
>> ...
>> ...
>> I'm with Roy on this one. It's not adding any new requirement about
>> interpretation, simply stating that the list is ordered, as is actually
>> the case from most senders.
>> There is no requirement added/removed about server interpretation so
>> those servers implementing random selection out of the ordered set are
>> still compliant. Those servers implementing ordered interpretation are
> > ...
> They are? How so?
> If the client sends
>     Accept-Language: en, de
> and the server returns German text, although English would have been 
> available, is it still compliant?

Where is the text saying the server MUST or even SHOULD return the 
clients first preference?
I could not find any in RFC 2068, 2616 or the current Draft.

The server gets to decide what it returns, the text is lacking in 
normative requirements, so we are quibbling over 
compliance/non-compliance with textual guidance on best interoperable 

>> now compliant - where before with the list defined as un-ordered they
>> would be non-compliant due to mis-interpreting an un-ordered list as
>> ordered.
> That doesn't make sense, sorry.
> If the list ordering is defined to be irrelevant it's totally ok to 
> pick the first match.

If the ordering is defined as relevant to the clients preference, why is 
it non-compliant to pick one of the *available* ones randomly? a bit 
daft, but as you say that used to be prescribed so tose who opted to 
follow the old text see no harm in it. They have the option of 
optimizing a bit or ignoring the new text.

>> ...
>>> Right now they interoperate as specified by the spec. If we change the
>>> spec, they do not anymore (or only some of the time).
>> The new spec does not forbid random selection. Merely states that the
>> client *wants* it to be interpreted non-randomly. Obeying that client
>> preference is still optional.
>> ...
> Again, that doesn't make any sense at all.
> If we say that the list is ordered by preference (in absence of 
> qvalues), this implies that a recipient should pick the *first* 
> matching language. If it does not, it's not interpreting the message 
> as defined.

Sure it is both unfriendly to the client and requires sub-optimal code 
to actually perform. But there is still no requirement to return the 
*first* matching language after the change. Just the implication that 
more optimal code may be used.