See below. The fun hasn't stopped yet! -Doug Ewell Fullerton, California
----- Original Message ----- From: "Masataka Ohta" <[EMAIL PROTECTED]> To: "Robert Elz" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, March 20, 2002 7:58 am Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 > Kre; > > > | IDNA does _not_ work, because Unicode does not work in International > > | context. > > > > This argument is bogus, and always has been. If (and where) unicode > > is defective, the right thing to do is to fix unicode. > > Unicode is not usable in international context. > > There is no unicode implementaion work in international context. > > Unicode is usable in some local context. > > There is some unicode implementaion work in local contexts. > > However, the context information must be supplied out of band. > > And, the out of band information is equivalent to "charset" > information, regardless of whether you call it "charset" or > not. > > > So, stop arguing against unicode (10646) - just fix any problems it has. > > Fix is to supply context information out of band to specify which > Unicode-based local character set to use. > > With MIME, it is doable by using different charset names for > different local character set. > > See, for example, RFC1815. > > As for IDN, it can't just say "use charset of utf-7" or "use charset > of utf-8". > > IDN can say "for Japanese, use charset of utf-7-japanese". > > Or, if you insist not to distinguish different local character sets by > MIME charset names, IDN can say "use charset of utf-7, but, for > Japanese, use Japan local version of utf-7" and somehow specify > how a name is used for Japanese. > > Anyway, with the fix, there is no reason to prefer Unicode-based > local character sets, which is not widely used today, than existing > local character sets already used world wide. > > Masataka Ohta
