RE: Problems of Internationalized Mail Address eXtensions (IMAX)

Simon, I feel that Paul is showing a Sisyphean level of patience here,
but I know it can't continue.  I believe you understand that very
similar issues were hashed out, and an ASCII Compatible Encoding (ACE)
solution was adopted in IDNA.  I think you understand that this does not
foreclose someone from eventually standardizing true UTF-8 support for
DNS (probably using EDNS), but I suspect that no one ever will, because
it's a huge amount of implementation work for no meaningful gain (since
IDNA code paths will still have to be supported forever).

The exact same logic holds for IMAA, and is why an IMAX ESMTP extension
simply adds no meaningful value over IMAA for the only folks who care
about i18n, which is the end-users.

Simon Josefsson wrote:

> Earlier you said my question whether IMAA was an internationalization
> solution for MTAs was ludicrous yet you now say IMAA doesn't require
> any changes to the MTA.  Clearly, if you want to internationalization
> support in the MTA, you will have to modify it.  Let's take a step
> back:

The whole point of IMAA, as I'm sure you know, is that we don't want
i18n support in MTAs.  Why bother?  It's a huge amount of work, and any
mail admin who really cares about the LHS can still treat it as an
opaque string (as the standard says it is).  Other than the specific
issue of sub-addressing, the whole concept of an I18NMTA is a huge
amount of work for no value.

If you do need to implement Unicode and nameprep support on an MTA to
support sub-addressing (and that's not clear yet), then additionally
adding punycode is a minor step.

>> It allows other entities in the Internet Mail system to easily use
>> the internationalized email addresses without having to know
>> anything about multiple charsets and repertoires.

> That isn't true.  Not all systems are using Unicode, but IMAA requires
> that they implement Unicode.  Clearly that is forcing them to know
> about multiple charsets.

No, no, no.  IMAA requires nameprep and punycode for i18n-capable MUAs.
But the installed based of 500+ M MUAs out there today can continue to
interact perfectly normally with any IMAA address.  They just don't see
the i18n version of the IMAA LHS, which is find, because it's an opaque
string.  And, MTAs don't need to be upgraded.  This is the whole point
of IMAA (and IDNA).

> If you believe IMAX would make Internet mail unreliable, please
> explain why.

Because most MTAs don't support IMAX, and so every IMAX-capable MUA and
MTA would always have to be downgrading to IMAA (or have to bounce the
message), in which case no value has been added, but a lot of addition
work has been done.  Since there will always be some non-IMAX capable
MTAs and MUAs, IMAA will always have to be around, so everyone of those
IMAX MUAs and MTAs will still need to implement punycode.  Or they can
bounce the message, which is what Paul was referring to as a
non-starter.

Simon, I've seen this movie before, and I know how it ends.  The ACE
wins.

If you want to go forward with IMAX, you may even succeed in getting it
published as Experimental, though I doubt it.  But no one will implement
it, since it adds lots of effort but no value over IMAA, so why bother?

          - dan
--
Dan Kohn <mailto:[email protected]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>