Re: Problems of Internationalized Mail Address eXtensions (IMAX)

I see.  You probably havent seen my latest reply on the "Forward looking"
part yet.
However, I know where you are coming from.  Perhaps we should introduce the
"charset" parameter but limit it to only UTF8 for now therefore we will have
the flexibility to add in the future...  it will also distinguish between
regular mailfrom and rcptto commands.
Your thoughts?
Edmon



----- Original Message -----
From: "Martin Duerst" <[email protected]>
To: "Edmon Chung" <[email protected]>; "Mark Davis" <[email protected]>;
<[email protected]>; "Paul Hoffman / IMC" <[email protected]>
Sent: Thursday, February 27, 2003 2:47 PM
Subject: 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.
>