Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?

John C Klensin <> Sat, 05 June 2021 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78B3B3A2B2B for <>; Sat, 5 Jun 2021 11:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vvif0zD9MID5 for <>; Sat, 5 Jun 2021 11:14:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 098FB3A2B2A for <>; Sat, 5 Jun 2021 11:14:35 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lpaoc-0005X5-50; Sat, 05 Jun 2021 14:14:34 -0400
Date: Sat, 05 Jun 2021 14:14:28 -0400
From: John C Klensin <>
To:, ietf-smtp <>
Message-ID: <196A7A6D696C799266EC7F8F@PSB>
In-Reply-To: <>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <> <> <> <E23639ADA7487360C9B5A93C@PSB> <> <> <F7279E1A825BAAA33F28BA85@PSB> <> <C744AD1CDF9E8214916463BB@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Jun 2021 18:14:41 -0000

--On Saturday, June 5, 2021 09:21 -0700 Dave Crocker
<> wrote:

> At any rate, it appears that you are suggesting expanding the
> proposed, very simple, very narrow, very pragmatic and
> entirely experience-based proposal into a larger and more
> generic activity.
> While the latter might be worth considering, there is nothing
> about the current issue that requires coupling it to the
> larger task.

Except that 

(1) Your "very simple, very narrow, very pragmatic, and entirely
experience-based proposal" may also be very wrong.  I don't
personally think it is, but I believe that deciding to make that
change by, e.g., the discussions on this list in the last few
days, would be inappropriate because it gives little or no voice
to those who have the strongest interest in in a fully
internationalized email system.    And no matter how often you
insist that your proposal is a very simple and pragmatic change
--presumably with no side effects--  will alter that exclusion
and the possibility those people identifying long-term side
effects we have not identified.

(2) At the risk of being even more pragmatic about your "very
pragmatic" proposal, I know of no way to make an authoritative
change in a standards track RFC -- whether one word or a few
paragraphs -- without generating an I-D, having it discussed in
the community, going through IETF Last Call, and publishing a
new RFC.    That is not a lightweight process even if the change
is "very simple and very narrow".  It seems to me that asking
the question of whether, given limited resources and energy and
other priorities, it is worth doing... and reaching a tentative
"no" conclusion.  John Levine's recent note suggests to me that
this issue is not a big problem and that, if we are inclined to
put more energy into the SMTPUTF8 collection, those resources
are better spent elsewhere.