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

John C Klensin <john-ietf@jck.com> Sun, 06 June 2021 17:22 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050403A2220 for <ietf-smtp@ietfa.amsl.com>; Sun, 6 Jun 2021 10:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNl_IH3bXXPI for <ietf-smtp@ietfa.amsl.com>; Sun, 6 Jun 2021 10:22:34 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D593A221C for <ietf-smtp@ietf.org>; Sun, 6 Jun 2021 10:22:34 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lpwTl-0009Yr-QI; Sun, 06 Jun 2021 13:22:29 -0400
Date: Sun, 06 Jun 2021 13:22:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Alessandro Vesely <vesely@tana.it>, ietf-smtp@ietf.org
Message-ID: <E863AF380A69FAD9C7CFBEB2@PSB>
In-Reply-To: <ee0cb9b3-f56f-a94d-6d1f-4e9d49c849c0@dcrocker.net>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <2021052700585304660213@cnnic.cn> <YK7E1dBKneP8B8Ib@straasha.imrryr.org> <01RZNI90M6SS0085YQ@mauve.mrochek.com> <E23639ADA7487360C9B5A93C@PSB> <01RZPUQVP8TU0085YQ@mauve.mrochek.com> <e9a6ce3e-3f83-a221-d132-fd021a2b5002@dcrocker.net> <F7279E1A825BAAA33F28BA85@PSB> <a8e45f33-3678-0a30-cca2-7f12c609e232@dcrocker.net> <C744AD1CDF9E8214916463BB@PSB> <61d523d4-7941-a506-639e-b2fb558e1bd4@dcrocker.net> <196A7A6D696C799266EC7F8F@PSB> <7289f66e-64c3-563d-af5f-7146bc7f5c14@tana.it> <ee0cb9b3-f56f-a94d-6d1f-4e9d49c849c0@dcrocker.net>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/DBKGmFZ994krhT9P8GVJmZF3TeY>
Subject: Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
X-BeenThere: ietf-smtp@ietf.org
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\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Jun 2021 17:22:39 -0000


--On Sunday, June 6, 2021 10:00 -0700 Dave Crocker
<dhc@dcrocker.net> wrote:

> On 6/6/2021 9:56 AM, Alessandro Vesely wrote:
>> On Sat 05/Jun/2021 20:14:28 +0200 John C Klensin wrote:
>>> (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.
>> 
>> How about an erratum?
> 
> Unfortunately, the administrative rule on RFC errata is that
> they are limited to corrections where what is written does not
> match what was intended.  That is, documentation errors,
> rather than -- such as here -- revised goals.

Agreed.  In addition to Dave's point and going beyond
"administrative rule", the problem is that there is not even a
pretense that errata represent IETF consensus.   So, even if the
WG messed up and the goals need revision, errata don't work
except in one very narrow way.   That would be to submit this as
an erratum and then try to get the powers-that-be to identify it
as "hold for document update" rather than rejecting it outright.
That would provide a very clear signpost that any future
revision of the SMTPUTF8 specifications should (SHOULD?) either
consider the issue or be prepared to explain why not.

> But, yeah.  The way to address a modest change is with a
> modest effort.

And I await a description --other than the errata signpost idea
mentioned above-- as to how to make a change in this area with a
modest effort, presumably one about which IETF consensus can be
asserted but that does not require an I-D, notification of (and
discussion including) as many of those who participated in the
EAI effort as were still interested, IETF Last Call, etc.

A different way of saying the same thing is that, if this change
is not important enough to establish IETF consensus about making
it, it is not a "modest change" but a change that is not worth
the trouble at this point.

    john