I don't like this update. Almost every sentences uses the passive voice. I think the use of "can," "are often," "do not have to be," and so on, is an awkward attempt to work around the use of the keywords as currently defined, or as redefined. These two usages do not help readability and clarity. How does this update affect interpretation of existing documents? It's ironic, I think, that the active voice clause, "Authors who follow these guidelines should incorporate this phrase" uses an uncapitalized "should," and I think it should be a "MUST." To Scott's semi-serious suggestion to deprecate "SHOULD," I'm hesitant. If there were another word for "do this unless you have a really good reason not to," I'd go for it. "Reasons not to" must be documented wherever possible, though sometimes not all reasons can be foreseen (see what I did there?). To another comment in the thread: I imagine that setting a reader to emphasize all caps would be annoying when reading specs with pronounceable acronyms. Lee On 8/9/16, 4:08 PM, "ietf on behalf of Barry Leiba" <ietf-bounces@xxxxxxxx on behalf of barryleiba@xxxxxxxxxxxx> wrote: >This draft should be self-explanatory -- and please be sure to look at >Section 1.1 for some explanations that may short-cut some of the >discussion. > >The bottom line is to update BCP 14 (RFC 2119) to >(1) make it clear that the key words MUST(/NOT), SHOULD(/NOT), and MAY >are only key words when they're in ALL CAPS, and >(2) deprecate the use of the variants (SHALL, RECOMMENDED, OPTIONAL) >so as to avoid reserving an unnecessarily number of key words. > >Discussion here, please, before Ben, who has kindly agreed to >AD-sponsor this, sends it out for last call. And we do expect there >to be some significant discussion on this one. > >Barry > >On Tue, Aug 9, 2016 at 2:55 PM, <internet-drafts@xxxxxxxx> wrote: >> >> A new version of I-D, draft-leiba-rfc2119-update-00.txt >> has been successfully submitted by Barry Leiba and posted to the >> IETF repository. >> >> Name: draft-leiba-rfc2119-update >> Revision: 00 >> Title: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words >> Document date: 2016-08-09 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-leiba-rfc2119-update-00.txt >> Status: https://datatracker.ietf.org/doc/draft-leiba-rfc2119-update/ >> Htmlized: https://tools.ietf.org/html/draft-leiba-rfc2119-update-00 >> >> >> Abstract: >> RFC 2119 specifies common key words that may be used in protocol >> specifications. This document aims to reduce the ambiguity by >> clarifying that only UPPERCASE usage of the key words have the >> defined special meanings, and by deprecating some versions of the key >> words. >> > >