Re: [ietf-smtp] How wrong is this EAI implementation
John C Klensin <john-ietf@jck.com> Tue, 23 June 2020 23:17 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 79F1D3A0C07 for <ietf-smtp@ietfa.amsl.com>; Tue, 23 Jun 2020 16:17:06 -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 8gWMSch7xLv7 for <ietf-smtp@ietfa.amsl.com>; Tue, 23 Jun 2020 16:17:04 -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 824343A0C2D for <ietf-smtp@ietf.org>; Tue, 23 Jun 2020 16:17:04 -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 1jns9y-000GCV-R3; Tue, 23 Jun 2020 19:16:58 -0400
Date: Tue, 23 Jun 2020 19:16:52 -0400
From: John C Klensin <john-ietf@jck.com>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, John Levine <johnl@taugh.com>
cc: ietf-smtp@ietf.org
Message-ID: <4B400734391D5DC6CD7FBBB2@PSB>
In-Reply-To: <156f485a-e927-4e0e-95e9-2aa5d21c5c2e@gulbrandsen.priv.no>
References: <alpine.OSX.2.22.407.2006201429080.28792@ary.qy> <2B0EB3A9E99431F86620038A@[10.1.10.18]> <alpine.OSX.2.22.407.2006201823060.29484@ary.qy> <DC26ED76E7E316714AB2B820@[10.1.10.18]> <a058a5bf-487e-63ca-70bd-4e2765d3b9b9@network-heretics.com> <alpine.OSX.2.22.407.2006201429080.28792@ary.qy> <2B0EB3A9E99431F86620038A@[10.1.10.18]> <alpine.OSX.2.22.407.2006201823060.29484@ary.qy> <DC26ED76E7E316714AB2B820@[10.1.10.18]> <a058a5bf-487e-63ca-70bd-4e2765d3b9b9@network-heretics.com> <kzlyExy/3YBZVUSNURxDqMLjYwWYAVGpn6yogCjhITg=.sha-256@antelope.email> <20200621145342.7364B1B4460D@ary.qy> <156f485a-e927-4e0e-95e9-2aa5d21c5c2e@gulbrandsen.priv.no>
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/gMsD8Ys5klJLgTg900gmZTa1chM>
Subject: Re: [ietf-smtp] How wrong is this EAI implementation
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: Tue, 23 Jun 2020 23:17:06 -0000
--On Tuesday, June 23, 2020 15:09 +0200 Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote: > On Sunday 21 June 2020 16:53:42 CEST, John Levine wrote: >> I don't think that 5321 requires that bob@example.com and >> bob@EXAMPLE.COM be treated the same, either. >> >> Beyond some point, you can't force people to be reasonable. > > Agree entirely. And this is why I think the EAI specs are too > subtle on this point. > > I do have an opinion about what that point is, and what the > documents ought to say. But my real issue is that it's > possible to review source code against every MUST and SHOULD > in 653x and miss that there's something to consider. In my capacity as the former co-chair of the former WG a few observations while speaking only for myself: * Like so many other i18n efforts in the IETF in recent years, the WG had mostly run out of energy by the time it got those documents out. I don't know if there would be energy and the needed focus to start (and ultimately finish) clarifying documents but other events of the last year or two leave me very doubtful. * There were several important contributors to EAI WG-produced specs who remain on the ima@ietf.org list (although even some of them have move on to other work professionally) but who are not on this one. Absent a move by the relevant ADs (presumably after discussion on both lists) to consolidate them, if one wants to have a serious discussion about SMTPUTF8 ("EAI") issues, those issues should probably be addressed there (instead or in addition). * Just as I think that the "core" RFC 5321/5322 specs and possibly some closely-related work are overdue for an applicability statement that discusses what is common, reasonable, and/or likely to work well in practice independent of what is formally permitted, a similar document would almost certainly be useful about assorted i18n extensions to email. I'd think that, not only should 6530-6533 and 6855-6858 be addressed (including whatever experience we have had that would suggest that one or both of 6857 and 6858 should be revised or deprecated), but that such an effort would want to make clear statements about the relevance of PRECIS to email address local-parts and to discuss and make recommendations about when to use non-ASCII addresses and relevant headers and when to stick to RFC 2231-style encoded words. If anyone thinks it is the right time to do the work and produce that document, and that the IETF would have the energy and will to process it in a timely way, I look forward to an I-D with great anticipation. And, fwiw, I certainly agree that one could do a code review against normative statements and miss that there are issues to consider. best, john
- [ietf-smtp] How wrong is this EAI implementation John R Levine
- Re: [ietf-smtp] How wrong is this EAI implementat… John C Klensin
- Re: [ietf-smtp] How wrong is this EAI implementat… John C Klensin
- Re: [ietf-smtp] How wrong is this EAI implementat… John R Levine
- Re: [ietf-smtp] How wrong is this EAI implementat… Keith Moore
- Re: [ietf-smtp] How wrong is this EAI implementat… John C Klensin
- Re: [ietf-smtp] How wrong is this EAI implementat… Arnt Gulbrandsen
- Re: [ietf-smtp] How wrong is this EAI implementat… John Levine
- Re: [ietf-smtp] How wrong is this EAI implementat… Ned Freed
- Re: [ietf-smtp] How wrong is this EAI implementat… Arnt Gulbrandsen
- Re: [ietf-smtp] How wrong is this EAI implementat… John C Klensin