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

[Ned Freed <[e-mail]>]

> Hi Ned,

> On 27/07/2021 18:39, Ned Freed wrote:
> >> On 11/16/2020 9:10 AM, Alexey Melnikov wrote:
> >> > Based on an earlier discussion on the mailing it looks like there is
> >> > consensus to create (or possible ammend an existing) registry for
> >> header
> >> > fields with extra information about which types of SMTP agents are
> >> > allowed to add them in transit or before final delivery.
> >
> >> Taking John Levine's pointed challenge on this issue, I went back to
> >> this start-of-thread message and now find myself also questioning what
> >> the benefit of this effort will be.
> >
> > I did so as well, and I see a lot of problems I didn't see before.

> You were the original person who motivated creation of this ticket  10
> months ago :-):

That's ... amusing.

> ----------------------

> Ned Freed wrote:

> There are many fields that get added after submission and before final
> delivery. And not all of them really qualify as "trace" IMO.

> Moreover, making a list of these fields is a hopeless task, since all
> it takes is one more document to outdate the list.

> I see two possible solutions:

> (1) Craft some text saying something like, "Only add fields specified as OK
> to be added in other specifications."

> (2) Create a registry.
> I kind of like the idea of a registry, but it is a fair bit more work.

> ----------------------

> >
> > For starters, I'm confused by the use of the term "subregistry". This seems to
> > me to come down to an update to RFC 3864 to add a column where people
> > can indicate where in email architecture they expect this field to be
> > added.

> No, this is not what I meant. I meant it would be listed on the same
> page as registered permanent/provisional header fields. But even that is
> not required, if people don't think this is a good idea.

OK, I now understand your proposal. But I still think having one list is much
better than having a separate list. Why not simply annotate the existing list
with the  points at which it makes sense to introduce the header field?

> And no, definitely not suggesting any changes to RFC 3864, as it is also
> used by HTTP and Usenet, as having extra columns that only apply to
> email would be very confusing to other users of the registry.

I believe that's what "n/a" is for. But OK, if you really think that having
mail-only field is too confusing to people viewing the page, then the way to
address that is to have one central list behind it all and generate as many
views of it as you like on the page.

Having to submit to two registries  grots up the process considerably for
anyone wanting to register a header. And given the complaints we're getting
about how hard it is to register stuff, I really think the focus needs to be
on keeping that process as simple as possible.

> Anyway, let's change "subregistry" to "registry".

Except it *is* a sugregistry. Changing the name doesn't change that.

> > If that's the case, then I don't understand what this has to do with
> > SMTP and
> > thus why it has any business being in RFC 5321bis. Our architecture
> > covers more
> > than SMTP, and this is true even if you expand the scope to cover
> > SUBMIT and LMTP.

> > If anything this belongs in RFC 5322bis.

> That would be Ok with me personally.

> > If you think about things this way I think most of the issues about
> > MSA/MDA/MUA/MfooA disappear. The columns is a means of indicating the
> > point in the architecture where it makes sense for it to be added.
> > Nothing
> > more. How this corresponds to actual implementations, which we all know
> > map the architectural elements to software components in complex and
> > fairly arbitrary ways, is essentially irrelevant.

> Ok, so are you suggesting some changes to how columns are named? Or
> their removal altogether? Can you please clarify.

No, I am suggesting keeping them the same, and making it clear that we're
referring to the point in the architecture the addition is supposed to be
done, not where it happens to appear in any particular implementation.

And while there may - or may not - be issues with the architecture document
that are worth looking at, I don't think they rise to the level where
citing the basic architectural components of email is problematic.

				Ned