Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words]

John C Klensin <> Tue, 29 March 2016 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 931E312E137; Tue, 29 Mar 2016 13:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3mo4xCDrF_bc; Tue, 29 Mar 2016 13:40:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0721112DB81; Tue, 29 Mar 2016 13:03:27 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1akzrD-000KQ1-HR; Tue, 29 Mar 2016 16:03:19 -0400
Date: Tue, 29 Mar 2016 16:03:14 -0400
From: John C Klensin <>
To: "HANSEN, TONY L" <>, Tony Finch <>, Brian E Carpenter <>
Message-ID: <>
In-Reply-To: <>
References: <> <> < om> <> <> <> <> <20160328104731.GO88304@verdi> <> <20160328132859.GP88304@verdi> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Approved-At: Tue, 29 Mar 2016 14:02:39 -0700
Cc: "Heather Flanagan (RFC Series Editor)" <>,, IETF discussion list <>, Barry Leiba <>, IESG <>
Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words]
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Mar 2016 20:40:05 -0000

--On Tuesday, March 29, 2016 18:11 +0000 "HANSEN, TONY L"
<> wrote:

> On 3/29/16, 6:57 AM, "ietf on behalf of Tony Finch"
> < on behalf of> wrote:
>> Brian E Carpenter <> 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.