Uppercase question for RFC2119 words

[John Leslie <[e-mail]>]

NB this IMHO belongs on <[e-mail]>, and I'm directing Reply-To there

Barry Leiba <[e-mail]> 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 <[e-mail]>