Re: Problems of Internationalized Mail Address eXtensions (IMAX)

Hi Mark,

I think you are right.  That is why in the IMAX description, UTF8 is
mandated.  The thinking is similar to XML among other things.  And in order
to not reinvent the wheel, a fall back to punycode is suggested.  What are
your thoughts overall on the doc?

BTW, I have updated the draft to -01 and changed a number of stuff.  Most
notably taking out section 3 as suggested by everyone... including myself
:-)

You can find it at: http://www.dnsii.org/draft-ietf-chung-imax-01.txt

(Paul, I havent changed the optional parameter word "CHARSET" yet, but I
think you are right and I will do so in the next version)

(James, I have sent it to the IETF, but I dont know when they will get it
posted... just in case you ask.)

Edmon



----- Original Message -----
From: "Mark Davis" <[email protected]>
To: <[email protected]>; "Paul Hoffman / IMC" <[email protected]>
Sent: Tuesday, February 25, 2003 6:36 PM
Subject: Re: Problems of Internationalized Mail Address eXtensions (IMAX)


>
> > >   It doesn't say that it is a bad idea to
> > >allow more than one charset.  I agree with that document, let's
> > >require the use of UTF-8 in protocols, but allow negotiation of other
> > >charsets to smooth transition and deployment.
>
> > You should take this up with Harald Alvestrand, the author of RFC
> > 2277. Note that IDN chose not to use UTF-8, and Harald (as chair of
> > the IESG) approved it to be on standards track.
>
> I want to point out a very important feature here. While IDN does not use
> UTF-8, the contents are algorithmically mappable to UTF-8. That is *very*
> different from allowing arbitrary charsets.
>
> There is a huge problem with using arbitrary charsets; they don't
> interoperate well. They may not be supported on the recipient platform, or
> if supported, even the 'same' charset (such as SJIS) is interpreted in
> different ways on different platforms. If the on-the-wire protocol is
UTF-8
> (or algorithmically mappable to UTF-8) then senders and recipients only
need
> to deal with one charset.
>
> Mark
>
>