- From: Frank Ellermann <nobody@xyzzy.claranet.de>
- Date: Tue, 5 Aug 2008 00:50:17 +0200
- To: ietf-http-wg@w3.org
Henrik Nordstrom wrote: >> 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. Okay, that answers that: The utf-8;q=0.7 is redundant, but actually harmless. Maybe Julian's or my UAs shouldn't do it, as it could cause harm for discussions on this list ;-) [* qvalue not the smallest non-zero qvalue] > 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 [...] > "bocu-1;q=0.5;Koi8-r,*;q=0.7" > * prefer Koi8-r. > * use bocu-1 only if no other is available Oh, you found a plausible meaning for non-zero and smaller than *. That is good, so far I assumed that this _must_ be erroneous. > 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). Yes, I got this idea for zero, but not for non-zero. Maybe a better example is application/pdf: ..., text/*, */*;q=0.2, application/pdf;q=0.1 "If all else fails I'm willing to try my luck with PDF before giving up". > 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.. Well, it did confuse me. Now that you've shown me a simple example it's perfectly clear. But maybe it was not only me, others apparently also didn't exactly know what the purpose of a wildcard with a "medium" <qvalue> is. So that IMO needs a plausible example, explaining what you wrote above (not the mpeg;q=0 case, that's IMO too simple). Frank
Received on Monday, 4 August 2008 22:49:58 UTC