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

Re: Issues-list item "QZERO"

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 23 Apr 1997 19:19:14 +0200 (MET DST)
Message-Id: <199704231719.TAA19741@wsooti08.win.tue.nl>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: koen@win.tue.nl, jg@w3.org, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3142
Roy T. Fielding:
>>From the Memphis minutes:
>> -- Koen Holtman
>>    will draft a clarification that a qvalue of 0.0 means "Don't send
>>    me this."
>>The clarification (taken from the slide I showed in the Memphis
>>evening session) is one new sentence in section 3.9 of the 1.1 spec.
>>The new sentence is between ** **.
>> 3.9 Quality Values
>>   HTTP content negotiation (section 12) uses short "floating point"
>>   numbers to indicate the relative importance ("weight") of various
>>   negotiable parameters. A weight is normalized to a real number in the
>>   range 0 through 1, where 0 is the minimum and 1 the maximum value.
>>   **If a parameter has a quality value of 0, then content with this
>>   parameter is `not acceptable' for the client.**
>>   HTTP/1.1 applications MUST NOT generate more than three digits after
>>   the decimal point. User configuration of these values SHOULD also be
>>   limited in this fashion.
>That change does not belong in that section -- it belongs in the sections
>on the Accept* header fields.  Servers send qvalues too.

The interpretation of q=0 is a general thing, so it belongs in the
general section as far as I am concerned.  And servers do not send
qvalues in HTTP/1.1.  They do send them under TCN, but such a qs=0 will
still mean that the content is not acceptable for the client.

I'm willing to change my proposal from 

 is `not acceptable' for the client


 will be `not acceptable' for the client

but I think it would be a mistake to move this to the Accept* sections.


Received on Wednesday, 23 April 1997 10:21:30 UTC

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