Ah, okay, I didn't realize that the mailcap spec and the mime-type spec
where so discontiguous (that was brilliant).
..
> > "well I'd really prefer mpeg over quicktime" so it'd set mpeg to 1.0 and
> > quicktime to 0.9, avi to 0.8, etc... this really could be quite a
> > powerful mechanism.
>
> Things brings up the interesting split: the q parameter is intended to
> express lossiness of presentation, not user preferences. Overloading it
> has some interesting implications (e.g. most people might prefer to use
> JPEG over GIF, but really it depends on how the image originated, since
> converting a GIF to a JPEG for transmission will make it worse, not better.)
According to
<URL:http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/HTTP1.0-ID_38.html#HEADING112>:
q
The quality factor chosen by the user agent (and configurable by the
user) that represents the desirability of that media type. In this
case, desirability is usually a measure of the clients ability to
faithfully represent the contents of that media type to the user.
The value is in the range [0,1], where the default value is 1.
How does the browser determine "the clients ability to faithfully represent
the contents of that media type to the user"? The best the client could do
would be 0 or 1. I might have a much better WAV player than MPEG player, but
I'd much prefer to get MPEG streams given that I know they pack higher
quality per byte. At some level, the user should have control over this.
In a general sense, overall "quality" shouldn't be mapped directly to
media types, I agree. The only thing that really maps to quality is
bandwidth in most cases - so an overall "Accept-Quality" header might be
needed (implemented as a slider replacing the throbbing N at the top of
my browser :) that the server uses to determine what to send.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/