W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: Content Sniffing impact on HTTPbis - #155

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Jan 2010 14:36:17 +1100
Cc: Ian Hickson <ian@hixie.ch>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <984072CF-2640-45F6-B531-EF2477EFC412@mnot.net>
To: Adam Barth <w3c@adambarth.com>

On 27/01/2010, at 7:22 AM, Adam Barth wrote:

> On Fri, Jun 12, 2009 at 10:03 PM, Ian Hickson <ian@hixie.ch> wrote:
>> Adam: assuming you have a conformance section which invokes RFC2119 and
>> includes a sentence such as "Requirements phrased in the imperative as
>> part of algorithms (such as "strip any leading space characters" or
>> "return false and abort these steps") are to be interpreted with the
>> meaning of the key word ("must", "should", "may", etc) used in introducing
>> the algorithm.", and assuming you keep the "must"s in the invokations of
>> the algorithms, I agree that it makes sense to remove the "must"s from the
>> steps.
> 
> Done (using the text you gave me for the cookie spec more recently).

Adam, it might be worth having a quiet word with a few people at the IETF about whether or not this style of specification is going to cause problems down the road. Lisa and Alexey would be a good start, and Julian would surely have an informed opinion.

> 
>>> Separately, as an editorial comment, as listed directly above, I'd like
>>> to see a big s/resource/resource representation/g (or just
>>> s/resource/representation/g as the resource is what is identified by the
>>> URI, not the bag-o-bits returned in an HTTP response.  I have some other
>>> editorial comments too, but those will have to wait until I have time to
>>> write them down.
>> 
>> A resource is a bag of bits. I would object to this change.
> 
> I've removed all mention of resource.  The algorithm now operates
> directly on the octets, however they are obtained.


Very diplomatic :)

Cheers,


--
Mark Nottingham     http://www.mnot.net/
Received on Thursday, 28 January 2010 03:36:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT