Re: #428 Accept-Language ordering for identical qvalues

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 <julian.reschke@gmx.de> 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   http://www.mnot.net/

Received on Thursday, 24 January 2013 23:38:03 UTC