Re: Comments on draft-klensin-emailaddr-i18n-00

Dan Oscarsson <[email protected]> writes:

> The draft have many open questions - I recommend that we go for full
> internationalisation of all headers so all headers are in UTF-8,
> and MIME-encoded headers are forbidden. This would greatly simplify
> handling in MTAs/MUAs and gives a clear signal to everybody that
> the ASCII only world is going away.
> Local part, domain names, subject etc. must all be in UTF-8.
> Allowing some parts in punycode or some other encoded form
> will just add a lot of unnecessary complexity.

I would like to give my support to this, to Klensin's draft, and echo
some other things you say.

Truly internationalized mail software are already required to
implement Unicode via IDNA.  Adding UTF-8 to the list of requirements
for internationalized software would only recognize what applications
already do.  (Out of curiosity, are there any widely used and open
standards that encode Unicode into anything but UTF-8 during network
transport or disk storage, except IDNA?)

We need IDNA/IMAA as a fall back mechanism for deployed systems, but
let's not make it more than that.  Going forward with the "encode as
ASCII" approach without, in parallel, offering a better approach for
new protocols, and new implementations of old protocols, is bad.

Another argument, that I only recently come to fully understand, is
that adopting the ASCII-encode approach risk decreasing the quality of
protocols that do not have the same restrictions for which IDNA/IMAA
was developed.  Instead of using Unicode and UTF-8 directly for
internationalized strings, it could be tempting to propose that
protocols should use ASCII-encoded Unicode a'la IDNA/IMAA because it
is used elsewhere.  The argument is that IDNA/IMAA will "leak" into
the protocol, so you better handle it somehow.  Two current examples
would be the UseNet news headers and Kerberos.

Thanks,
Simon