- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Jan 2010 14:36:17 +1100
- To: Adam Barth <w3c@adambarth.com>
- Cc: Ian Hickson <ian@hixie.ch>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>
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 UTC