Re: RFC 2119 terms, ALL CAPS vs lower case

[Dave Crocker <[e-mail]>]

On 5/16/2012 6:59 AM, Barry Leiba wrote:
> This passes all nit checks, including those involving the eyes of the
> IESG,

Computer Science has a long history of being quaint about the role of 
upper/lower case and then ignoring the problems caused by the 
distinctive interpretation it imposes.  It has never recovered from a 
couple of decades of having no upper case, and continues to treat the 
capability as worthy for semantic distinction, in contrast with natural 
usage.

it is ALso interesting to hear that the IETF's actual standards are not 
what is written in our documents but what is in our SUBMISSION testing 
code and the whims of personal interpretation (by the IESG).  There are 
faint echos of Through the Looking Glass, here.  Things mean whatever 
the IESG chooses to declare them to mean, not what the plain language in 
formally adopted documents say they mean.

This is not the sort of topic that should be artificial nor nuanced, nor 
should it encourage misunderstanding.  Case does not define meaning in 
normal language, why should it here?

It is not exactly an onerous task to use different vocabulary, to make 
sure there is no potential ambiguity for readers.  Relying solely on 
case to distinguish between normative vs. non-normative is, forgive me, 
really silly.


> Alternatively, Tony and Dave had submitted this draft, now expired:
> http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119
> It suggests words such as "can" and "ought to" as substitutes, which is
> what Murray's original review was also suggesting.
>
> The trouble with the first approach (using all caps as 2119 terms, and
> using the same words in lower case as normal English) isn't so much that
> someone might be confused later,

It is certainly one of the troubles with it.


> but that during development and review
> we're not sure whether you meant to put the word in all caps, and just
> forgot. No amount of documentation can avoid that question, and using
> "can" or "ought to" gets us away from the issue.

And yes, this is certainly another trouble with it.


> The trouble with the "non-normative synonyms" is that it makes document
> text awkward, by requiring us to artificially substitute less apt words,
> when "may" and "should", as English words, are exactly what we mean.

Because, after all, technical specification language is already such 
elegant prose, maintaining that elegance is more important than robustly 
encoding the semantic of being normative in a way that avoids ambiguity?

I guess the underlying issue here is whether the rather essential burden 
of working to carefully discerning normativity is placed on the small 
range of authors of a specification or on the variable ocean of 
potential readers?

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net