Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission

John C Klensin <john-ietf@jck.com> Mon, 26 July 2021 00:41 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 C2B863A081F for <emailcore@ietfa.amsl.com>; Sun, 25 Jul 2021 17:41: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 tozmaOZDWlrb for <emailcore@ietfa.amsl.com>; Sun, 25 Jul 2021 17:41:07 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D463A0812 for <emailcore@ietf.org>; Sun, 25 Jul 2021 17:41:07 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1m7ofR-000IU9-MT; Sun, 25 Jul 2021 20:40:25 -0400
Date: Sun, 25 Jul 2021 20:40:05 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net
cc: emailcore@ietf.org
Message-ID: <B2688FD2D5BE8DCE0038A939@JcK-HP5>
In-Reply-To: <daf7b953-2bb0-ec3d-935c-52142e3fb910@dcrocker.net>
References: <e64e5ab8-fe18-7708-f8bf-6c5ee60658b6@isode.com> <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> <C371882359676271873A6904@JcK-HP5> <daf7b953-2bb0-ec3d-935c-52142e3fb910@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
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/lL2zCH9wPDwgtZ3H_blNYVT3HeI>
Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission
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: Mon, 26 Jul 2021 00:41:12 -0000


--On Sunday, 25 July, 2021 16:42 -0700 Dave Crocker
<dhc@dcrocker.net> wrote:

> On 7/25/2021 4:30 PM, John C Klensin wrote:
>> Personal opinion and opinion as co-author of RFC 6409: Much of
>> the reason for creating a separate Message Submission
>> specification was to make it clear that the MSA was allowed to
>> do things that, in a more abstract world, we expected MUAs to
>> do and discouraged MTAs from doing.  In other words, the
>> boundary between MUA and SMA is deliberately unclear; the MUA
>> could incorporate MSA functions (or not) or could communicate
>> with the MSA using just about whatever protocol or API the
>> two agreed on, etc.
> 
> 
> You appear to be saying that Sections 4.2.1 and 4.3.1 of RFC
> 5598 are not sufficiently clear or complete.
> 
> Please elaborate with particulars.

I am saying that RFC 5598 is an Informational document, perhaps
in part because some of its sections could not get consensus.
If you want to propose to some appropriate AD that it be put out
for Last Call to move it to Proposed Standard or BCP, or
recommend chartering a WG for the purpose (or assigning it to an
existing AD), by all means go for it.

Or you could convince the WG to tell me to go ahead and create a
normative reference to 5598 5598 to and use the exception
procedure, but I imagine some of us would argue that would be
tantamount to moving standards track and hence out of charter.

   john

> 
> d/