--On Tuesday, March 29, 2016 18:11 +0000 "HANSEN, TONY L"
<tony@xxxxxxx> wrote:
> On 3/29/16, 6:57 AM, "ietf on behalf of Tony Finch"
> <ietf-bounces@xxxxxxxx on behalf of dot@xxxxxxxx> wrote:
>
>
>> Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
>>
>>> 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.
>>
>> I think if a document uses RFC 2119 keywords then it ought to
>> avoid non-capitalized uses of the keywords, e.g. by replacing
>> "should" with "ought to" or other rephrasings.
>>
>> Tony.
>
> Cue reference to "draft-hansen-nonkeywords-non2119" :-)
Tony (and Tony), it seems to me that raises a fundamental issue
in editorial philosophy and style as well as some human factors
issues... the latter especially for readers who have to
translate (if only in their heads) between English and whatever
language they "think in". I just don't know whether it is
possible to fix/adjust 2119 without resolving it.
There are, I think, two almost-separate problems. The first is
that 2119, presumably in the interest of smooth and elegant
writing and phrasing, defined and therefore preempted not only
MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, but several of the
obvious synonyms. Had it not done that, it would have been
possible to say "for IETF purposes, these are not synonyms,
their meanings are different, and upper-case is just a
convenience for emphasis". But those obvious synonyms are gone
too, so that avoiding the non-normative versions of the terms
requires some rather awkward circumlocutions as, IMO, some of
the recommendations of draft-hansen-nonkeywords-non2119 rather
painfully illustrates.
If you want to understand how painful, pick a non-English
language with with you or one of your colleagues is familiar, a
language that is not closely related to English in vocabulary
and semantics (i.e., not either a Germanic or a Romance
language), and then toss the text of a standard with the terms
recommended in your I-D mechanically substituted for the
normative 2119 terms into the widely-available automatic
translation tool of your choice. I've tried an experiment or
two like that; the results were, IMO, appalling but YMMD.
So I just don't see that as a viable solution unless you want to
make writing clear I-Ds really difficult (and Heather and the
Production Center are willing to let those awkward constructions
make it into RFCs).
Again, this is partially a philosophical disagreement, so I
recognize that there are other points of view.
best,
john