Re: I-D Action: draft-hansen-nonkeywords-non2119-04.txt

[Dave Cridland <[e-mail]>]

On 3 March 2016 at 07:01, Dave Crocker <[e-mail]> 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.