On Sat, 2012-05-19, Brian E Carpenter wrote:
On 2012-05-19 20:39, Ofer Inbar wrote:
...
But don't change the rules. 2119 works well as is IMO.
Just to be clear about the current rules, 2119 makes it clear that
upper case keywords are optional ("These words are often capitalized").
Indeed, numerous standards track documents don't use them.
I do not agree that 2119 is "clear" on this topic. I read the
beginning of the first paragraph of the Abstract as:
Some background motivation:
In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized.
A new proposal:
This document defines these words as they should be interpreted
in IETF documents.
Thus, it is defining a new, unified convention for documenting
requirements language.
And then the boilerplate shows all of the requirement words in
uppercase, obviously convincing a lot of people that the new
standard is to use them in uppercase when their meaning is
normative.
As one example, in section 6 the text reads:
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
There is one instance of "MUST" and two of "must" in this
paragraph. I would observe that the "MUST" is used to define a
requirement upon RFC texts, but the two "must"s are used to
try to affect the motivation of the humans writing the RFC texts.
There are examples elsewhere in 2119 of the use of these words in
lowercase that seem NOT be used in a normative way.
If anything I would evaluate the evidence to indicate that the
distinction of case *was intended* to be meaningful.
--
Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>