Re: [idn] Internet Draft uname.txt

["James Seng/Personal" <James@Seng.cc>]

I can answer that ;-)

To be exact, there is no codepage. ML1, ML2, ML3, ML4 are just binary
string of an IDNs representation, irregardless of codepage or encodings.

But yes, this means there need to be 13++ (Shift-JIS, GBK, BIG5,
KSC5601, ISO2022-JP, ISO2022-KR, ISO2022-CN, ISO2022-TW, EUC-KR, EUC-CN,
EUC-TW, EUC-JP, UTF-8) binary representation for a two han ideographic
name...

-James Seng

> The ugliest part of this approach is that code page identification, is
at
> best imprecise. For example, practically every vendor interprets the
term
> "JIS" slightly differently.
>
> Mark
>
> ----- Original Message -----
> From: "James Seng/Personal" <James@Seng.cc>
> To: "Brian W. Spolarich" <briansp@walid.com>; <idn@ops.ietf.org>
> Sent: Monday, March 19, 2001 10:47
> Subject: Re: [idn] Internet Draft uname.txt
>
>
> > > c. It might be possible to construct a binary string in some
legacy
> > > encoding which gives the same binary representation for another
domain
> > > name (a.k.a. binary collision).
> > >
> > >   This is a big problem in my mind.  Sending unidentified codepage
> > data
> > > could create all sorts of opportunities for spoofing, and more
mundane
> > > problems like DNS caches giving out the wrong answer.
> >
> > Yes. So the workaround would involve preventing binary collision in
the
> > first place.
> >
> > -James Seng
> >
> >
>