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

[Ned Freed <[e-mail]>]

> 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.

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.

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.

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.

> Technical specifications or Applicability Statements, or the like, will
> contain the normative information about acceptable use of a header
> field.  Providing such information in a registry will, therefore, be
> redundant.  (Possibly adding the risk of divergence, over time.)

> If that redundancy were expected to be extremely helpful -- such as
> finding appropriate header fields for a given functional component --
> then it might be useful.

The value of the information is essentially the same as the value of
registering header fields - it's useful to know what people's intentions
are/were, and why they did what they did. (It's actually even more useful when
what they did doesn't actually make much sense.)

The counter to this is that the header field registry has, regretfully,
for the most part failed to capture this sort of information. Asking for
more information isn't gong to change this, but I don't see how it hurts.

> Given the work of maintaining a registry -- and that risk of it getting
> out of sync with the normative specifications -- I'd suggest that the
> expected utility needs to be /very/ high.

This makes no sense to me. The registry exists and is being maintained, so
that's a sunk cost. Adding a column to it seems to me to a minimal
cost addtion.

What am I missing here?

> Absent such a claim and support for it, this isn't likely to be a
> constructive change.

> Registries should be for coordinating against collisions, dealing with
> scarcity, and not much else, absent truly compelling justification.

Coordinating use outside of standardize use-cases is also kind of important.

				Ned