Re: RFC 2119 terms, ALL CAPS vs lower case

[Abdussalam Baryun <[e-mail]>]

Hi

It is preferable to update RFC2119 to be more suitable for IETF RFCs
in the future, IMO importance of using CAPS is understood, but when to
use lower case (e.g. must, should, etc.) is not clear. Some use their
sensibility to determine when to use lower case. In the end we can
leave it for the editors to feedback on that when submitting, or use
different sentences. In summary, from some discussions, RFC2119 seems
not to be the best practice so far.

Abdussalam

+++++++++++++++++++++++++++++++++++++++++++++
--On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:

> On 2012-05-19 20:39, Ofer Inbar wrote:
> ...
>
>>  But don't change the rules.  2119 works well as is IMO.
>
> Just to be clear about the current rules, 2119 makes it clear
> that upper case keywords are optional ("These words are often
> capitalized"). Indeed, numerous standards track documents
> don't use them.

Brian,

I've been trying really hard to avoid this discussion, but I
think the above is misleading.

In recent years, various IESG members have insisted that any
IETF Track document that contains anything approximating
conformance language include the 2119 reference and whatever the
strict interpretation of the week is about caps, etc.  As Randy
suggests, there have been signs of more nuance in the last IESG
or two, but...

The same problem applies to the other issue with 2119, which is
that we have history for at least two different interpretations
of those words, the ones in 2119 that are interpreted as
"necessary for interoperability" and the ones in, e.g.,
1122/1123 (Section 1.3.2 in the latter) which are "requirements
of the specification" without binding those requirements to a
particular reason.  From my point of view, the other difficulty
with treating 2119 like Received Wisdom and a set of absolute
requirements is that the interoperability criterion often makes
no sense for what are perfectly reasonable requirements.  As an
example drawn from 1123, a specification might reasonably say
"this option MUST be configurable" because it is necessary to
make things work in a plausible way even if that statement
cannot be explicitly linked to "won't interoperate unless it
does".   But again, in recent years, some IESG members (and
others) have insisted that only the 2119 definitions are
permitted.

The combination of the two is known in some quarters as writing
technically poor or deficient specs in the interest of clear
conformance to procedures.  At least historically, that was a
trap the IETF tried to avoid.

    john