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

From: David Hopwood <[email-masked]>
Date: Fri, 31 Aug 2001 04:28:55 +0100

-----BEGIN PGP SIGNED MESSAGE-----

[email-masked] wrote:
> 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.

What is the problem with converting local standards to Unicode
as a first step? There's nothing difficult in that; in fact it's
considerably simpler than what you seem to be proposing.

> 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.

Why should there be any restrictions on mixing scripts (other
than mixing left-to-right and right-to-left scripts, possibly)?
What benefit does this give?

>  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.
...
> My feeling on this, there are more politics and money
> then technical issues hidden behind us.

Enough with the paranoid conspiracy theories. I'm certainly not
making any money out of contributing to this group, and I doubt
the other contributors are either. There are serious technical
problems with some of the things you're suggesting - that's what
people are concerned about.

> 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
> arguments.

TC/SC equivalence is not analogous to case folding, period. It's
closer to Cyrillic <-> Latin equivalence for Serbo-Croatian and
Azeri (except that it is more complicated in the general case).
If it was exactly the same as case folding, then we shouldn't
include it, because case folding is only in nameprep for consistency
with the folding of a-z and A-Z in RFC 1034/1035 (which is in turn
only there for compatibility with the original HOSTS.TXT specification).
If hostnames had originally been case-sensitive, that would not
cause any problem for users, who would in practice always type
lowercase.

If there is an argument for doing some subset of TC/SC folding, it
will have to stand on it own merits, not by analogy.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 1 Sep 2001 15:58:35 +0800

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: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, September 01, 2001 11:36 AM
Subject: Re: [idn] opting out of SC/TC equivalence

> Hi, Prof. Tseng:
> is an equal access issue.  The best place to demonstrate
>  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.
>
> 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?????????????
>
> 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?=
> <[email-masked]> 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: <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > 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"
> > <[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.
> > > >
> > > >
> > >
> >