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