Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
John C Klensin <john-ietf@jck.com> Tue, 25 May 2021 02:32 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 719723A0BD7 for <ietf-smtp@ietfa.amsl.com>; Mon, 24 May 2021 19:32:11 -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 wiyIAXVgGH4q for <ietf-smtp@ietfa.amsl.com>; Mon, 24 May 2021 19:32:07 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 0DB2C3A0AB6 for <ietf-smtp@ietf.org>; Mon, 24 May 2021 19:32:06 -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 1llMrV-000LL9-HF; Mon, 24 May 2021 22:32:05 -0400
Date: Mon, 24 May 2021 22:31:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: "John R. Levine" <johnl@iecc.com>
cc: ietf-smtp@ietf.org
Message-ID: <4ED5FF03CF3B91767AD87B8A@PSB>
In-Reply-To: <dde03886-a735-b52e-5cc2-3f9df96ef7a6@iecc.com>
References: <dde03886-a735-b52e-5cc2-3f9df96ef7a6@iecc.com>
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/GowOmauL4u2Z5GcS0UZDWFOl5f8>
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: Tue, 25 May 2021 02:32:12 -0000
It would certainly be appropriate to either revise the spec or, better from my point of view, create a short applicability statement that explains the reasoning behind the SHOULD and the circumstances under which it would be sensible to ignore it. The thing that sometimes gets lost in "let's make the spec conform to what implementations are doing" discussions in this area is that there is an assumption behind the whole collection of SMTPUTF8 specs, namely that the world really wanted non-ASCII addressing and header field values. If that were true and things had gone as quickly as the advocates predicted, then your argument would not hold because the odds of the downstream system in the scenario you describe not having support for the extension would be low. If we are merely being slower than expected getting there, then advising people to do something that is sub-optimal for other reasons is a bad idea because it is likely to just slow things down further. Now, if, on the other hand, the reality were that no one is going to fully implement SMTPUTF8 other than mail providers in a few countries that intend to use it internally, then we should probably be reconsidering the whole model --not just this detail-- lest we end up with two mail systems and needing gateways, possibly even gateways with serious downgrade and/or encapsulation facilities between them. Just my personal opinion, of course. john --On Monday, May 24, 2021 19:05 -0400 "John R. Levine" <johnl@iecc.com> wrote: > I've been doing some EAI tests. RFC 6531 section 3.7.3 says > that domain names in trace headers SHOULD all be U-labels. In > practice, everyone uses A-labels for reasons that are not > absurd. The FROM clause has the name from the EHLO command > which has to be sent as A-labels, and it's quite plausible to > have a message where the message itself is entirely ASCII, > sent to a UTF-8 address, which then could be forwarded to an > ASCII address except that it has those U-labels in the trace > header which would have to be downgraded. I've talked to a > couple of MTA maintainers who have told me forget it, that's > silly, not doing that. > > In a situation like this, would it make sense in a future > update to the RFC to adjust the advice to the reality?
- [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