Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
John C Klensin <john-ietf@jck.com> Fri, 04 June 2021 22:45 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 B298D3A2427 for <ietf-smtp@ietfa.amsl.com>; Fri, 4 Jun 2021 15:45:27 -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 2M7SgtArpI_7 for <ietf-smtp@ietfa.amsl.com>; Fri, 4 Jun 2021 15:45:23 -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 41B7A3A2404 for <ietf-smtp@ietf.org>; Fri, 4 Jun 2021 15:45:23 -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 1lpIZ5-0002eU-KP; Fri, 04 Jun 2021 18:45:19 -0400
Date: Fri, 04 Jun 2021 18:45:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Sam Varshavchik <mrsam@courier-mta.com>, ietf-smtp <ietf-smtp@ietf.org>
Message-ID: <203173C2C0E54D8CB90AC3B8@PSB>
In-Reply-To: <c3651aba-db32-614c-c89c-0dab91a9faf4@dcrocker.net>
References: <2021052700585304660213@cnnic.cn> <YK7E1dBKneP8B8Ib@straasha.imrryr.org> <01RZNI90M6SS0085YQ@mauve.mrochek.com> <E23639ADA7487360C9B5A93C@PSB> <01RZPUQVP8TU0085YQ@mauve.mrochek.com> <e9a6ce3e-3f83-a221-d132-fd021a2b5002@dcrocker.net> <cone.1622844380.436481.31038.1004@monster.email-scan.com> <c3651aba-db32-614c-c89c-0dab91a9faf4@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/tr6qPgp6PO3_uYP8BtOGzimatCc>
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: Fri, 04 Jun 2021 22:45:35 -0000
--On Friday, June 4, 2021 15:14 -0700 Dave Crocker <dhc@dcrocker.net> wrote: > On 6/4/2021 3:06 PM, Sam Varshavchik wrote: >> The current preference is for A-labels. But after SMTPUTF8 >> becomes customary: at some point it will make sense to >> interpret SHOULD using its original meaning, here. > > One of the consistent demonstrates of Internet Scale is that > transition times are /really/ long. But that was another very explicit decision of the WG: to focus on when, as Sam puts it, SMTPUTF8 becomes customary and then try to accelerate the rate of adoption. That was, in particular, rather than trying to invent horrible kludges that we would then want to transition away from, facing exactly the problem you identify, a problem that normally gets even worse when those kludges that "everyone" has adopted mostly work. If one views the desire to get a fast transition from a really extreme direction (and I'm trying to summarize some of the perspective of WG participants, not advocate for it), then "what happens when a message gets partway across the Internet and then hits a system that does not support the extension?" is very nearly a feature, as in "let the users complain until the relevant system is upgraded" and/or "encourage destination system that do not support the extension to avoid advertising MX intermediaries until the whole chain is upgraded". And, again, if we conclude that expectation was either unrealistic or just a bad idea, well hindsight is great, isn't it? One other decision we didn't make is worth remembering. That decision would have been to keep mailbox names in ASCII (using U-labels in the domain part if needed but following 2891/5321 and 2892/5322 strictly wrt the local part). No changes to trace fields, no complications with header-signing protocols, etc. Instead, we would just put more emphasis on name phrases in header fields, using encoded words if needed, and _maybe_ creating a small SMTP extension to allow carrying those phrases into the envelope as parameters to MAIL and RCPT. That was, perhaps for good reason, completely unacceptable to those who thought they needed non-ASCII local parts and probably unacceptable to everyone in the relevant countries who like using email addresses as identifiers. But, if we wanted to concentrate on easy and smooth extensibility and ignore those use needs, a good exercise in second-guessing the WG's decision might yield that sort of result. And, btw, while we were at it, we could decide to second-guess all of those email address as personal identifier ideas. :-( best, john with reference to my prior note
- [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