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

Barry Leiba <> Mon, 28 March 2016 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEE1812D526; Mon, 28 Mar 2016 13:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 30uQPKQhguEZ; Mon, 28 Mar 2016 13:30:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53A0C12D538; Mon, 28 Mar 2016 13:30:37 -0700 (PDT)
Received: by with SMTP id i4so89635850qkc.3; Mon, 28 Mar 2016 13:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=8DzbuAPLRwbfcVHLJ1XCNK4FwQdLyvjZw8cK8S5Kf8A=; b=TZCMd90+7J/3oSG1Iivdno+5axZRsPX6u8ZwCmA/xzT3CFU8M7IxQM9paxKueQyO5V dhQw9U72MY3tkvG57NQudfYc6JY726lJGPsHuX7kUGRBpyhxiD32nH16ma+korwzxuxQ 7FKuGBQeJnD2nLM3pLwMP7sbH2sC2uUdZN7U1BxmzeWtBYt78qpsn8UrZh2eGBQskuNq O5dL95Yhc59xtOkaWaUCvjHcnehownYDW+I9zHyAuSDJLHvfFeZnY1BFCNZisA3bH9T0 5nOWpt171rYOqufPnW9kbSblxsiT+mnrIsZYuqujhRVmPwVMXC70cUJdYRLQOqNcsDMf cxUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=8DzbuAPLRwbfcVHLJ1XCNK4FwQdLyvjZw8cK8S5Kf8A=; b=kt2SXTbL86RAnMTDuwNefmF43vZj3NOGS5gDS1BS4sC4pBaJip9B4DKd7GrVETkvsk Wq2bJDFqhF3I2E22WQ5m1yJhVTwtVE3gaYujH0lu3ESbOcz6f+UZuRVsRJX/LDZt/xcz XzCeEF2uihtxXg7VJdQ4jK0vInRWkqMm2hQF9bqQ7Me7WEjOlolTyJTBrPU/twhLfwaY tjuCx8WPMnO7j5jxhYSisQyvu2KhKCDRmQF7EaSJCpWp6iUB7LHEnpq8QRptUM1TYlTm s+ucPZNicjiImdIT43jigvlyXKHn0e8UdMUfdkFW1F1Y60phUstusS8eXGI+yNWTD5kc YWMA==
X-Gm-Message-State: AD7BkJJJ2Vo3THf/fi+9jbH2XLUIaWvOZWfK4xkBpYhD/0RAh8Zk+Xo2ItS8VzM+ZbfaG+T36vxp1A6flQQhTw==
MIME-Version: 1.0
X-Received: by with SMTP id d64mr8926543ybh.159.1459197036324; Mon, 28 Mar 2016 13:30:36 -0700 (PDT)
Received: by with HTTP; Mon, 28 Mar 2016 13:30:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <20160328104731.GO88304@verdi> <> <20160328132859.GP88304@verdi> <> <> <> <>
Date: Mon, 28 Mar 2016 16:30:36 -0400
X-Google-Sender-Auth: Ml2IqVgirJknZRCDgaQNt_uXLOU
Message-ID: <>
Subject: Re: Fuzzy words [was Uppercase question for RFC2119 words]
From: Barry Leiba <>
To: Brian E Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "Heather Flanagan (RFC Series Editor)" <>, "" <>, IETF discussion list <>, IESG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Mar 2016 20:30:42 -0000

Brian, I think your note goes to how important it is to write clearly
and to get a lot of eyes on it before we publish it.  Well-written
documents, with or without 2119 key words, and with or without
lower-case look-alikes, can still be clear.  Fuzzily written documents
will be fuzzy.

In particular:

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

Well, this is where 2119 advises that we *use* the key words when
interoperability is at stake.  It's fine to be fuzzy when it doesn't
matter, though even then, I'd argue for more explanation:

   Every frobotz MUST contain a valid bleeg.  The glorp field in the
   frobotz is an unsigned integer that is normally between 0 and 666,
   inclusive.  Values greater than 666 are allowed, but recipients
   using older software might not be able to handle such values.
   When processing a frobotz that does not meet the requirements in
   section 3.1.4, it is permissible to reject the frobotz outright, or to
   attempt to process the parts of it that make sense; the choice is
   an implementation decision.  However, any frobotz that does not
   contain a valid bleeg MUST be rejected.

That sort of thing.


On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter
<> wrote:
> 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 <> 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