If we add new MIME headers and ESMTP commands, MUA and MTA should be
able to have a smooth transition from 7bit encoded 8bits to UTF8.
I don't think that's the right way to go - first, because SMTP MTAs
have
no idea about whether the MUA can support raw utf-8 (this was the
mistake
we made with 8BITMIME, let's not repeat it); second, because expecting
MTAs to extensively rewrite messages is a good way to introduce
errors;
third, because this pretends that a good part of the problem can be
solved by changes to the MTAs, when in reality the UA issues are a far
bigger hurdle.
Let me give an example: *Enhanced* MUA that can use ESMTP will use the
new
ESMTP command with the new MIME headers to have UTF8... let's say the
new
header we called it X-IDN-FROM and X-IDN-TO,
that solution path was considered for MIME back in 1990 or so. it was
a non-starter then, and I expect it's a non-starter now, for the same
reasons.
it's a very bad idea to have two different versions of a message header,
first because they won't stay in sync (these things do change somtimes in
transit, sometimes for good reasons), and second because an MUA that
supports both won't know which one is more recent.
in short, what you're proposing is far worse than 2047 and ACE.
If we are saying that the ACE <=> IDN(UTF8) so why is the two headers not in
sync?
also if new MUA always use the new headers and only old existing MUA wont be
able to read the new headers will use the old ACE headers, so why MUA wont
know which one is more recent?