[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] opting out of SC/TC equivalence
Liana,
I am extremely offended by this email.
I have no doubt there is a lot of money and politics. But this WG has so
far focus *only* on the technical aspect of the IDN work. The limited
scope for the WG is to ensure the WG can actually produce something in a
timely fashion (altho we have failed quite miserably on the "timely"
aspect, if you notice the goal & milestone from our charter).
The WG cannot work on a vague scope covering everything under the sky.
We do not have the expertise to design or create or change character set
and mappings, simply because we *do not* have the right expertise to do
so. We cannot discuss registration policy or management issues of IDN
because we are not a politic forum (bring it to ICANN or MINC or
whatever). We have to limit our scope or else the wg will divert into
chaos. Any wg which does not have a determistic charter and goals are
doom to fail because there is no basis to measure success.
And no, I do not think we are rushing anything. We been working on this
coming to 20months so far, and many many other proposals have been
rejected, yours been *only* one of them which have not gain much
support. Do not take it personally and jump into conclusion.
I am also not impressed with your suggestion that the wg is not open and
democratic with some vague conspriacy theory around the management of
the group. I challenge you to point out specific instance whereby the wg
(or the chairs) have not acted appropriately.
-James Seng
----- Original Message -----
From: <liana.ydisg@juno.com>
To: <tsenglm@cc.ncu.edu.tw>
Cc: <James@Seng.cc>; <liana.ydisg@juno.com>; <idn@ops.ietf.org>
Sent: Saturday, September 01, 2001 11:36 AM
Subject: 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.
> > > >
> > > >
> > >
> >