[Emailcore] Two extra issues

John C Klensin <john-ietf@jck.com> Thu, 17 December 2020 05:03 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BE73A1450 for <emailcore@ietfa.amsl.com>; Wed, 16 Dec 2020 21:03:01 -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 ewgRr4sRuUi0 for <emailcore@ietfa.amsl.com>; Wed, 16 Dec 2020 21:03:00 -0800 (PST)
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 7CEC33A144D for <emailcore@ietf.org>; Wed, 16 Dec 2020 21:03:00 -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 1kplRL-000JYh-AD for emailcore@ietf.org; Thu, 17 Dec 2020 00:02:59 -0500
Date: Thu, 17 Dec 2020 00:02:54 -0500
From: John C Klensin <john-ietf@jck.com>
To: emailcore@ietf.org
Message-ID: <9ABCA62E3E54C4356D09E1EE@PSB>
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/emailcore/Zn9T42eVMbqZUtgYU2Ou6UQ4TjA>
Subject: [Emailcore] Two extra issues
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 05:03:02 -0000

Hi.

As mentioned in my note about ticket #2 sent about an hour ago,
two additional issues came to my attention (or I was reminded
about them) while looking at that issue and looking through the
document.  

I've put them into the working version of what will become
draft-ietf-emailcore-rfc5321bis-01 as:

       ----

 G.12.  Extension Keywords Starting in 'X-'

   Section 2.2.2 contains a discussion of SMTP keywords starting
in "X".
   Given general experience with such things and RFC 6648, is
there any
   reason to not deprecate that practice entirely and remove
that text?
   If we do so, should Section 4.1.5 be dropped or rewritten to
make
   clear this is an obsolete practice?

 G.13.  Deprecating HELO

   RFC 5321 (and 2821 before it) very carefully circle around
the status
   of HELO, even recommending its use as a fallback when EHLO is
sent
   and a "command not recognized" response is received.  We are
just a
   few months short of 20 years; is it time to deprecate the
thing and
   clean out some or all of that text?  And, given a recent
(4Q2020)
   discussion on the EMAILCORE list, should EHLO be explicitly
bound to
   SMTP over TCP with the older transports allowed only with
HELO?
   While those questions may seem independent, separating them
is fairly
   hard given the way the text is now constructed.

Two more things...

(1) I think I've figured out how to overlay the ticket numbers
from https://trac.ietf.org/trac/emailcore/report/1 onto the
relevant lists in 5321bis where they are applicable, so the
request for someone to build a table for me is withdrawn -- they
will be in the next version.

(2) I await guidance from the WG Chairs as to when to post a new
version.  My personal preference would be to wait until we have
at least a few more tickets resolved, but up to them (and the
WG).

   john