Re: meaning RFC 2119 (was Re:I'm struggling with 2219 language again)

[Abdussalam Baryun <[e-mail]>]

>I guess the test is whether a reasonably
careful reader might interpret a sentence incorrectly while writing code;
and if so, would a normative keyword help?

I think the best key word used/help is *IF, THEN, ELSE* the programmer
will never miss that key for running code and specification.

AB

> Hi Dean
>
> I agree with you which I suggested before an update to the RFC [*], I
> actually writing a work in progress ID, you may give me your
> suggestion if you like. I recommend you use for your work IF, THEN
> rather than MUST. Easier to read.
>
> *  http://tools.ietf.org/id/draft-baryun-rfc2119-update-00.txt
>
> AB
>
>>
>>
>> I've always held to the idea that RFC 2119 language is for defining
>> levels of compliance to requirements, and is best used very sparingly
>> (as recommended in RFC 2119 itself). To me, RFC 2119 language doesn't
>> make behavior normative -- rather, it describes the implications of
>> doing something different than the defined behavior, from "will break
>> the protocol if you change it" to "we have reason to think that there
>> might be a reason we don't want to describe here that might influence
>> you not to do this" to "here are some reasons that would cause you to
>> do something different" and on to "doing something different might
>> offend the sensibilities of the protocol author, but probably won't
>> hurt anything else."
>>
>> But I'm ghost-editing a document right now whose gen-art review
>> suggested replacing the vast majority of "is" "does" and "are" prose
>> with MUST. The comments seem to indicate that protocol-defining text
>> not using RFC 2119 language (specifically MUST) is "not normative".
>>
>> This makes me cringe. But my co-editor likes it a lot. And I see smart
>> people like Ole also echoing the though that RFC 2119 language is what
>> makes text normative.
>>
>> For example, the protocol under discussion uses TLS or DTLS for a
>> plethora of security reasons. So, every time the draft discusses
>> sending a response to a request, we would say "the node MUST send a
>> response, and this response MUST be constructed by (insert some
>> concatenation procedure here) and MUST be transmitted using TLS or
>> DTLS.
>>
>> Or, a more specific example:
>>
>> For the text:
>>
>> In order to originate a message to a given Node-ID or
>> Resource-ID, a node constructs an appropriate destination list.
>>
>>
>> The Gen-ART comment here is:
>> -First sentence: "a node constructs" -> "a node MUST construct"
>>
>>
>> We'll literally end up with hundreds of RFC 2119 invocations (mostly
>> MUST) in a protocol specification.
>>
>> Is this a good or bad thing? My co-editor and I disagree -- he likes
>> formalization of the description language, and I like the English
>> prose. But it raises process questions for the IETF as a whole:
>>
>> Are we deliberately evolving our language to use RFC 2119 terms as the
>> principle verbs  of a formal specification language?
>>
>> Either way, I'd like to see some consensus. Because my head is
>> throbbing and I want to know if it MUST hurt, SHOULD hurst, or just
>> hurts. But I MUST proceed in accordance with consensus, because to do
>> otherwise would undermine the clarity of our entire specification
>> family.
>>
>> --
>> Dean
>>
>