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

[Alexey Melnikov <[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 :-):

----------------------

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.

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.

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

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


Best Regards,

Alexey