NB this IMHO belongs on <ietf(_at_)ietf(_dot_)org>, and I'm directing Reply-To
there
Barry Leiba <barryleiba(_at_)computer(_dot_)org> wrote:
Martin says:
... while for some people, the difference between upper and lower case
is very strong, for others, it's not perceived that strongly. Examples
may include people whose native script doesn't make such a distinction
This has been brought up before. I know Martin lives in such a
country, so perhaps he has different data, but I have checked with my
own Chinese colleagues, and they confirm that they *do* understand,
notice, and pay attention to the difference in case when they're
reading the documents. (It's entirely possible that they're more
prone to making case errors when they're writing, but that speaks to
the "getting it right" part, which I always consider a problem --
there are a great many wrong uses of 2119 key words that show up
often, and some of those are, no doubt, due to authors writing
"should" or "may" or "must" and thinking they ought to put that in
upper case.)
John comments:
... It would be good if the relevant entity (I have copied the IESG
and the RFC Editor, but somebody else may be in charge here)
(indeed, the IESG may or may not be in charge here; but this is a
definite mine-field as we try to escape the ASCII straitjacket when
preparing RFCs)
I believe the IESG is *not* in charge here, other than to have
different ADs pick at different things in our reviews. I believe the
community is in charge.
I agree with Barry: the community should be in charge.
The key point is the second sentence of the Abstract from RFC 2119:
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized.
Please note that an Abstract is never supposed to override the
document itself. (But I agree this is the source of the issue.)
The problem here is that it's explanatory, not normative. The
explanation -- and the usage custom -- leads many of us to think we
can use capitalization to make the distinction, while the fact that
its not normative leads many of us to think that "should" means
"SHOULD".
I think Barry has it right; but I hope our readers don't confuse the
Abstract with the explanation in the body of the document.
My suggestion is to write a tiny draft (I'm willing to be the editor
of that) that updates 2119, which makes one of the following changes:
NEW -- alternative 1
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized, as shown below, but they have special, requirements
meanings regardless of capitalization.
NEW -- alternative 2
In many standards track documents several words are used to signify
the requirements in the specification. These words have special,
requirements meanings only when they appear in ALL CAPITALS,
as shown below.
Needless to say, I prefer alternative 2...
The hard bit, of course, will be to determine which of those
alternatives the community has rough consensus on.
And for that determination, the IESG _is_ in charge.
Perhaps I will post an I-D when the pre-meeting fog lifts, and we can
bash it out on the IETF discussion list.
Actually, I suggest on-list discussion before that, and Barry posting
_after_ the plenary, when he has left the IESG (and returned to the
_actually_ important work of IESG scribing ;^)
I know this is a religious-war; and I apologize in advance for not
being present in Buenos Aires to receive the in-person flamage.
Nonetheless, I restate my opinion:
] IMHO, the intent (when 2119 was written), was to define new words
] using ASCII uppercase, not to redefine English words. As evidence,
] I cite the three uses of lowercase "must", four uses of lowercase
] "should", and five uses of lowercase "may", which are a true challenge
] to interpret as 2119 keywords.
And I beg folks to respect the convention that an Abstract must not
_change_ the meaning of a document.
(I'll wait for later to argue why I believe alternative 2 is a better
way to run a railroad...)
--
John Leslie <john(_at_)jlc(_dot_)net>