[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] opting out of SC/TC equivalence
Hi, Prof. Tseng:
The first step of our solution is to open [nameprep]
to let local standards in for easy code exchange. This
is an equal access issue. The best place to demonstrate
such a feature is the "cut and paste" of an IDN URL
e-mail entry. It shall be a universal treatment at the end.
The second step is to define the ranges of different
user groups who need their primary script tag. No
mix scripts is allowed at this stage. But we can take
wish list. For example, English may wish to include
Greek, Korean may want Hanja on its wish list.
That way, we can identify conflicts of codepoints and
possible confusion of codepoints, and start with a
careful first step. A survey on the existing registered
names for possible conflict when Unicode is
used for limited scripts is helpful to start a clean first
deployment of [nameprep].
Someone wants to lunch an unmature version of
[nameprep] are very smart. They probally have put
a lot of money behind this working group already , where
we are just a decoration voices to lead people believing
that this is an open discussion, democratic process.
Meanwhile, when we started to speak out, they are pressing
the group to rush out a premature version, so that they
can get ahead of [nameprep] and make the future upgrade
very hard for others, so CJK at a great disadvantage on
this. The Chinese domains using numbers for their names
at this time for globle consideration would be trashed.
My feeling on this, there are more politics and money
then technical issues hidden behind us. I am not an
expert on any of this, even I can point out feasible solutions,
why they can not see it. Why the "Scope of this WG" is
so tight on them is beyong me. As a user, we have been
waiting for years, why suddenly, a few months of extension
making so many people nervous? Even Microsoft has
sliping their published product delievery dates as long as
6 months, why such a multitude complexing issue has
to be pushed to a rushing date?????????????
So your first step TC/SC simple mapping in [nameprep]
which should be on the same footing with Latin case
folding being pushed away by all kind of nonsense
argurments. I think we are too naive. We are better to be
prepared to leave this discussion and bring the whole
thing onto the news media, and let the public to be the
judge.
Liana
The third step is to let safe range go online for ML.com.
On Fri, 31 Aug 2001 18:08:13 +0800
=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?=
<tsenglm@cc.ncu.edu.tw> writes:
> 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
> ----- Original Message -----
> From: <liana.ydisg@juno.com>
> To: <James@Seng.cc>
> Cc: <idn@ops.ietf.org>
> Sent: Friday, August 31, 2001 4:02 PM
> Subject: Re: [idn] opting out of SC/TC equivalence
>
>
> > 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"
> <James@Seng.cc>
> > 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.
> > >
> > >
> >
>