--On Tuesday, August 09, 2016 18:03 -0400 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
>...
> The point of lower case keywords shouldn't be to allow people
> to be sloppy and to avoid normative text to make a false
> consensus easier. This SHOULD be about writing clearer RFCs
> and not having to contort language when should and must are
> perfectly good non-normative things to say.
It seems to me that this is key. I'd even favor some text that
discourages the use of the lower-case forms except when the
meaning (normative status) is clear from context or the
alternatives would be really awkward. For example, something
like the following could be added to the second bullet in
Section 2:
"As a matter of editorial style and to reduce possible
confusion, especially with alternate presentation
methods, it is generally preferable to avoid the
uncapitalized forms in documents where the capitalized
ones are used unless the intent is very clear from
context",
That doesn't say "SHOULD NOT" or 'MUST NOT" use, but provides
general guidance and a basis for the RFC Editor doing some
negotiating when they deem it appropriate.
--On Wednesday, August 10, 2016 10:44 +1200 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:
>> REQUIRED, SHALL, SHALL NOT, RECOMMENDED, NOT RECOMMENDED,
>> OPTIONAL
>
> I will be glad to see the back of SHALL, but I object to
> deprecating the adjectives. They are useful - indeed,
> sometimes required - for the construction of readable
> sentences and, for example, tables of RECOMMENDED and OPTIONAL
> values.
It seems to me that we have tested the model of using different
terms, avoiding the 2119 terms entirely except when they are
used in normative form. At least for me,
draft-hansen-nonkeywords-non2119 offers fairly conclusive proof
that avoiding the 2119 terms entirely just causes the language
to be too stressed and convoluted, increasing confusion
(especially for people who are not expert in English). YNMD
about that, but I think the option of returning SHALL and the
adjectives to non-specialized use and forcing more convoluted
language to avoid the entire 2119 set are the alternatives and
that there is little point discussing one strategy in isolation
from the other.
Incidentally, as part of what I see as if we are going to do
this, let's clean things up, rather than merely
clarifying/modifying the case rules, it would be worth taking a
look at the five year old draft-saintandre-2119bis-01 for some
potential clarifications.
I think that means I disagree with draft-leiba-rfc2119-update-00
and its argument that it is best to fix 2119 piecemeal. We are
just too dependent on that document to apply a lot of separate
patches to it, a situation that will almost certainly lead to
confusion about which patches are in effect. Even if authors
are very careful about what they reference, readers at not
likely to be careful to check those references.
On the other hand, I am sympathetic to Barry's argument that
we've wasted altogether too much time arguing about what
lower-case "must" (etc.,) means and believe that some
clarification (almost independent of which one is chosen) would
be helpful. If the community wants to do that as a small
incremental change, it seem to me that this draft should confine
itself to the matter of case distinctions and avoid engaging in
the (obviously from the discussion) much more controversial
topic of getting rid of the synonyms or even, as an alternative,
explicitly discouraging, but not forbidding, their use.
--On Wednesday, August 10, 2016 10:03 -0800 Melinda Shore
<melinda.shore@xxxxxxxxx> wrote:
> Not much, I don't think. I certainly cannot think of
> an instance where a document has been anything other than
> trivially delayed by a discussion about normative language.
> And of course there are serious discussions about whether
> something should be mandatory or recommended, and this
> document really doesn't help those at all.
Actually, I can think of several instances, but they were not
associated with arguments about case sensitivity (Ted Lemon's
note about this, which I'm sure is correct, notwithstanding).
Instead, they were about another issue that I thought 2119 was
clear about until I encountered the problem. This I-D not only
doesn't fix that problem but might make it worse. The issue has
to do with whether 2119 language is required in normative
standards-track specs or whether an author can choose to use
other terminology or the same terminology with other
definitions.
MUST, SHOULD, etc., became prominent in our vocabulary with RFC
1122/1123, but the terms were used there in the sense of
"required to conform to this specification". RFC 2119 defines
them in terms of requirements to interoperate, not to conform.
The two are often the same, but certainly not always so. RFC
2821 does not reference 2119 and uses the terms in the RFC 1123
sense. When its successor, the I-D preceding RFC 5321, reached
the IESG with the same definition (IIR, a bit more explicitly
than in 2821), the IESG balked and insisted that there be a
reference to 2119 and that usage in the document conform to 2119
usage. Again IIR, since the IESG member(s) involved were
adamant and those those who had worked on proto-5321 were
running out of energy, the latter was adjusted to 2119
terminology, an effort that took some weeks.
The I-D now says (under "=== NEW ===" in Section 2), "This
document defines how these words are interpreted in IETF
documents when the words are capitalized." That is not "when
the words are capitalized and BCP 14 and/or this document is
referenced" or any such thing; it applies the definition to all
"IETF documents". The next paragraph (first bullet) appears to
contradict that ("...can be used as defined here, but it is not
required that they be. Specifically, normative text does not
require the use of these key words."). The combination is
a recipe for continued, possibly increased, confusion.
Finally, please either get rid of "capitalized" and/or
substitute "written in all capital letters" or equivalent. The
term "capitalized" is, itself, ambiguous and is correctly used
in the sentence "'Must' is capitalized".
best,
john