Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF

Keith Moore <> Thu, 23 July 2020 04:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9E623A0C24 for <>; Wed, 22 Jul 2020 21:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HYwG5xMb2NF4 for <>; Wed, 22 Jul 2020 21:14:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A5113A091D for <>; Wed, 22 Jul 2020 21:14:29 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 9A4115C004A for <>; Thu, 23 Jul 2020 00:14:28 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Thu, 23 Jul 2020 00:14:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Qbo7rzFtnetNFfx7mzJpzLL9vx6V6Gd43VMzhn0Ca 9E=; b=Nwa44qjfmUbYYmSpCU66Mi+1FyK9aRubRjvPU1d4qCZuHZbam4F6ecu2J 05G4CJ9sCqEE+dAGHstB//EusgjWJofH4y0rnor3CsiIPiDkRoIRH1im4VOQj2I1 E2WlUgnYAV5xHyQUNUM4R38ssNXXtu8Wjhwn9EZ2A4ElmcvEcY/9tS5IG4CJGwZd rMJ61N4wYyyA6I+nsIPrigrd/LeeNm0+12cSXnjdbbfNMujBEzqfMeA/C7BBiEfZ mDuXbNqFXJQ623hN17VBOOcFzkpvUb9BzPpwkcAda+gZK1PAh5rGTTQdhrozmMMM qAK++Z0jTAaXDTisl1lIEF2OTCAvg==
X-ME-Sender: <xms:pA4ZXy9d-dU2j4QDsVIDKoKBO6mmgy7snP7EDhLu4iwE1_Zc0-01-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedtgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedtheefgf efgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:pA4ZXysDLxZOv8u7NysvuR6x_o3M7PJ_i7S36gEPBxk_5_c8ahs-_Q> <xmx:pA4ZX4BT4dsoJWmcpv-brDQaA9SAbOVOQgEJjA3NRnD6z8ivWLl68w> <xmx:pA4ZX6f52E6iMj_3SAlUcaMYtQqYRa85F9ck-_i1ZLh3aYeyIC57Sg> <xmx:pA4ZX5sjYYXdgUIOPY_kCvRxis1ZNJUG9wgNUh8-JaUylbjclbZVzQ>
Received: from [] ( []) by (Postfix) with ESMTPA id EAB1030600A3 for <>; Thu, 23 Jul 2020 00:14:27 -0400 (EDT)
References: <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Thu, 23 Jul 2020 00:14:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jul 2020 04:14:31 -0000

I would like it to be clarified as to whether the purpose of the BOF is 
to bash the charter for the proposed EMAILCORE WG.

If the purpose of the EMAILCORE WG is indeed to bring the current 
message format and SMTP specifications to Full Standard, I further 
propose that any features not in those specifications should be 
out-of-scope for the WG, unless perhaps any new features are (a) already 
at Proposed Standard; (b) widely implemented enough to also be 
considered for Full Standard; and (c) necessary for inclusion in the 
core specifications in order for the complete set of revised 
specifications (core + new features) to qualify for Full Standard.

(I suppose if someone wants to make a case that the core email 
specifications are not suitable for advancement to Full Standard but 
instead should be recycled at Proposed, while the charter is being 
bashed would also be the time to make that argument.)

I would therefore propose that any features that don't meet those 
criteria either be ruled out-of-scope for the BOF, at least deferred 
until the WG charter has been bashed.   Perhaps if there's time 
remaining it would make sense to use that time to discuss features that 
couldn't be taken up by the working group.

What I don't think makes any sense at all, at least given the current 
IETF standards process, is to combine a discussion of adding new 
features, with a discussion of advancement to Full Standard.