W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: qvalue *

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 05 Aug 2008 00:23:13 +0200
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Cc: ietf-http-wg@w3.org
Message-Id: <1217888593.12221.85.camel@henriknordstrom.net>

On mån, 2008-08-04 at 21:09 +0200, Frank Ellermann wrote:
> assume
> that Koi8-R, BOCU-1, and UTF-8 are available:
> 
> All match *;q=0.7.  Toss a coin ?  Take always the last,
> i.e. for utf-8;q=0.7,*;q=0.7 take the * and toss a coin ?

Toss a coin.

All three have a qvalue of 0.7. It's not relevant that only one got the
qvalue from a specific declaration and the other from a wildcard. The
result should be the same if the header was listing all three explicitly
as in "utf-8;q=0.7, koi8-r;q=0.7; bocu-1;q=0.7".

> But it is strange when the <qvalue> of * isn't one of the
> smallest non-zero <qvalue>s, and I'm surprised that folks
> here refuse to see it.

I don't see it stange. It's a negative prose. "I really prefer anything
else than...". Useful as an optimization when you have problems with
something specific (a specific media type, a specific charset, language
or whatever..)

"bocu-1;q=0.5;Koi8-r,*;q=0.7"

* prefer Koi8-r.
* use bocu-1 only if no other is availabe


Or using Accept to illustrate the need for negative proses better:


"*/*; q=0.5, movie/mpeg;q=0, image/jpeg, text/*"

for an application that understands most content, have some preferences
on preferred content, but knows it can not decode mpeg content (patent
issues).

> But why ?  If everybody does something else the wildcard
> can be simply deprecated.  Or if desired fixed in some
> way, e.g., state that a wildcard <qvalue> greater or
> equal than the smallest non-zero <qvalue> elsewhere MUST
> be interpreted as *;q=0.001.  Or SHOULD.  Or something
> better than "dunno, who cares, toss a coin, get BOCU-1".

I'd say the specs is fine as they are on this. The rules is pretty clear
with no real room for confusion. You just have to keep in mind that the
specifications is written from a server perspective here starting out
with all available variants of the resource and finding the qvalue for
each of them and then filtering and sorting the result..

Implementers are however free to implement server driven negotiation
differently if they wish, with the specifications being no more than a
recommendation (no MUSTs in there.. only SHOULD or MAY). But the rules
specified is easy to implement, and not hard to understand for technical
people (even if Accept-Language concepts is far from intuitive to most
end-users, as already explained)

Regards
Henrik
Received on Monday, 4 August 2008 22:23:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT