Re: Problems of Internationalized Mail Address eXtensions (IMAX)

Hello Edmon,

At 11:58 03/02/27 -0500, Edmon Chung wrote:
>I see.  The reason support for other charset seems to make sense is that I
>can see that a lot of times IMA would be used within a same region, say
>china MTA to china MTA, which means that by simply using GB would make it
>easier in most cases.  It is therefore going to be true that in most cases
>using the local encoding will be a much more efficient transport than UTF8.

'easier' and 'efficient' are not very clear to me here. If we want IMAX
to be really interoperable, we have to have at least one encoding that
every IMAX-aware piece of software supports. The obvious choice for this
is UTF-8. [Even if punycode is the only encoding that we require every
IMAX-aware piece of software to support (for backwards compatibility),
the software has to support Unicode.]

So just doing things in UTF-8 looks easier to me than also using
all these legacy encodings.

Of course some people will say that just doing punycode only is even easier.
The point is that with UTF-8, we are investing in our future, and
creating a clear upgrade path, whereas bringing in legacy encodings
is more like 'sidegrading'.


>Because the the IMAX capable MTA should really annouce which encoding it
>supports, in real transaction, there wouldn't really be negotiation.
>Perhaps I should change it so that if there is no annoucement of additional
>charset support then the MUA MUST use UTF8 to start with and avoid having to
>negotiate further.  Would that be better?

That would be a step in the right direction. But I suggest to directly
go to a model where UTF-8 and punycode (or whatever fallback we choose)
are the only choices.


Regards,    Martin.