NB this IMHO belongs on <ietf@xxxxxxxx>, and I'm directing Reply-To there Barry Leiba <barryleiba@xxxxxxxxxxxx> 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@xxxxxxx>