using raw utf-8 in message headers wouldn't replace 2047. instead,
it would add yet another format that MUAs are expected to parse
and display. it would not reduce complexity, it would add to it.
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, and also the existing FROM and
TO will have ACE, so none *Enhanced* MUA will still display the ACE while
new MUA that can read X-IDN-FROM and X-IDN-TO will be able to display the
UTF8 as is... also any MTA along the path will act the same way too, capable
server will use ESMTP with the new MIME header, and none capable/existing
MTA will still use SMTP with ACE and the existing header, there is no need
for the MTA to *extensively rewrite messages*, the *Enhanced* MUA will have
both send out if the first hop MTA is able to use the new ESMTP and MIME
headers, if not then the mail will be send with ACE, which works the same
way as regular email address now adays... I am not saying that we can solve
this by just changing the MTA, but what I am saying is that we should have
the MTA ready, so when we have MUA that can use the new ESMTP and MIME
headers, it will be a smoother transition... what we are doing all the time,
is proposing some implementation that can make smoother transition and not
directly supporting just ACE or UTF8 extremely, like the others... we want
to have both ACE and UTF8 to co-exists so that the transition will be
smooth, why forcing to have just ACE or just UTF8?!
If there is a requirement of change anyway, why not change it to
something that is more simple and well support by the Unicode
Consortium.
It's simply not the case that raw utf-8 in headers is simpler to deal
with than the current method of encoding things in ASCII. There are
complexities associated with each, but the UTF-8 complexities are new
ones whereas the ASCII ones are already familiar. In some ways we'd be
far better off if we kept structured fields in ASCII - even though that
seems unpalatable.
I agree with this, we are familiar with the behaviour of ASCII headers, so
we should keep ASCII with old headers, but if we introduce new headers
especially the ones that start with X-, where they are vendor specified, I
dont see why any MTA or MUA will behave badly since they are not suppose to
be able to pick up those headers anyways, not unless a bad implementation
: )