On 3 March 2016 at 07:01, Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
Folks,
G'day. We'd like to see whether there is interest in getting the enclosed published.
It's meant as a helpful suggestion for avoiding possible confusion in the use of vocabulary the IETF treats as normative.
The latest version works a bit harder to avoid appearing, itself, to be giving normative direction...
It's not entirely clear to me that if a specification says "support for FOOBAR is necessary in order to support BLURDYBLOOP", that this is anything different from "implementations MUST support FOOBAR in order to support BLURDYBLOOP". The latter is easier to spot, of course, and might well be preferable for that reason alone, but I would expect an implementer to treat the two with equal weight.
RFC 2119 is, I have always assumed, for clarification of intent when making normative statements, rather than the only way of making something normative. This draft appears to imply, for example in the final sentence of §4, that the RFC 2119 keywords have a particular standing in terms of normativity. Some of the suggested alternatives are effectively stating normative requirements; at the very least the uses when one does not intend normative meaning are not the first things that spring to mind.
That said, providing suggested alternate phrasing when one explicitly does not wish to evoke the meaning given in RFC 2119 is a useful thing; but perhaps some examples of non-normative use of the English words (and suitable rephrasings) might help reduce any confusion. "May be aware", "must consider", "should prove useful", etc.
Also, I was going to suggest you might not mean "verbiage"; but then I discovered the US meaning. The rest of the English-speaking world exclusively uses the meaning of "excessively lengthy or technical speech or writing". "Wording" or "phrasing" might work just as well, without the alternate meaning.
Dave.