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:22 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 E2CD13A2345 for <ietf-smtp@ietfa.amsl.com>; Fri, 4 Jun 2021 15:22:11 -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 4C9vbDRu_6eJ for <ietf-smtp@ietfa.amsl.com>; Fri, 4 Jun 2021 15:22:06 -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 08B5E3A2344 for <ietf-smtp@ietf.org>; Fri, 4 Jun 2021 15:22:05 -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 1lpICa-0002ah-I9; Fri, 04 Jun 2021 18:22:04 -0400
Date: Fri, 04 Jun 2021 18:21:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, ietf-smtp <ietf-smtp@ietf.org>
Message-ID: <F7279E1A825BAAA33F28BA85@PSB>
In-Reply-To: <e9a6ce3e-3f83-a221-d132-fd021a2b5002@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>
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/wpBv8eOhrzLYm5HLZzadPQ0v3qc>
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:22:12 -0000
Dave (and others), There are old sayings, at least when and where I was growing up, about hindsight being almost perfect and far easier and more accurate that looking ahead. 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? I'd like to think so for some cases, but there is no way that any of can be sure now. Were these issues and options, including what forms should appear in "Received:" fields, considered by the WG? As Jiankang has indicated, yes. Were they considered carefully enough, and the tradeoffs analyzed adequately, given what we knew then? Well, it seemed so at the time. I can tell you a few things that I remember very clearly: (1) The active participants in the WG included significantly more people whose interest and expertise was in i18n matters despite some knowledge of Internet email than people with a really strong background in Internet email and some background in the i18n issues. That made me, as WG co-chair, uncomfortable. I assume it made my co-chair Joseph and our predecessors Harald and Xiaodong uncomfortable too but don't ever remember discussing it with them. Could we do anything about it? No. I have often wished that, when a WG was proposed, we could explicitly identify the expertise and balance of perspectives needed, write it into the charter, decline to start the WG is those conditions could not be met and shut it down immediately if they were never met. Profoundly unrealistic and I'd probably also like a pony, but an idea that, if we are going to talk about informed consensus, has some theoretical appeal. (2) No one in the WG and no one during IETF Last Call raised the question of whether the choice of U-labels in "Received:" fields was appropriate. If what became RFC 6531 were under active consideration today and that issue were raised with the conclusions or arguments you and others are reaching now, I think that appropriate WG response (and certainly the response from the co-chairs) would have been "even though we would have preferred it earlier, good catch and that was probably not discussed sufficient". But it is not in that state. Instead, it is a Proposed Standard published more than eleven years ago and the issue is coming up only now. Isn't hindsight great? (3) By contrast, the idea of using an overlay or special encoding as you suggest was extensively discussed in the WG (long before I became co-chair). That discussion was, for better or worse, dominated by questions of what to do about the local part in mailbox names. While it was obvious how to encode IDN labels using something like Base64 and later, once the problems with that were understood, Punycode encoding, it was critical to that idea that RFC 1034 specified a very restrictive syntax while allowing almost any octet string of reasonable length as a label and that we could scan a significant portion of the DNS to find out what was actually being used. For mailbox local parts, we had the related problems of (i) email addresses being used to convey all sorts of strange information including system commands and instruction sequences, hashes as part of addresses, and a wide variety of indicators about what was going on and (ii) the combination of extremely permissive syntax rules (dating, you will recall, to before RFCs 822 and 821). The WG concluded that the only possibilities were to make a semi-arbitrary choice of encoding indicators and accept the notion that any existing addresses that were broken in the process were just causalities of progress and to give up on encoding. It also concluded, for reasons entirely consistent with ones you have made in the past even more forcefully than I have, that the "some breakage is ok" option was unacceptable. I don't think we would change that even in hindsight. The conclusion was then to specify U-labels in addresses and even isolated domain names with the one exception of the initial "220" greeting and the EHLO command, neither of which could use non-ASCII forms because the extension had not been negotiated yet. Should that have been parsed out more carefully on a case-by-case basis? Maybe. Isn't hindsight fun? And isn't second-guessing even more so? (4) One of the consequences of the composition and focus of the EAI WG is that many of those who actively participated, including some document authors and probably past co-chairs, are not represented on this list. Whatever else we do, I think it would be unfair and improper for us to make decisions without reaching out to those people and giving them an opportunity to be involved. In particular, it is possible that their view of some of the tradeoffs might be different from that of most of the people on this (more email-oriented) list. Finally, let me say again, more strongly, that discussions here, perhaps especially those that involve second-guessing or applying hindsight to decisions made more than a decade ago, are not getting us anywhere. Suggestions about whether a sentence written before 2005 should have said "SHOULD" or "MAY" appear to be even less useful. If someone wants to propose a WG to reopen old questions and revise the SMTPFUT8 specs, by all means go for it but please try to be sure that the perspectives that were represented in the EAI WG are represented again. Or, if someone wants to propose taking some or all of the SMTPUTF8 specs to Internet Standard, please do the needed reports and get that process started: we could certainly reduce a SHOULD to a MAY and/or add supplemental text as part of that process. Otherwise, please explain how additional discussions of the wording of the specs -- perhaps as distinguished from sharing implementation experience and perspectives -- are helpful. best, john --On Friday, June 4, 2021 10:12 -0700 Dave Crocker <dhc@dcrocker.net> wrote: > >> But in the bigger picture, every time you use a U-label or a >> UTF-8 local-part, you make it more difficult to deal with the >> case when you hit a point where the SMTPUTF8 extension isn't >> available. >> >> We have two downgrading options defined, but neither of them >> is terribly attractive. >> >> What this argues for is to eliminate as much use of the >> extension as you possibly can. And if that means using >> A-labels, or even dropping the use of "for" clauses - which >> are optional anyhow - so be it. > > > If I've read this thread correct, the main argument for the > original SHOULD was convenient display to (end) users. While > that's a laudable goal, it's quite different from a typical > protocol mandate to achieve interoperability. > > Further, it appears that implementers have chosen to widely > ignore the SHOULD, in favor of A-labels. Again, this does not > hurt interoperability, but makes reading by /some/ humans more > challenging, though not impossible. Even further, it appears > that A-labels work well for some other readers. > > My impression is that the SHOULD represented idealism over > simple pragmatism. > > The basic work was to extend an existing service to support a > wider range of characters. With some consistency, that kind > of task fares much better with an overlay solution. (Think > MIME.) A-labels are an overlay. U-labels are not. > > If the operational industry has voted with its code and > clearly prefers A-labels, than the SHOULD is an especially > counter-productive choice, since it creates debate about the > specification where, really, it has no benefit. I suspect MAY > is the better choice. It gives permission and even implicit > encouragement, but eliminates the standards tension caused by > not using U-labels. > > d/
- [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