I certainly do not want to be seen cutting off the 2022 limb that the
Japanese are sitting on, especially since it works well with 7-bit our
SMTP transfer paths.
So, without any technical evaluations implications, I want to endorse
your message2022 proposal.
But, lets be careful to choose the right name here (again)!
How about "RFC-XXXX-2022", (which raises the issue that Nathaniel
wants to avoid) of maybe using RFC-XXXX-ASCII in place of the rather
generic sounding (and thus potentially ambiguous) MAILASCII. We do
not own or specify all the MAIL or MESSAGE standards in the world, so
...
I do not want to distract this discussion from it main course, but I
do want to put a flag on this name question to be sure that we revisit
it later.
When we revisit it later, I will suggest that we should be precise in
how any TYPE NAME identifies exactly what it means, which suggests
using the name of the source document that contains the full and
precise specification, in the TYPE NAME used in the specified
protocol. This has the flavor of using a unique ISO OID.
Best...\Stef