(no subject)

Henrik Frystyk Nielsen ([email protected])
Sat, 6 May 1995 23:03:06 +0500

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

Having the client setting the quality factors to either '0' or '1' depending on
what it can find, and then have the users adjusting according to their personal
preferences is in my opinion a perfectly good way of doing it. In the gray zone
between '0' and '1' the quality factor acts pretty much like the accept language
header: The user has to take part in assigning values.

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

The HTTP specification is not very clear when it comes to content-negotiation.
There are several reasons for this: First of all because most URLs maps directly
to a specific file type which leaves little room for content-negotiation (because
the document only exists in one format); Second because nobody has been able to
come up with a good set of parameters for network performance that can be used
to select the desired media type (BTW: this is not only a problem for HTTP).
Obviously, size is a reasonable parameter, but I don't think the only one required
in a flexible algorithm.

So maybe we simply have no choice but to let the quality factor be a mapping of user
preferences!

-- cheers --

Henrik Frystyk [email protected]
World-Wide Web Consortium, Tel + 1 617 258 8143
MIT/LCS, NE43-356 Fax + 1 617 258 8682
77 Massachusetts Avenue
Cambridge MA 02154, USA