Well, I've learned some things here, and shall attempt to summarize:
1) First. the "1" key is really close to the "2" key, and my spell-checker
doesn't care. Apparently, I'm not alone in this problem.
2) We're all over the map in our use of 2119 language, and it is creating many
headaches beyond my own.
3) The majority of respondents feel that 2119 language should be used as stated
in 2119 -- sparingly, and free that MUST is not a substitute for "does". But
some people feel we need a more formal specification language that goes beyond
"key point compliance" or "requirements definition", and some are using 2119
words in that role and like it.
I'm torn as to what to do with the draft in question. I picked up an editorial
role after the authors fatigued in response to some 100+ AD comments (with
several DISCUSSes) and a gen-art review that proposed adding several hundred
2119 invocations (and that was backed up with a DISCUSS demeaning that the
gen-art comments be dealt with). My co-editor, who is doing most of the
key-stroking, favors lots of 2119 language. And I think it turns the draft into
unreadable felrgercarb.
But there's nothing hard we can point to and say "This is the guideline",
because usage has softened the guidelines in 2119 itself. It's rather like
those rules in one's Home Owner's Association handbooks that can no longer be
enforced because widespread violations have already been approved.
There appears to be interest in clarification, but nobody really wants to
revise the immortal words of RFC 2119, although there is a proposal to add a
few more words, like IF and THEN to the vocabulary (I'm hoping for GOTO,
myself; perhaps we can make 2119 a Turing-complete language.)
--
Dean