Re: Can we back up a bit and ask some basic questions? An alternate model

At 8:00 PM -0500 2/14/03, John C Klensin wrote:
>IMAA starts from the assumption that the right way to handle domain 
>names is, with slight modifications, the right way to handle email 
>local-parts.

Those words in the document, and they should not be put there by 
interpretation. IMAA starts from the assumption that the right way to 
handle domain names is likely to be as good or better as other 
proposals. If it is as good or better, it is preferable to using a 
different approach. If a better approach based on a different format 
is proposed,that's fine. Early views of what would be best for IDNs 
were shown to be not as good as what we ended up with.

[ Much elided below ]

>(3) Strawman semi-proposal

To help the discussion, let's call the two proposals IMAA-ACE and 
IMAA-UTF8. FWIW, I thought about something along these lines a long 
time ago and rejected it for some of the reasons below.

>(a) We define a new SMTP extension.  For purposes of discussion, 
>let's call it UTF8ADDRESSES.

Therefore IMAA-UTF8 cannot achieve wide use until this extension is 
nearly universally adopted. When you get a business card from a 
colleague that has an internationalized email address, you can 
probably assume that their MTA supports UTF8ADDRESSES, but there is 
no way for you to know if your own MTA supports it, so you don't know 
if you can send him or her mail.

With IMAA-UTF8, you always need to know that the originating MTA 
supports UTF8ADDRESSES. If you are a road warrior, you would need to 
know if your on-the-road ISP's MTAs support UTF8ADDRESSES before you 
could send mail to an IMAA-UTF8 address. Of course, you have no 
control over this.

With IMAA-UTF8, if a company has an MTA that supports UTF8ADDRESSES, 
and they want to add a firewall that has an SMTP proxy, that proxy 
must support UTF8ADDRESSES. Today, companies can safely add firewalls 
that have SMTP proxies that have fewer ESMTP services than the MTA 
for which they front.

These sound like show-stoppers to me. If I'm wrong, please let me know.

>(e) The issue of what the delivery MTA actually puts in the mail 
>store, and how the receiving MUA(s) handle that, has never been the 
>subject of Internet protocols and that should probably not change.

This can be read as "the display of internationalized addresses to 
the user will happen by magic". That seems pretty irresponsible to 
the people who have deployed POP and IMAP clients following the 
IETF's standards. It also assumes that the MTA knows that all mail 
clients that are going to read mail from the mailstore can read 
IMAA-UTF8 addresses. Given that there is no negotiation possible 
there, that is a pretty heady assumption.

Basically, you are forcing the MTA to know the display capabilities 
of all possible readers of stored mail. MIME avoided this: IMAA-foo 
should avoid this.

>(f) There are some other issues here, but that is the general 
>picture.  For example, we would have to _very_ carefully work out 
>what went into reply messages, given that those might hit a host 
>that wasn't prepared to have i18n characters in them.  But that is a 
>problem to be worked out, not a showstopper.

We fully disagree about the status of that. Many systems based on 
IETF standard will break if reasonable responses are routinely lost.

The outcome of this proposal is that no one will know when it is safe 
for them to start using their internationalized LHS. This will be 
even more confusing to the people who can very safely use their 
internationalized RHS in email, but not their internationalized LHS. 
This sounds like a setup for frustration and failure.

--Paul Hoffman, Director
--Internet Mail Consortium