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
- [ietf-smtp] Should we update an RFC if people ref… John R. Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… Jiankang Yao
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni
- Re: [ietf-smtp] Should we update an RFC if people… Ned Freed
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Ned Freed
- Re: [ietf-smtp] Should we update an RFC if people… Alessandro Vesely
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… Sam Varshavchik
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Alessandro Vesely
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… Valdis Kl ē tnieks
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni