- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Thu, 28 Jan 2010 15:04:26 +0900
- To: Mark Nottingham <mnot@mnot.net>
- CC: Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 2010/01/28 12:36, Mark Nottingham wrote:
>
> 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.
Even without the explicit sentence ("Requirements phrased in the
imperative..."), something like the above definitely has been done in
the past. The example I'm most familiar with (for obvious reasons) is
"Applications MUST map IRIs to URIs by using the following two steps."
(see http://tools.ietf.org/html/rfc3987#section-3.1), but I'm sure you
can find quite a few more in various RFCs.
Regards, Martin.
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Thursday, 28 January 2010 06:05:19 UTC