Brian,
I agree with most of what you say. My impression has been that many
times the use of some
of the fuzzier words stems from the fact that the author(s) have occasionally
forgotten that they are
writing a specification, and not a bit of literary prose.
Using variation in wording does not make a specification more readable,
as it might a piece of
literature. It makes it less readable, even if it might make it a less boring
read.
I am not certain that making a specification exciting enough to keep
the average reader awake is
a goal.
One area where I do slightly disagree is in your characterization of
the use of must verses MUST,
and similar words. The English usage of the word "must" can vary slightly from
the normative use of the
word "MUST."
As an example - in the statement "what goes up, must come down" - the
word "must" is almost
certainly meant to reflect a fact of nature, as opposed to an implementation
choice that is needed if we
want to have interoperable implementations of a specification.
If you could throw a ball into the air, and it just hung there, I'm not
sure we should refer to it as
"non-compliant." :-)
Also, a statement along the lines of "electronic equipment MUST have a
power source of some
sort" is not particularly useful for interoperability - even though it seems
likely to be true.
Nor do I think we would want an implementation that did not have this
limitation to be deemed
non-compliant.
There are similar uses for "need" for instance. And - while I cannot
think of an example at the
moment - I am not prepared to bet the farm that there are no such similar uses
for "required." Maybe
this might be the case for a legal requirement that has nothing to do with
compatible implementation?
In any case, it is occasionally necessary to use these terms in an
explanatory sense, having not
very much to do with specification of normative behavior. The good news is
that most of us can tell if
the meaning is explanatory, verses normative.
--
Eric
-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Brian E
Carpenter
Sent: Monday, March 28, 2016 3:58 PM
To: Scott O. Bradner; Barry Leiba
Cc: Heather Flanagan (RFC Series Editor); rtcweb(_at_)ietf(_dot_)org; IETF
discussion list; IESG
Subject: Fuzzy words [was Uppercase question for RFC2119 words]
There are times when I think RFC2119 was a really bad idea, despite it having
become probably the most frequently cited RFC (inside and outside the IETF).
It seems to create as much confusion as it avoids.
There are four words whose RFC2119 meaning is different from the dictionary
meaning: should, recommended, may and optional. Having special typography
for them is useful, because it signals the RFC2119 meanings. But if a spec
uses, for example, a mixture of SHOULD and should, who knows what the authors
intended? To that extent, the proposed clarification is helpful.
The other words (must, shall, required, not) mean what they always mean.
The only argument for upper-casing them is aesthetic symmetry. If a spec
uses alternatives like mandatory, necessary or forbidden, they are just as
powerful.
So
these definitions are only meaningful if the words are capitalized
can be applied to should, recommended, may and optional if we want,
but strictly doesn't apply to must, shall, required, not, mandatory,
necessary, forbidden, need, or any other such words.
Where we can get into real trouble is if a spec contains should, recommended,
may and optional *plus* other non-categorical (fuzzy) words like ought,
encourage, suggest, can, might, allowed, permit (and I did not pull those
words out of the air, but out of draft-hansen-nonkeywords-non2119). What do
they mean? It can be very unclear. If a node receives a message containing
an element covered in the spec by "allowed" instead of "OPTIONAL", is the
receiver supposed to interoperate or to reject the message?
If we are issuing guidance, it should probably include a specific warning
to use any such fuzzy words with extreme care.
Brian
On 29/03/2016 03:13, Scott O. Bradner wrote:
one minor tweak
On Mar 28, 2016, at 10:09 AM, Barry Leiba
<barryleiba(_at_)computer(_dot_)org> wrote:
The wishy washy descriptive rather than proscriptive language in the
abstract was because I,
the IESG and the community were not of one mind to say that the use of such
capitalized
terms should be mandatory - quite a few people felt that the english
language was at
least good enough to convey the writer’s intent without having to
aggrandize specific words.
Thus the abstract basically was saying: if you want to use capitalized
words here is a standard
way to say what they mean
Ah. Then perhaps the clarification needs to go a little further and
make this clear:
- We're defining specific terms that specifications can use.
- These terms are always capitalized when these definitions are used.
these definitions are only meaningful if the words are capitalized
- You don't have to use them. If you do, they're capitalized and
their meanings are as specified here.
- There are similar-looking English words that are not capitalized,
and they have their normal English meanings; this document has nothing
to do with them.
...and I'd like to add one more, because so many people think that
text isn't normative unless it has 2119 key words in all caps in it:
- Normative text doesn't require the use of these key words. They're
used for clarity and consistency when you want that, but lots of
normative text doesn't need to use them, and doesn't use them.
Barry