Re: First strawman for UTF-8 headers proposal

Paul's strawman proposal avoids defining an ACE form for local
parts.  I'd like to remind everyone that UTF-8-supporting MTAs and
address-mapping servers are harder to deploy than MUAs, and hence there
would be a price to pay for not defining ACE local parts.

Suppose I'm not familiar with ASCII characters, so you tell me your
non-ASCII address, which I remember and later type into my MUA.  If
there is no ACE form for my MUA to use, then the only way for that
message to find you is if you can associate your domain name with a mail
exchanger that supports non-ASCII directly, or with an address-mapping
server.  Either way, you need to wait for some sort of new server to
appear before you can have a usable non-ASCII address to tell me.  (And
even then, if I'm behind a firewall, I might not have access to those
servers; if I can access only a local SMTP gateway then you'll have to
wait for that to be upgraded.)

If an ACE form is defined, then you can register an IDN and give it
an MX record pointing at any existing mail-hosting service, and it
will just work (assuming I have a new MUA, but that's needed in any
approach).  You don't need to wait for any new servers to appear.

Address-mapping and UTF-8 headers can add value beyond what ACE
provides, but they don't render ACE superfluous, because they don't
match its ease of incremental deployment.

AMC