|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.
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.
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 RFC2119meaning for each only applies when the word is in all-uppercase.
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-non2119It 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.