Re: #428 Accept-Language ordering for identical qvalues

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.

Yes.

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

....Roy

Received on Friday, 18 January 2013 12:13:19 UTC