Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
John C Klensin <john-ietf@jck.com> Sat, 05 June 2021 07:21 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 9A9233A17CA for <ietf-smtp@ietfa.amsl.com>; Sat, 5 Jun 2021 00:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZZ-_2eLDbnbm for <ietf-smtp@ietfa.amsl.com>; Sat, 5 Jun 2021 00:21:11 -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 9B2C13A17C7 for <ietf-smtp@ietf.org>; Sat, 5 Jun 2021 00:21:11 -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 1lpQcH-0003zb-Qh; Sat, 05 Jun 2021 03:21:09 -0400
Date: Sat, 05 Jun 2021 03:21:04 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, ietf-smtp <ietf-smtp@ietf.org>
Message-ID: <C744AD1CDF9E8214916463BB@PSB>
In-Reply-To: <a8e45f33-3678-0a30-cca2-7f12c609e232@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>
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/j7Z8FCTGGBh2xwyiTN_LQie3Klw>
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: Sat, 05 Jun 2021 07:21:17 -0000
--On Friday, June 4, 2021 16:14 -0700 Dave Crocker <dhc@dcrocker.net> wrote: > On 6/4/2021 3:21 PM, John C Klensin wrote: >> Would the EAI WG have made >> different decisions in some cases had there been full >> understanding of what we know now, including what and how >> people would choose to implement? > > > No doubt you are right. We didn't have much experience yet, > with operational enhancement efforts such as ESMTP, RFC2822, > MIME, DNSSec, DKIM, or much else. > > >> Otherwise, please explain how additional discussions of the >> wording of the specs -- perhaps as distinguished from sharing >> implementation experience and perspectives -- are helpful. > > The current concern I saw is with field experience > demonstrating that SHOULD is out of sync, with the obvious > suggestion that it be changed. > > You appear to be asking how it would be helpful to have the > specification reflect extensive field experience. But maybe > not? No. I am asking a much more pragmatic question or pair of questions: (i) whether making a change in this area (see below) is worth, at this particular point, opening up RFC 6531 and/or 6532 (and reviewing whether other documents in the SMTPUTF8 collection to see if they need similar adjustments) would be worth the trouble and (ii) whether there is the energy to do that and to do it well. I think it is particularly important to ask the second question because the apparently underwhelming speed at which EMAILCORE is converging on 5321bis and 5322bis does not support the hypothesis that there is a lot of energy to do work like this and because there are i18n issues associated with what the right solutions might be and there appears to be even less energy in the IETF for that kind of work. And, finally, while I am personally convinced, at least at this moment, that changes to the relevant text would be appropriate if we had the collective time and energy, it is much less clear to me that swapping MAY for SHOULD is the correct change to make. If, in the long term and when SMTPUTF8 is ubiquitous, U-labels were really the better answer for this case, then the test ought to explain why that is the right target even while explaining why A-labels may be appropriate during the transition period (however long that lasts). Simply saying "everyone who has spoken up about implementations is using A-labels" is actually not a sufficient reason to change the spec. And I again note that the people who were represented in the WG with the strongest perceived need for non-ASCII email addresses do not appear to be represented on this list. Making a decision without them having the ability to be consulted would seem to me to be profoundly unfair and unreasonable. john changing, e.g., SHOULD to MAY (if that were to be the right solution)
- [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