+1
My view that this is more about the specific issues of documents and
not just RFC2119 itself. Sometimes it falls through the cracks.
Sometimes a justification or argument is found to show the contrary of
what is stated, especially when its uses lower cases or even terms
like "choose." Sometimes its just new conflicts of integrated
documents where perhaps an augmented RFC attempts to reinforce what
the base RFC may have lacked.
In my view, it will help if future I-D and RFC authors begin to have
one new section called in chapter 1.0
1.x - Minimum Compliancy Requirement Summary
Far too often documents have mixed functional and technical
specifications, mixed normative and non-normative compliance semantics
too spread out and peppered throughout the document making it harder
to catch compliance level issues.
--
HLS
Brian E Carpenter wrote:
On 2012-05-16 18:53, Peter Saint-Andre wrote:
On 5/16/12 9:58 AM, Sam Hartman wrote:
...
I'll note that in my normal reading mode I do not distinguish case,
but even so I find the ability to use may and should in RFC text without
the 2119 implications valuable.
Agreed. But as a gen-art reviewer, I have several times had to ask
authors whether a particular lower case "may" was intended to be normative
or normal English. Authors must be fastidious about this.
Your mileage may (or is that MAY?) vary, but to forestall confusion I've
settled on the practice of using "can" and "might" instead of lowercase
"may", "ought to" and "is suggested to" instead of lowercase "should",
and "needs to" or "has to" instead of lowercase "must" (etc.). I'm not
saying that anyone else SHOULD or MUST use that convention, but you
might consider it in your own spec-writing.
It is indeed very important not to use "may" when it's ambiguous.
"It may rain today" is fine; "you may leave now" is not (I can think
of three different meanings). In RFC2119-talk, "you MAY leave now"
only has one meaning.