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