Re: [idn] Prohibit CDN code points

[=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>]

----- Original Message -----
From: <DougEwell2@cs.com>
To: <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>; <paf@cisco.com>; <seki@jp.fujitsu.com>
Sent: Tuesday, January 22, 2002 11:08 PM
Subject: Re: [idn] Prohibit CDN code points


> In a message dated 2002-01-22 1:56:56 Pacific Standard Time,
> tsenglm@cc.ncu.edu.tw writes:
>
> > TC/SC character equivalence mapping is similar to  the mapping of
UNICODE
> > Alphabet  map  it to its counterpart of ASCII  alpnabet .
>
> No, it isn't.  Stop saying that.
>
> ASCII uppercase/lowercase mapping is straightforward and unambiguous, and
can
> be done one character at a time with NO lexical analysis (at least for 99%
of
> all languages that use it; Turkish and Azeri do have exceptions).
>
> TC/SC is NOT one-to-one for all characters.  It is for many, but nowhere
near
> 99% or 95%.  If you implement any sort of TC/SC mapping you MUST figure
out
> how to handle the many-to-one and one-to-many cases, and this is where we
> have all been balking.  Users will not understand or accept that "only
some"
> of the TC and SC characters are mapped to each other.
               Using TC/SC in a name identifier is not the same as a
bi-directional translation of  literature.
Today there are many TC/SC translater that only based on character
conversion are used very well in NEWS/BBS. As an identifier comparision ,
one way mapping for both then do comparision  is very simple.  It is like
the case insentive comparision of ASCII string.
               IDN name system need not use a complete literature translater
for such a similar language character TC/SC.

L.M.Tseng
>
> -Doug Ewell
>  Fullerton, California
>