W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: A broken browser

From: Martin J. Duerst <mduerst@ifi.unizh.ch>
Date: Wed, 8 Jan 1997 19:27:10 +0100 (MET)
To: "M. Hedlund" <hedlund@best.com>
Cc: "Gregory J. Woodhouse" <gjw@wnetc.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970108190705.245t-100000@enoshima>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2264
On Wed, 1 Jan 1997, M. Hedlund wrote:

> However, I disagree that the spec simply doesn't spell this out but does
> imply it (as you seem to suggest).  Section 3.9 says that q values merely
> indicate relative preference, rather than absolute quality.  Under that
> definition, q=0 would mean, "This is the least desirable media type of the
> media types listed in the Accept header."

Relativity is relative. Relative to what? Obviously relative to
to the other q's in the same Accept header line. And relative
in what sense? Is q=0.5 half as desirable as q=1.0? Or is q=0.5
just less desirable than q=1.0, without concerning its degree?
In both cases, we are still relative. Other scales would also
be relative, such as a logarithmic scale (a little difficult
with a range of 0.0 to 1.0, I admit).

If we go for multiplicity, then things become a little clearer.
All the values 0.0 < ... <=1.0 are still relative, but 0.0
looses its relativity. 0.0 is absolute. Whatever you combine
it with, it will stay 0.0. If you send a preference with
gif=1.0, png=0.0001, and jpeg=0.0, and the server has all
three, with different q factors, there is a (very slight)
chance that you get back the png version. But however
high the quality of the jpeg image is compared to the
gif and the png, you have no chance whatsoever to get
the jpeg back.

If the general consensus is therefore indeed to go towards
multiplicity, the consistent solution is to assume (or spell
out) that q=0.0 means NOT desired, and not just LEAST desired.

Regards,	Martin.
Received on Wednesday, 8 January 1997 10:31:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC