IETF Logo Mail Archive

Re: Question about BCP 14 / RFC 8174

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 29 August 2025 19:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BB06C5ACEEEA for <ietf@mail2.ietf.org>; Fri, 29 Aug 2025 12:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNfMVkokcKko for <ietf@mail2.ietf.org>; Fri, 29 Aug 2025 12:56:55 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5E6DE5ACEEDC for <ietf@ietf.org>; Fri, 29 Aug 2025 12:56:55 -0700 (PDT)
Received: from dyas.sandelman.ca (unknown [142.169.16.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 9B4B81F50D for <ietf@ietf.org>; Fri, 29 Aug 2025 19:56:54 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 878F5A07C8; Fri, 29 Aug 2025 14:33:58 -0400 (EDT)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 83B61A01E9 for <ietf@ietf.org>; Fri, 29 Aug 2025 14:33:58 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Question about BCP 14 / RFC 8174
In-reply-to: <LV8PR11MB8536396453A3D7E11DE8A48CB53AA@LV8PR11MB8536.namprd11.prod.outlook.com>
References: <aKzK5qdwLUHSa3JL@ubby> <CAC4RtVASn123qUSuFZg50wL4Nrjebz=QMf5AU=jeZLgQd5fsDg@mail.gmail.com> <9953f535-672f-49de-8b8f-9e1a471d97b8@gmail.com> <aLDiRY6Tw7PTKQoy@faui48e.informatik.uni-erlangen.de> <51f521aa-0b66-4f35-a9b1-815cb92a169e@gmail.com> <D739413C0AE13FFFFCB670A2@PSB> <LV8PR11MB8536396453A3D7E11DE8A48CB53AA@LV8PR11MB8536.namprd11.prod.outlook.com>
Comments: In-reply-to "Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org> message dated "Fri, 29 Aug 2025 10:24:24 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; Emacs 29.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 29 Aug 2025 14:33:58 -0400
Message-ID: <270510.1756492438@dyas>
Message-ID-Hash: UBVSNOW3YZE7S3AKNZTMPDY6JQT7CZRX
X-Message-ID-Hash: UBVSNOW3YZE7S3AKNZTMPDY6JQT7CZRX
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/De2oSwXVfYgDp7wZpPzV0wMquZw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

Rob Wilton \(rwilton\) <rwilton=40cisco.com@dmarc.ietf.org> wrote:
    > Picking up on Brian’s prose, arguably writing “MUST xxx UNLESS yyy”,
    > “MUST NOT aaa UNLESS bbb” would be even clearer to readers.  A slightly
    > out-there suggestion could be to update RFC 2119 to remove
    > SHOULD/SHOULD NOT and introduce MUST … UNLESS and MUST NOT … UNLESS as
    > their replacements.

I would support that.

    > That would make specifications more precise and prevent folks from
    > using SHOULD to sit on the fence.

I think that people use SHOULD because MUST feels too emphatic.
It does not feel very polite.
But, it's not an invitation (in Caligraphy) to your great aunt for tea, it's
a technical specification.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.34.0 | Report a Bug | By Email | System Status