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