On 5/16/2012 6:59 AM, Barry Leiba wrote:
This passes all nit checks, including those involving the eyes of the
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
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,
Alternatively, Tony and Dave had submitted this draft, now expired:
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