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

John Leslie <> Wed, 10 August 2016 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EAA612D7A1 for <>; Wed, 10 Aug 2016 05:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id br35uweljWjz for <>; Wed, 10 Aug 2016 05:37:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 848C012B028 for <>; Wed, 10 Aug 2016 05:37:01 -0700 (PDT)
Received: by (Postfix, from userid 104) id 09ECE90960F; Wed, 10 Aug 2016 08:37:00 -0400 (EDT)
Date: Wed, 10 Aug 2016 08:37:00 -0400
From: John Leslie <>
To: Stewart Bryant <>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
Message-ID: <20160810123659.GH4396@verdi>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <>
Cc: Barry Leiba <>, IETF discussion list <>
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: Wed, 10 Aug 2016 12:37:03 -0000

Stewart Bryant <> wrote:
> Having thought a little more about this, I am wondering about
> unintended consequences in the 5K documents that we have
> written since RFC2119 was published.

   Actually, there is an obvious meaning of citing RFC xxxx or BCX xx:
which implies, "at the time of this publication".

   Nonetheless, I urge including text if leiba-rfc2119-update becomes an
RFC: stating that going forward, a reference to RFC 2119 will continue
to include-by-reference RFC 2119 as published, whereas a reference to
BCP 14 will include-by-reference whatever BCP 14 may be (or have been)
at the time any RFC referencing it is published.

   (This really doesn't change much of anything; but the opportunity for
confusion is _so_ great that I'm sure it will arise.)

   We must leave it to the RFC Editor to do whatever _can_ be done to
ensure that nobody "unintentionally" cites RFC 2119 or BCP 14 in such
a way as to cause further confusion.

> If we effectively change RFC2119 as we propose, is there a danger that
> readers will incorrectly interpret old text with new semantics. 

   RFC 2119 _cannot_ change.

   Nor, alas, _can_ we change the confusion in existing documents which
cite RFC 2119.

   We can only reduce that confusion going forward -- and that only if
the RFC Editor agrees to discourage citing RFC 2119 in future documents.

> I have no idea whether anything of significance will occur but
> considering the thought put into terms like SHOULD there exists a risk
> that would be mitigated if we picked a new RFC number whereupon the
> reader would know which definition the writers and reviewers were using.

   I would have recommended this, too, if I were writing the document.
But I stand by my previous statement: we can only reduce the confusion
if the RFC Editor discourages citing RFC 2119 after draft-leiba becomes
an RFC.

John Leslie <>