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

[Alexey Melnikov <[e-mail]>]

Hi Dave,

On 26/07/2021 17:18, Dave Crocker 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.
>
> 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.)

One of the main purposes of the proposed registry is to be able to find 
a specific RFC that defines a particular header field. So the advice of 
"just find the RFC" is not particularly helpful, considering how many 
there are now.

Also, the registry will contain header fields not necessarily defined in 
an RFC (e.g. header fields already in use in the wild), which would 
serve a useful purpose.

I don't think I agree about the risk of divergence: we will populate the 
registry once for known header fields and then future RFCs will just 
update the registry. As our community will know about existence of this 
new registry, I don't think it will be likely that RFC authors will 
forget to update it.

> 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.
IMHO, this would be useful as well.
>
> 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.
>
> 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.

Best Regards,

Alexey