Re: #428 Accept-Language ordering for identical qvalues

"Roy T. Fielding" <> Fri, 18 January 2013 12:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55CCE21F8703 for <>; Fri, 18 Jan 2013 04:14:40 -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 bW7xWoEHu1wV for <>; Fri, 18 Jan 2013 04:14:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 62FB321F8477 for <>; Fri, 18 Jan 2013 04:14:39 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1TwAp0-0007sb-Tn for; Fri, 18 Jan 2013 12:13:22 +0000
Resent-Date: Fri, 18 Jan 2013 12:13:22 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1TwAox-0007rU-C3 for; Fri, 18 Jan 2013 12:13:19 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1TwAot-00069W-HZ for; Fri, 18 Jan 2013 12:13:19 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 127E320202C; Fri, 18 Jan 2013 04:12:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=fS3zi5pBryqXcjZyurGYyR9Dmvk=; b=OINK2bG8ua2DjlPLYTuwLaNERSQe tC/1Qi3zKc+FRj1NiAci23gbbc+6tdrmeHsPAH8k9tjG5xnKfOIYVJk6nJxaSd+E niyXk0+x8XPetr+C85XABZ9IQeNcBSNMlXCPXWCtrDHliyT94RcXtfYjyNJlITIh x2mZxNmGy+4ASpE=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id D3FD9202018; Fri, 18 Jan 2013 04:12:53 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Fri, 18 Jan 2013 04:11:21 -0800
Cc: Amos Jeffries <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Julian Reschke <>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.424, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1TwAot-00069W-HZ 0edddba787dba5545ba5f82d28f141e2
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16000
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Jan 18, 2013, at 1:07 AM, 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?

Yes.  It would also be conformant to send Mäori text.

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


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

Ignoring the preferences sent in Accept-Language is conforming behavior.

Conformance is not a relevant issue here.  What matters is what the
user actually prefers. It is my opinion that when a user sets an
Accept-Language header to

  Accept-Language: en, de

what they are actually saying is that they accept both languages
but would prefer en if the de representation is no better.

The reason I believe this is because user agents that allow a
user to send such a header field have explicitly instructed the
user that the field is ordered (or based the value on some other
ordered list for the host UI, as is the case for some cell phones).
Servers that wish to implement content negotiation according to the
user's desires (not just the IETF's desires) will, in fact, treat
the order as significant; failing to do so results in bug reports.

This is a change to the specified semantics for Accept-Language,
but that is well within the scope of what we are chartered to do.