--On Wednesday, March 30, 2016 07:34 -0700 Dave Crocker
<dhc@xxxxxxxxxxxx> wrote:
> That such a rule differs from natural English -- which does
> not typically alter semantics based on case -- and that most
> readers of RFCs will not have such detailed knowledge of
> RFC2119 nor read RFCs with the care such a rule demands, my
> question BARRY and adam and EveryOne Else, is what makes
> anyone think that such a rule must (MUST?) ensure proper
> reading of RFCs so as to distinguish between normative
> portions and advisory portions?
Dave, I'd suggest that technical (and, btw, legal) documents
define words to have local meanings in the context of that
document all the time, and that caps, boldface, italics, and
capital letters are commonly viewed as doing a favor to the
reader. Usually that is done for slightly-unusual terms, rather
than words that are in common use, but that doesn't really
change the situation especially because, for most practical
cases, the difference between 2119-MUST and ordinary-must is
fairly slight. I've explained elsewhere why I don't believe
the use of convoluted and forced language to avoid using words
like "must" is not a satisfactory solution, YMMD on that point
(and, I presume, does).
> It's worth distinguishing between rules that make the writers
> more comfortable, from rules that aid the reading efficacy in
> practical terms.
Sure. But the convoluted sentences proposed by some
alternatives are likely to improve the situation for neither
group.
It seems to me that we may be asking the wrong questions. To
review and consolidate two things that others have mentioned,
there are almost separate issues about (i) the difference
between normative and non-normative language and (ii) the
difference between interoperability requirements and conformance
requirements.
For the first, I don't think expecting people to do detective
work based on whether or not certain words (capitalized or not)
appear in a sentence of paragraph. If we don't think our
documents are clear enough about it, the solution probably lies
in what some other standards bodies have done for years: be
really clear about whether the default is normative or
non-normative and then specifically identify every section or
paragraph that is the other. That approach is sometimes tedious
for both authors and readers but is efficacious for readers and
does not allow misunderstandings.
On the other hand, while the problem is easy to identify and
worry about, in watching IETF documents over the years, I've
rarely seen examples that represent real problems in practice.
The only major exceptions occur when the same information is
presented in two ways. For example, when an ABNF description of
syntax and a prose description both appear in the same document
and do not turn out to be 100% consistent, it might be helpful
to have clear language that says "that is the one to believe if
there is any doubt", but we've often done that without having to
resort to "normative" and "non-normative" section labeling.
For the second, 2119 made a shift from the conformance language
of, e.g., RFC 1122 and 1123, to interoperability language. In
retrospect, I think the implications of that change (quite
unintentionally, AFAICT) snuck by the community and perhaps have
never been adequately appreciated. In many cases, there is no
practical difference but, it is sometimes important. If that is
really our problem today --and a number of comments on these
threads suggest that it is -- then we aren't going to solve it
by discussing whether some words are written in upper case. The
solution to that one probably lies in a 2119bis that provides
two sets of definitions (or at least explanations) and requires
each invoking document to call out which it is using.
best,
john