Some snippets from another discussion thread, in a galaxy far, far away:
Murray:
Sections 1, 3-7: The "may" in a document citing RFC2119 ought to be
"can" or such.
Ned:
This seems pretty silly to me. The entire point of capitalizing these
terms is so they aren't confused with conventional usage, freeing up
the regular forms for conventional use.
Murray:
As Dave would have pointed out had I not beaten him to it, RFC2119
doesn't actually say "MAY" is different from "may". And I've been
asked to deal with this in enough of my own drafts that now I bring
it up when I see it.
Barry has suggested, and I believe the IESG has allowed, that the
RFC2119 boilerplate included in the document also say that the RFC2119
meaning for each only applies when the word is in all-uppercase.
That
allows the stuff you're talking about.
We could further suggest that someone who feels so inclined propose a
BCP draft to actually update RFC2119 accordingly.
In fact, RFC 2119 says that the normative keywords are "often
capitalized", but doesn't require that they be.
As Murray says, my habit is to use this for 2119 boilerplate:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
This passes all nit checks, including those involving the eyes of the
IESG, and I think it makes the situation absolutely clear. We could,
certainly, as Murray notes, update 2119 to require all caps in order to
use the words as 2119 terms.
Alternatively, Tony and Dave had submitted this draft, now expired:
http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119
It suggests words such as "can" and "ought to" as substitutes, which is
what Murray's original review was also suggesting.
The trouble with the first approach (using all caps as 2119 terms, and
using the same words in lower case as normal English) isn't so much
that someone might be confused later, but that during development and
review we're not sure whether you meant to put the word in all caps,
and just forgot. No amount of documentation can avoid that question,
and using "can" or "ought to" gets us away from the issue.
The trouble with the "non-normative synonyms" is that it makes document
text awkward, by requiring us to artificially substitute less apt
words, when "may" and "should", as English words, are exactly what we
mean.
It's probably worth having a discussion of all of that, and seeing
whether there's some possibility of developing a rough community
consensus on what we might-could-maybe-oughta-should do.
Barry