Fuzzy words [was Uppercase question for RFC2119 words]

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 28 March 2016 19:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1012D155; Mon, 28 Mar 2016 12:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 35HiHBDb--xO; Mon, 28 Mar 2016 12:58:14 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A9412D183; Mon, 28 Mar 2016 12:58:14 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id n5so144801869pfn.2; Mon, 28 Mar 2016 12:58:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3crMLs86+6DTIjfXPjKkTBomscUba+IhnLSIDEpHwgo=; b=KGoshIMGMcFgSsHMUVegyBcvESLtSyCGSqgXuhUqGn27CAecwBSAMLRvFJpn8yVLFn wvD9OIZctbLVGlUfEmS8dA8fAlO70EpcZ95aR0TKVI2rEBwR+ax09kzHF0UCvAVj5/qi GppvGhxfqW1F/nq9QB5xsQ5C50tBE1/83QI6xBGuI+0wcvnczy1T1c2iFW0igHCCoaC9 jkvNm6A3Sf7rXvLiMOeBlZGaGei6iDPGJlPEPFc3ovw82wHBjwUDY/PG382DDADLXxHx N2ZY30mGwd4+hxT34wO70he5PiR7Nu4d02QIef6JB8GTzBHPxipQWnFX2CKgY4uo6qiU 2YWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3crMLs86+6DTIjfXPjKkTBomscUba+IhnLSIDEpHwgo=; b=lDldzNKghwh0Kgy09xRP8LJVuD1aaM0X9stdMcKAoV6pc8UnINRuzLBaW0n2KC/2Lt S7R71sTyhOOo+Jhp6NJCP3SNffdu3Ctaf55dakZeBHreZRki1mfTE8cc2rc6otjqW4lS QzBRVmGprUta2RuLl+uKBlUEojrcWL3Gey+NwhymNA8uy/lXgzDaqeuPw7ulYyn8XXlj g1x+jtOdv8GjwaqH52f9pjkjSfIDWn3LkBbjXkaGQEexcVwyXR9DlAj24XY78uGKXN7/ n0wMeauOG3LVSCVdTYCKoVu2YgWqLrM4jCgAqnwzXlq7wUtlgmwXlQ252XThvRs+osW1 6pPA==
X-Gm-Message-State: AD7BkJIMRKNOElgdgOHULOyyWnw+7AwSlgv2NWBC2Y74HoOHOiQHw41phOYfUoH89z16wg==
X-Received: by with SMTP id 88mr45820899pfi.51.1459195094192; Mon, 28 Mar 2016 12:58:14 -0700 (PDT)
Received: from ?IPv6:2406:e007:71e7:1:28cc:dc4c:9703:6781? ([2406:e007:71e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id tb10sm37690885pab.22.2016. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 12:58:12 -0700 (PDT)
Subject: Fuzzy words [was Uppercase question for RFC2119 words]
To: "Scott O. Bradner" <sob@sobco.com>, Barry Leiba <barryleiba@computer.org>
References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CA+9kkMCsT43ZCSdq8gdKXu1k4pJgbf0ab5tE=dDiFfrTT2gtkA@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <CALaySJ+hYMMsKE7Ws-NJbyqH55E-mQM-duTEcJGc0TWvTP88Ew@mail.gmail.com> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <CALaySJJkNj2jfm0gJpuDzq8oFDjTNn-uQ5MHdmEOLwTiFZUyQQ@mail.gmail.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <56F98CD1.10706@gmail.com>
Date: Tue, 29 Mar 2016 08:58:09 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Op7NEaNGzR_evTWvziRHLnxlEpc>
Cc: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, IETF discussion list <ietf@ietf.org>, IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2016 19:58:16 -0000

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

> 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.

On 29/03/2016 03:13, Scott O. Bradner wrote:
> one minor tweak
>> On Mar 28, 2016, at 10:09 AM, Barry Leiba <barryleiba@computer.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