Re: Problems of Internationalized Mail Address eXtensions (IMAX)

> What are your thoughts overall on the doc?

Sadly, I am up to my ears in Unicode 4.0 work right now, and am only able to
keep half an ear open to this mailing list. I should have more time in a
couple of weeks.

Mark
________
[email protected]
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

----- Original Message -----
From: "Edmon Chung" <[email protected]>
To: "Mark Davis" <[email protected]>; <[email protected]>; "Paul Hoffman
/ IMC" <[email protected]>
Sent: Tuesday, February 25, 2003 18:20
Subject: 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
> >
> >
>
>