Re: [ietf-smtp] Email standard revision

John C Klensin <john-ietf@jck.com> Tue, 18 February 2020 19:26 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 08C75120145 for <ietf-smtp@ietfa.amsl.com>; Tue, 18 Feb 2020 11:26:24 -0800 (PST)
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 AoHQgF2pGL9Y for <ietf-smtp@ietfa.amsl.com>; Tue, 18 Feb 2020 11:26:22 -0800 (PST)
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 8152B12016E for <ietf-smtp@ietf.org>; Tue, 18 Feb 2020 11:26:22 -0800 (PST)
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 1j48Vh-000FCY-5R; Tue, 18 Feb 2020 14:26:21 -0500
Date: Tue, 18 Feb 2020 14:26:15 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alessandro Vesely <vesely@tana.it>
cc: ietf-smtp@ietf.org
Message-ID: <118BA897BE380DA6BCE22C4C@PSB>
In-Reply-To: <9a9e42da-5754-858c-5571-2505f0a0d057@tana.it>
References: <CAOEezJTLEzpDUivS50xUvQtQbNNyJXVKk29Q=c4QRaxgRvTxBw@mail.gmail.com> <972BC556117E20BE16D62E29@PSB> <7c7bd9e2-ffc8-c307-898a-2c827c72695f@tana.it> <eb8a1c75-294b-6deb-3bb2-68ac723543d5@dcrocker.net> <9a9e42da-5754-858c-5571-2505f0a0d057@tana.it>
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
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/ja4-Huur_e-q4m0yyTDIXwvcYRI>
Subject: Re: [ietf-smtp] Email standard revision
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, 18 Feb 2020 19:26:24 -0000


--On Tuesday, February 18, 2020 19:08 +0100 Alessandro Vesely
<vesely@tana.it> wrote:

>...
>  I don't think a cleanup, like e.g. the one you proposed[*],
> would revert rfc5321bis to proposed standard.  However, I'm
> not clear on how that works.  Certainly, rfc2821 was reverted
> to proposed standard, but I wasn't there and I don't know
> who/how decided to label that I-D to a lower standard.
> 
> BCP 9 is not so precise:
>...

At the time, there was at least one important issue and it was
independent of the BCP 9 text you cited.  2821 was essentially a
merge of RFCs
  821 (a full standard)
  974 (don't remember its status at the time 2821 was in
progress, but note that it is listed as part of STD 10, so I
assume full standar)
  some text from 1123 (another full standard)
  1829 (another full standard)
  and bits and pieces of text, some of it completely new, either
picked up from assorted places or inserted to better align 2821
with 2822 than 821 and 822 were aligned.

That new text, and the merger itself, were, in principle and
maybe in practice, untested for how they would work in terms of
comprehension, implementations, and deployment in the future.
Hence PS.  Could we have pushed it through as full standard?
Maybe.  But the experience of the changes that needed to be made
to get to 5321 (virtually all of which were "cleanup") suggests
that would have been a bad decision.
  
> Since there are quite some issues to be clarified[†], I
> think the new WG will need some detailed guidelines about what
> would be a very significant change.

Yes.  See my earlier note.  And, again, I'm skeptical that can
actually be done by guidelines rather that a case-by-case review.

    best,
     john