Subject: Re: [idn] opting out of SC/TC equivalence

From: [email-masked]
Date: Fri, 31 Aug 2001 01:02:15 -0700

Hi, James, 

  That was a miscommunication on my part, that I did not 
amend, since I did not see anyone care about except 
Martin, which I have answered indirectly.  This is
realy two issues. One is one-to-one TC/SC mapping
in [nameprep]. With this part, we shall include GB, Big5,
and a few other standards representing local access
directly to [nameprep] and speeding up hostname 
translation.  This is my 20% effort for 80% TC/SC cases
arguing for. [nameprep] shall only do one-to-one 
mapping, no guessing or second try shall be there at 
all.

Another issue is direct mapping to StepCode part of
the proposal which is mixed up in that short 
communication.  StepCode has Pinyin for each radical
already for SC character set.   More work is needed 
to check against with larger character set such as Big5
and Unicode.   I thought if some published listing may 
help out for Kanji and Hanja to encode,  just an idea to 
throw out to be criticized, it does not mean to play with
TC/SC AI treatment in [nameprep].   After that, I was a 
little regret, since  if the current architecture of [nameprep] 
does not change,  I am putting up more work for nothing. 

Liana

On Fri, 31 Aug 2001 12:50:45 +0800 "James Seng/Personal" <[email-masked]>
writes:
> Iiana,
> 
> I am not comment on other parts but your presumation that TC/SC can 
> be
> done by radical equivalence simplification is unfortunately 
> misplaced.
> No doubts there are *some* cases whereby TC->SC can be done by 
> changing
> radicals, it is not rule of the thumb.
> 
> Once again, you may want to read the problems with TC-SC paper by 
> Jack
> Halpern at http://www.basistech.com/articles/C2C.html first on basic
> difficulties of TC/SC in general.
> http://playground.i-dns.net/one/onec_sum.htm (also by Jack) 
> describes
> the more specific difficulties of doing TC-SC in Domain Names.
> 
> -James Seng
> 
> > As to TC/SC, I think the problem can be divided into two
> > levels. One level is the mechanical, one-to-one.  They are
> > the majority and bothering  the readers.  The minority as many
> > have said those n-to-1problem, normally one of them is
> > the major one, and the other are minor ones.  There are
> > always exceptions!!!  So to benefit the majority, the way to deal
> > with it is to come up with an arbitary one-to-one, and let Chinese
> > to fight which one is the major one!   The same principle is
> > applied to decomposition of a Hanja and Kanji.  When there
> > is a base, the rest will follow , the application will have
> > something to conform to.
> 
>

---

From: [email-masked] <[email-masked]>
Date: Fri, 31 Aug 2001 18:08:13 +0800

Hi !  Liana:
        I have the same feeling . We try  to solve these SC/TC problem step
by step and  to reduce the complexity.  As John had pointed-out in this
listing , sometimes many scripts-only term  will be expand to lanaguage-term
and let some one to neglect the key-point.  1-1 mapping will reduce the
complexity like mixing case of alphabet that will reduce the number of
non-necessary registration and confusing of using.
        No one try to translate TC/SC in DNS. Even an expert of chinese
language also can not resolve  the different local naming  and habit of
personal name in different Province of China.  The PRC-SC is the frequently
used characters in chinese language, some of them can be differentiated by
different shape, but a little of them is easy-to-confuse ,  such as TC(頻)
SC(频)  SC (统)  TC (統). James seems avoid to answer what is the first step
to solution.
        If the easy-to-confuse characters can be reduced . Even a little ,
that is better than nothing to do.  Reducing the number of easy-to-confuse
characters in nameprep is a better help to CJK users.
        Always to point out the complexity of chinese language and never to
solve some problem step by step is not a coorect approach in engineering.

L.M.Tseng