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

[Ned Freed <[e-mail]>]

> On 7/28/2021 8:13 PM, John Levine wrote:
> > I can sort of see adding a column to the existing registry with a hint
> > about where in the mail process it's typically added, but not a whole new registry.

> A 'hint'?

The file extension in the media types registry is just a hint, but even
so it's quite useful.

> 1. Chosen by whom and through what process?

The usual process of adding entries to the registry. This would simply
be an optional item on the registation form.

>     Note that that makes it additional work and potentially another
>     source of controversy.

Really? You actually believe that it's possible to write a clear and cogent
specification for the syntax and semantics for a new email header and
yet not know the places where it can be introduced into the mail system?

And in the unlikely event this does happen, perhaps in this case it would
be good for the specification to explain why it's unclear.

> 2. It will be taken as normative
>     Because that's what people do when they see entries like this, in
>     places like this.

Decades of experience with various registries says this is not the case.

Like it or not, the "selective inattention" force mediated by the "doesn't
apply to me" boson tends to overpower almost everything.

And as far as I can tell we have yet to detect the "normative" force you
meantion.

> 3. It is an attempt to make a 'registry' be a kind of partial tutorial.
>     To do a useful job takes surrounding text.  Typically quite a bit.

Again, I don't see how you can properly specify a header field without
talking about it's relationship to the email architecture. So yes,
actual text is required to do this properly. But providing a indication
of this in the registry doesn't change this one bit.

				Ned