>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 >> >
