Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP
John C Klensin <john-ietf@jck.com> Thu, 02 January 2020 21:49 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 5D0E212004D for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 13:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Level:
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 VpsZPfhYwunD for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 13:49:14 -0800 (PST)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8403120096 for <ietf-smtp@ietf.org>; Thu, 2 Jan 2020 13:49:14 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1in8L7-000IGj-Tn; Thu, 02 Jan 2020 16:49:09 -0500
Date: Thu, 02 Jan 2020 16:49:04 -0500
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, ietf-smtp@ietf.org
Message-ID: <97F17D0555B461EB32F917E9@JcK-HP5.jck.com>
In-Reply-To: <0fc9f066-ecd2-5e8e-e795-c778bc4847e8@network-heretics.com>
References: <20200101175510.8549A11E2905@ary.qy> <D441E0BE-1F32-4329-9296-A5026540E8D0@dukhovni.org> <994e7a23-9e80-4751-6067-8863ad0ee72f@network-heretics.com> <2Iq+URBKeODeFANB@highwayman.com> <5E0E04AA.5070408@isdg.net> <986919d8-613b-7e13-c39b-0f7f978ca763@network-heretics.com> <B7644591809D5C3CBB682F56@JcK-HP5.jck.com> <65a41f13-6a8f-95ef-2a6f-744a4604c546@dcrocker.net> <0fc9f066-ecd2-5e8e-e795-c778bc4847e8@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/ZYhXV3RCEQiglOcWkiubZi0U6k0>
Subject: Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP
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: Thu, 02 Jan 2020 21:49:16 -0000
--On Thursday, 02 January, 2020 14:28 -0500 Keith Moore <moore@network-heretics.com> wrote: >> Failing to obtain some history covering both of these >> questions, pursuing this topic doesn't seem likely to be >> productive, though it could be wonderfully expensive in time >> and frustration. > > Some of us remember these things and the references are > potentially useful to those who do. Are we constrained > to only talk about what we're sure everyone already knows? > I certainly don't want us to have to revisit the entire > history of email in this discussion (and to have to repeat > that discussion every few years), but I assume that people > seriously involved in email are motivated to do that > anyway. So I don't think it's wrong to refer to history, > and I think that sometimes it provides valuable context. > > I doubt that much, if any, historical discussion should be in > the 5321bis spec(s). If someone really feels motivated > there could be an informational document but I wouldn't want > it to be a work item for a WG. Keith (and, to some extent, Dave), I'm not suggesting a historical description. I am suggesting a rationale for any changes we make, one that is persuasive enough to overcome the natural resistance to making changes for anyone (and, where relevant, their management) who thinks they have a system that is working well for them. Otherwise, while a few clarifications (including tracking the errata and issues at a level similar to most of them) may still be in order, it is not clear to me a major revision of 5321 is likely to be a good use of time. As to whether the IETF usually or normally or even sometimes does an authoritative rationale document like I'm suggesting, two examples may help. Many of the "discussion" materials in RFC 1122 and 1123 do precisely what I'm suggesting -- explain why a particular recommendation or requirement is being made in the hope that people will pay attention rather than expecting them to do something different (and "different" is important) just because the IETF said so. And, of course, when IPv6 was adopted, the reasons for the decision, as well as the alternate proposals, were published. Only in part because I don't think it would take much hair-splitting to argue that one or both examples don't apply, consider how many application-level protocols we have that are as old as SMTP and whose basic assumptions or coverage are still being actively reviewed and revised. Telnet is older, but not as heavily used today as it was 20 or 30 years ago, the basic model has not changed in a very long time, and the most recent standards-track extension I can find is the data encryption stuff from 2000. FTP is also older, but, the additional of the HOST command in 2014 (for which I've seen little evidence of wide adoption but may not have been looking in the right places) notwithstanding, no changes to the basic model since RFC 959 (and, if we were to start counting from there, it postdates SMTP). At least IMO and although I can name exceptions, the IETF has almost always done better (in terms of quality and wide adoption) with new protocols, especially ones that fill a vacuum, than with revisions to long-established ones. Maybe that is how it should be but, if we are going to make revisions to widely-deployed protocols, especially revisions that imply that people should (or MUST) do things differently, I think doing something differently than what it is perceived we have "always" done may be entirely appropriate lest people look at our work and paraphrase the comment about doing things the same way multiple times that is attributed to Einstein. Finally, >... > The established terms are actually rather precise and refer to the > networking abstraction, not an implementation. Good luck trying to get everyone to use these or any other terms, in exactly the way you want them to use them, on any particular occasion. As far as I can tell, people use words imprecisely, and to mean slightly different things in different contexts, because it's so often useful or necessary for them to do so. There's nothing new or odd about this. If we are going to treat RFC 5598 and/or the discussions that led up to it as final and normative, or even "as established terms" and therefore align 5321bis (or any subsequent document) with what it says (or appears to say), then let's do what my reading of RFC 2026 requires, which is to put 5321bis aside for a while and issue a 5598bis as a PS or BCP that makes clear which sections or terminology of 5321 it is updating or replacing, then come back to 5321bis. I think a better strategy, and more consistent with IETF practices in which no document is so much the last work on a subject as to make it never subject to future debate or revision, to treat 5588 as useful guidance as we undertake 5321bis but with the understanding that the terminology and models of 5321, 5598, or even something else may ultimately prevail. With that approach, if the answer is not the terminology and model of 5321, then 5321bis should also update whatever is relevant to [re-]achieve consistency, but that should be no big deal. YMMD, of course. best, john
- [ietf-smtp] Possible cont4ibution to moving forwa… John C Klensin
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… John C Klensin
- Re: [ietf-smtp] Possible cont4ibution to moving f… John C Klensin
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Possible cont4ibution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… John C Klensin
- Re: [ietf-smtp] Possible cont4ibution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Possible cont4ibution to moving f… Jeremy Harris
- Re: [ietf-smtp] Possible cont4ibution to moving f… Alessandro Vesely
- Re: [ietf-smtp] Possible contiibution to moving f… John C Klensin
- Re: [ietf-smtp] Possible contiibution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Possible contiibution to moving f… John C Klensin
- Re: [ietf-smtp] Possible contribution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Possible contribution to moving f… John C Klensin
- Re: [ietf-smtp] Possible contribution to moving f… S Moonesamy
- Re: [ietf-smtp] Possible cont4ibution to moving f… Barry Leiba
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… John Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… John Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… John R Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… Laura Atkins
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Laura Atkins
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Laura Atkins
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals John Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… Hector Santos
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- [ietf-smtp] It's not about IP-Literals, its about… Hector Santos
- Re: [ietf-smtp] Endless debate on IP literals John C Klensin
- Re: [ietf-smtp] Endless debate on IP literals John R Levine
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Jeremy Harris
- Re: [ietf-smtp] Endless debate on IP literals John R Levine
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals John R Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… John Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible contribution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Possible contribution to moving f… Keith Moore
- Re: [ietf-smtp] SMTP client certs John Levine
- Re: [ietf-smtp] Endless debate on IP literals John Levine
- Re: [ietf-smtp] Possible contribution to moving f… Richard Clayton
- Re: [ietf-smtp] Possible contribution to moving f… John Levine
- Re: [ietf-smtp] Possible contribution to moving f… Viktor Dukhovni
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Possible contribution to moving f… Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals John R Levine
- Re: [ietf-smtp] Endless debate on IP literals Viktor Dukhovni
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals John Levine
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Possible contribution to moving f… Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals John Levine
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals Viktor Dukhovni
- Re: [ietf-smtp] Endless debate on IP literals Alessandro Vesely
- Re: [ietf-smtp] Possible contribution to moving f… Hector Santos
- Re: [ietf-smtp] Possible contribution to moving f… Hector Santos
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Hector Santos
- Re: [ietf-smtp] Endless debate on IP literals Hector Santos
- Re: [ietf-smtp] Endless debate on IP literals John R Levine
- Re: [ietf-smtp] Possible contribution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Hector Santos
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- Re: [ietf-smtp] Possible contribution to moving f… John C Klensin
- Re: [ietf-smtp] Possible contribution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Arnt Gulbrandsen
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Possible contribution to moving f… Keith Moore
- Re: [ietf-smtp] Possible contribution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible contribution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Possible contribution to moving f… John C Klensin
- Re: [ietf-smtp] Possible contribution to moving f… Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… John Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… John Levine
- Re: [ietf-smtp] Possible contribution to moving f… Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Ned Freed
- Re: [ietf-smtp] Possible cont4ibution to moving f… Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Ned Freed
- Re: [ietf-smtp] Endless debate on IP literals Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- [ietf-smtp] lounging around Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals Keith Moore
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals John R Levine
- Re: [ietf-smtp] Possible cont4ibution to moving f… Keith Moore
- Re: [ietf-smtp] lounging around John Levine
- Re: [ietf-smtp] Endless debate on submission auth… John Levine
- Re: [ietf-smtp] lounging around John Levine
- Re: [ietf-smtp] lounging around Keith Moore
- Re: [ietf-smtp] lounging around Dave Crocker