Re: [Emailcore] Publication has been requested for draft-ietf-emailcore-rfc5322bis-10

"Murray S. Kucherawy" <superuser@gmail.com> Tue, 19 March 2024 04:50 UTC

Return-Path: <superuser@gmail.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 3D338C14F686 for <emailcore@ietfa.amsl.com>; Mon, 18 Mar 2024 21:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQwXzbk7KpvJ for <emailcore@ietfa.amsl.com>; Mon, 18 Mar 2024 21:50:47 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8D5C1654F2 for <emailcore@ietf.org>; Mon, 18 Mar 2024 21:50:06 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-565c4d0fa48so2110894a12.1 for <emailcore@ietf.org>; Mon, 18 Mar 2024 21:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710823804; x=1711428604; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=eK96wnx+Ovyeymj65+iS/BhVQJb/bCst1EICr6y3ZJ0=; b=Lw3Z18lId2z59Lwg4p6XeJTFSRScN0h4YPk1bpWWFM/hVPG0lEBYa/SlIDSLRhETr5 4yOQUQ19xYzOmmYvhgKw+iRZpoXSLTG3JwOdTc3gEvFKJTMC9aUnEyWGsM0OL3tBbAHH EFczDY+wt24kMtf9Iat0SrTUcO2KdMHk+hOO8qJaKQReQ+r7uGh3bRteRSEiJd+Z+Bc8 5Qg9QdcROIUbegtP/14QZH4DJfUdlejJaPKhowbri0/xm/aQ6GfP1TgWM5uyh7FXDt9x ExGT1NhH0t2O9hZywtyyyw1WHM4sIRUs8Vm7Ajl0ouH/FXGb801O42oKTPFTRfZMT8lD PU1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710823804; x=1711428604; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eK96wnx+Ovyeymj65+iS/BhVQJb/bCst1EICr6y3ZJ0=; b=odvCkr4Zy2z7kXlsXo8nj1BDVeoqgGAf1FRiOzvDfv68ncFhc1JemUeEje/SxFB94c kmIVKDqFAuR/AuY70RhuawhsxccHCcRmV3hvVs1rsScyrPmM1kkDQY045ecqcXi1rCl1 kI4+T5lK4ez7drJ7/+xZgMIaZwkAO1etShU8DWwKJ9hGEUFmOvmFz8rIm+zGo8PJqUPy rhDMj68UOdhSePrwfAdWg/gUkWlgj9PyQSG46jS7LaiegUIaRLQuPeo8HcOLss/rDQ7a U9YpcPC+0rHERsQulTyTCberaG/XUpDHQ6ZFjGFeQKrwijkCsArS8vhfNm5VD93N3bDM CUYw==
X-Gm-Message-State: AOJu0YxCWKXLmrynmjBf1eavf3XQkTBfHOMeZThKPlqEykEomtsNzwb3 +0UqvWpc6c2J4oE3DTSZ5LR3GbY8G2jl+lA8J5AYzdPJuD80iyE95Usj+tB2O1KzMT/MZA0E/Ka NICiaxiSxsCwq6W3aHKOawrtq9mCRmPJdEFms3g==
X-Google-Smtp-Source: AGHT+IHM4lGmK1r0IwdY9m3AUuWDPTaK7ahj4ZkE7PwoFiK5JIBx9S5w76Cc7xImD7k+psWZQndsoASa4fPG5pHKyZ4=
X-Received: by 2002:a17:906:504b:b0:a46:53e7:999f with SMTP id e11-20020a170906504b00b00a4653e7999fmr807295ejk.4.1710823803987; Mon, 18 Mar 2024 21:50:03 -0700 (PDT)
MIME-Version: 1.0
References: <170717045911.28761.2601519691688511415@ietfa.amsl.com> <CAL0qLwYuQhxJmyyX=EYwKS-cfMHT0+iPcwJwutm6vm0=DLJ9Dg@mail.gmail.com> <CAHej_8nSH6AbFBXPHQTKceab5Oi_hmMoA9d_whHi5pLegdtqTw@mail.gmail.com> <CAL0qLwb5E4nMM0cUhWvgjXU_QoXTQPz5zFPD36r5m_R5f-ryfA@mail.gmail.com> <CAL0qLwb9NK7XSYQn+nE+VXdGwRb_PQyEUSQWTwNqx7n7eLPV5w@mail.gmail.com> <CAL0qLwZ8=XzTu0eUNsBBRSFHOAgaY4DGaj9dAN9piPMj3sA2VQ@mail.gmail.com> <32B64A19-6003-4E33-97A6-432C66FDC87B@episteme.net>
In-Reply-To: <32B64A19-6003-4E33-97A6-432C66FDC87B@episteme.net>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 19 Mar 2024 14:49:51 +1000
Message-ID: <CAL0qLwZ-EXB8jsR70RkaWEsTdQODNKiqdJp5dVuRMiRQ5NjMNQ@mail.gmail.com>
To: emailcore@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001c308f0613fc35a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/mUvgTR7CrJpNsKeBRL1vaVj2d6s>
Subject: Re: [Emailcore] Publication has been requested for draft-ietf-emailcore-rfc5322bis-10
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 19 Mar 2024 04:50:48 -0000

On Mon, Mar 18, 2024 at 8:32 PM Pete Resnick <resnick@episteme.net> wrote:

> > (3) Also with respect to the trace flag being added to the registry,
> > and
> > the current DE retiring from that role, I'm wondering if we should
> > consider
> > providing some lightweight process for retroactively adding that flag
> > (set
> > or otherwise) to registered header fields.  For example, I registered
> > Authentication-Results and at least one other with the intent that
> > they be
> > treated as trace fields, so do I need to publish an RFC to get this
> > flag
> > updated?  Or do we want to get a small team to go through all of the
> > current registrations to figure out which ones are supposed to be
> > trace
> > fields, and do a one-shot update (which perhaps the IESG could just
> > approve
> > without publishing something)?  Or can updating that flag be FCFS by
> > the
> > original author/change controller for existing registrations?  Or
> > something
> > else?
>
> This is outside the context of this document obviously, but I'm
> ambivalent about how to do this. I'm not sure a bunch of RFCs is a good
> idea, but I'm also not convinced about FCFS.
>

Since I'm the troublemaker here, let me make a suggestion:

For retroactive population of this flag for things already in the registry,
the IESG can be asked to approve such a request.  At some point we can
announce to ietf-822 or other relevant lists that anyone who thinks they
have a favorite header field in need of this annotation, someone has to
bring it to our attention and request it.

For new registrations, the field must be provided (or its default accepted)
when the registration is made.

> (4) A procedural point: For the HFDU errata you chose not to
> > incorporate,
> > what should be done with them?  Do they remain in that state until
> > some
> > unspecified future update might be considered, or should we be marking
> > them
> > dead/rejected somehow?
>
> The first we definitely decided to reject, so I think the right thing
> there is to mark it so with the justification stated in the document.
> The second we punted to the A/S; not sure how you want to write that up
> in the errata system.
>

It looks like I've opened a bit of a can of worms.  The IESG will take this
question up.  Please don't worry about it for now.

-MSK