Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

"John Levine" <> Tue, 09 August 2016 23:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8736E12D519 for <>; Tue, 9 Aug 2016 16:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7fKpD2Et6tOp for <>; Tue, 9 Aug 2016 16:28:43 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 732B512D16F for <>; Tue, 9 Aug 2016 16:28:43 -0700 (PDT)
Received: (qmail 86929 invoked from network); 9 Aug 2016 23:28:42 -0000
Received: from unknown ( by with QMQP; 9 Aug 2016 23:28:42 -0000
Date: 9 Aug 2016 23:28:19 -0000
Message-ID: <20160809232819.1291.qmail@ary.lan>
From: "John Levine" <>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <>
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: Tue, 09 Aug 2016 23:28:47 -0000

>Obviously, taste and correctness matter.
>It still won't be a good idea to say "The reserved bit must be zero on
>send and must be ignored on receive," arguing "Well, we don't want to
>use MUST because some implementations don't do that so it can't be

I'd write "The reserved bit is set to zero on send and is ignored on
receive" and save the command terms for things where one might think
that there was a reason to do something else.

>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