Subject: Re: [idn] draft about Tradition and Simplified Chinese Conversion[version01]

From: liana Ye <[email-masked]>
Date: Wed, 14 Nov 2001 11:09:07 -0800

I thought James has stated we are here to search 
for a solution that is either for all srcipts or non-scripts
(excluding Latin of course).  If this TC/SC is only good 
for Chinese, then are you suggesting your support for 
language tag?

Liana

On Wed, 14 Nov 2001 19:05:07 +0800
=?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= <[email-masked]>
writes:
> Hi!  Liana:
> 
> > Hello,
> >    I like your analysis on placement of TC/SC conversion.
> > But is your HSE is something similar to recordering?
> >
>       HSE(Half Selection Encoding) put all n TC/SC code-point  
> together and
> selecting half of them (n/2) as the result with index (case) for  
> pair of
> TC/SC  input  and   further for AMC-ACE-Z encoding to produce output 
> of ACE
> with case .
>       The half selection is similar to re-ordering.  Because the 
> urgency on
> IDN time schedule,  AMC-ACE-Z with multiple-casing is not adopted to 
> support
> (TC,SC,JC,KC) equivalent set . It only limied to (TC, SC) and remove 
> some
> pair to respect the current considerations of JP.
> 
> L.M.Tseng
> > On Tue, 13 Nov 2001 23:09:42 +0800 "xiaodong lee"
> > <[email-masked]> writes:
> > > Dear IETF&IDN WG:
> > >
> > >     Attachment is our draft about Traditional and Simplified 
> Chinese
> > > Conversion[Version01], which defines the requirement of Chinese
> > > domain name and a proposed solution based on AMC-ACE-Z 
> extension.
> > >     Thanks for any suggestions and comments!
> > >
> > > Xiaodong LEE, HSU NAI-WEN, Deng Xiang, Erin Chen, Zhang Hong, 
> Sun
> > > Guonian
> > > CNNIC&TWNIC&CDNC
> > >
> >
>

---

From: [email-masked] <[email-masked]>
Date: Thu, 15 Nov 2001 09:49:26 +0800

> for Chinese, then are you suggesting your support for
In my personal view:
The  major goal of Draft of TSCONV  are
   1. to improve the communication posibility of CJK area with their scipts.
   2. to reduce the  2^N  records  problem
   3. to support reliable and predicable hostname resolving

Even current TC/SC without including (JSC, JTC/TC) pairs ,  JP still get the
benefits  of  1, 2, 3 . The goal of 2 is based on the assumption of JP
mostly use  simplified JC rather than JTC/TC. But TC area(HK, MO, TW,KR)
must tolerant all the  bad side effect of mixed {sJC , TC } . Unfortunately,
the sJC are about half in PRC-SC and half in traditional-SC  based on the
"PRC Total Table of Simplified Characters"  and most of  them are  in the
range of most frequently used. For Example

國立臺灣大學 (ALL JTC/TC)
u+570b u+7acb u+81fa u+7063 u+5927 u+5b78

国立台湾大学 (ALL  JPCHAR  and also all are PRC SC)
u+56fd  u+7acb u+53f0 u+6e7e u+5927 u+5b66

         Only I can suggested is to do inhibitation in nameprep/HSE to avoid
the  mixing of {PRC-Jp-common-SC, TC } to let ALL-TC and ALL-C-J-cSC work in
these range .  That is based on the assumption that JP are mostly used SJC
rather than TC and  JP want to let  goal 2, 3 can be achieved to some better
level to help other more.

L.M.Tseng

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 15 Nov 2001 12:18:42 +0800

Prof Tseng,

1. AFAIK, JP does not want to match JSC-JTC pairs (if such pairs exists
or such table can even be constructed).

2. I do not see how JP can benefit from 1,2,3 since TC-SC pairs existed
in the tables is based on Chinese simplification process, not Japanese.
In fact, I see JP (and KR) been affected by these TC-SC pairs unless we
remove all characters used in kanji and hanja.

3. TC/SC is not a 2^n problem. It is closer to n*2 to n*4 problem.

4. There is no sub-division of TC-han and SC-han "space" in ISO10646.
Han ideograph is a han ideograph.

5. I am wondering which authority in China, Japan and Korea is approving
this table as stated in the draft.

-James Seng

---

From: Erin Chen <[email-masked]>
Date: Thu, 15 Nov 2001 16:07:43 +0800

I give some of my opinion and question.

James Seng/Personal ¼g¹D¡G

> or such table can even be constructed).

In TSCONV-01, we have took JSC-JTC pairs off.

> remove all characters used in kanji and hanja.

For the benefit 1, people can use Kanji or Hanja to interconnet amoung TC
and SC.
For 2, TSCONV intend to reduce 2^n , every one do not have to register 2^n
For 3,  every one need reliable and predicable hostname resolving

> 3. TC/SC is not a 2^n problem. It is closer to n*2 to n*4 problem.

Why is n*2 or n*4?  It is possible maximum 2^n problem.

> Han ideograph is a han ideograph.

Of course, it is not the goal of ISO 10646. It just collect all the Han
ideograph.
It do not offer any TC/SC tag or TC/SC relationship.

> this table as stated in the draft.

In the TSCONV-01, the authority is from
A Complete Ser of Simplified Chinese Characters
and
Dictonary of Chinese Characters Variant

Erin Chen

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 15 Nov 2001 19:29:36 +0800

> In TSCONV-01, we have took JSC-JTC pairs off.

Ok, so -00 tables is not updated yet.

> For the benefit 1, people can use Kanji or Hanja to interconnet amoung
TC

In other words, JP/KR users can access Chinese language IDN thru either
TC or SC.

But such TC-SC does not usually makes any sense. Therefore, when they
key in TC and they got back SC, wouldnt they be confused?

> For 2, TSCONV intend to reduce 2^n , every one do not have to register
2^n

TC-SC is not a 2^n problem. TC-SC have basically around 2-4 variant in
practice. Others nonsense variant can be constructed but it bears no
meanings usually.

> For 3,  every one need reliable and predicable hostname resolving

Yes agree, everyone ..."regardless of race, language or religion".
(quoted from Singapore pleague :-)

> Why is n*2 or n*4?  It is possible maximum 2^n problem.

Theortically. In practice, it is not. In engineering, we do trade off.

If we have a 90% solution, then we need to consider if it is worthwhile
to do the last 10% if the 90% effort and trouble it cost us.

> Dictonary of Chinese Characters Variant

Thanks. In other words, it have been confirmed by China authority who
does simplification and Taiwan dictionary group. Please clarify that in
your draft. Stating "China, Japan and Korea" is at best misleading.

Next questions then:
1. Who have confirmed it in Japan and Korea as stated in your draft.

2. You have two source. How you put it as one table? You did not use the
table as-it-is in its original form right?

3. If you indeed combine the two sources into a single table, I presumed
there would be many overlaps in the tables but still some conflicts.
What about those conflicting cases and how have you deal with them?

3. Why did the authorities creates such tables in the first place? What
is their written policy on the stablility of the tables and futures
changes? What is the procedure for someone to add/delete/modifyt (if
possible) such tables if someone thinks there is a need to update it?

4. Have it been go thru codepoint experts review by UTC or IRG etc?

Standard questions which someone would ask...:-) very simply to the one
asked about reordering.

-James Seng

---

From: [email-masked] <[email-masked]>
Date: Thu, 15 Nov 2001 20:41:38 +0800

Dear James:
                   I  have gived you the  URL to reference. I think the
following Japanese web sites can help us more to learn these common sense of
Simplified Characters.
 http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/china.html

> table as-it-is in its original form right?
Not correct !
   PRC new simplified characters are come from one only source. They are
re-annouced from PRC goverent in June , 24, 1986 and published in  人民日報,
光明日報  newspaper of PRC .

The following dictionary published by Ministry of Education in Taiwan have
many documents to verify the correctness of these variants.
http://140.111.1.40/main.htm

If you have troubles in Traditional Chinese in this web site. One reference
(No authority in this issue , I think) come from Japan is very interesting.
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK.html
Variants table for Unicode

           As draft of  tsconv described , we adopt only 1-1 mapping part
that can be  referenced correctly from a trustable orginal PRC source to
treat PRC SC to reduce the trouble of  2^n problems and let it can help user
more to do comunications by their local scripts.  This is not a draft to
solve  all SC/TC language conversion, right ?

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 16 Nov 2001 03:31:59 +0800

> > table as-it-is in its original form right?

Okay, in others words, the two source you reference are exactly
identitical?

> > What about those conflicting cases and how have you deal with them?

SInce the table is identitical, then this question is irrelevant.

And I am waiting for the last 2 questions, thanks.

---

From: [email-masked] <[email-masked]>
Date: Fri, 16 Nov 2001 08:26:17 +0800

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: "[email-masked]" <[email-masked]>; "Erin Chen"
<[email-masked]>
Cc: "liana Ye" <[email-masked]>; <[email-masked]>
Sent: Friday, November 16, 2001 3:31 AM
Subject: Re: [idn] draft about Tradition and Simplified Chinese
Conversion[version01]

> Okay, in others words, the two source you reference are exactly
Not correct !
        The  PRC-SC is one of the variants in the dictionary.  But the
PRC-SC is not  arbitary created , they still based on some rule. The
dictionary verified all sources of variants . They are not identical.
> SInce the table is identitical, then this question is irrelevant.
         The conflicts come from the developing and growth after so many
years,
some special not-frequently used TC character fonts that announced in 1956
has been changed or not used in Taiwan . The different one are mark by
document or removed .  These characters can be checked by UTC unicode table
too. Please reference the URL:
http://cdns.twnic.net.tw/cjk.html
> > > possible) such tables if someone thinks there is a need to update
          Sorry ,  it is a goverment's documents of PRC , so we can not
answer the "why" problems.  The first source  is at 1956 , the referenced
documents fixed in 1964.  It is re-announced in 1986.

> > > Standard questions which someone would ask...:-) very simply to the
          The UTC/IRG can review the referenced table and results to verify
the source originality .  I think the draft take the simple approach to
keep it possible to reduce trouble in DNS related problems .  It is not a
document try to solve all variants problem in UNICODE,  the approach just
applied to DNS identifier operation .

L.M.Tseng

---

From: "Kent Karlsson" <[email-masked]>
Date: Fri, 16 Nov 2001 14:03:04 +0100

> Why is n*2 or n*4?  It is possible maximum 2^n problem.

In the "testbed" registration data, how many actually registered "names"
*do* mix SC and TC in *one* name?  And, of course, how many
SC or TC names are registered?

The registrations done people involved with the SC/TC discussion here,
or people/organisations/companies somehow associated with them
should be disqualified in the counting of such names, so as to remove
any irrelevant and possibly biased registrations.

I don't think that "testbed" data should wander into mapping tables for
IDN of any sort.  I'd just like to find out if there is an actual problem or not.

        Kind regards
        /kent k

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 16 Nov 2001 23:48:07 +0800

> dictionary verified all sources of variants . They are not identical.

Okay, I hearing different answer...but anyway, if that is the case,
there are two souce as you said and they are not identical. How do you
put the two source into a single table? What is the policy?

For example, I notice U+56FD & U+570B (the "guo" which Ted mention) just
suddenly disappear in the latest draft. Who made that decision and how
is it done? What policy this authority adopts?

> documents fixed in 1964.  It is re-announced in 1986.

The tables are distributed to teachers actually for education purposes.

-James Seng

---

From: [email-masked] <[email-masked]>
Date: Sat, 17 Nov 2001 00:47:19 +0800

Dear James:

> is it done? What policy this authority adopts?
         Do not forget we are discussed it in JET meeting , our Japan
friends they have some worry or they can not make sure the relation in
(PRC-SC/J-SC ,  JTC/TC) pair.  For Example , like  U+56FD U+570B. This draft
is proposed it will be work in the IDNA AMC-Z-encoder, so these pair that
will influence other people are reserved for further discussions  to make
sure it  and we keep the principle to respect to each others. So,  they are
moved from equivalence  pair  set  to  checking set by JPNIC .
        The draft has one goal to reduce 2^N records problems as possible,
reduced it to one by TC/SC 1-1 mapping and reduced  them  to All-TC  or
All-SC for 1-n mapping are  the possible approach.  Whether  the pair
(PRC-SC/J-SC, JTC/TC) is 1-1 mapping  or not can be verified by many existed
documents. But if  some NIC still want to treat them as total  different ,
then we should to find a way to let them  MUST be  used as  all-TC or all-SC
as you have suggested .
        The  original (SC, TC) pair is keep for checking reference , but if
one character has different meanning and usage in different CJK area, the
relation of 1-1 mapping can be  reduced to checking-state to let CJK people
can keep their local need and also to match the ALL-SC, ALL-TC approach.

L.M.Tseng

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 18 Nov 2001 07:30:49 +0800

> can keep their local need and also to match the ALL-SC, ALL-TC
approach.

Okay, let me try to see if I can get this right on the table mappings:

1. The original source of the table mapping is from A Complete List of
Simplified Chinese Characters and Dictonary of Chinese Characters
Variant.

2. JET members have adopted these tables, combined them into a single
tables.

3. JET members then later remove all conflicting cases with Japanese &
Korean pairs from the tables.

If these are true, then JET could be considered as the authority for the
tables mappings. As such, it is important for JET to explain the policy
and stability consideration of the table, probably in the next revision
of the tsconv draft.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 17 Nov 2001 19:27:42 -0500

> 2. JET members have adopted these tables, combined them into a single

That was my understanding at the October JET meeting.

> Korean pairs from the tables.

Ditto.

> tables mappings.

s/If these are true, then//
s/could be considered as/is/

>              ... As such, it is important for JET to explain the policy
> and stability consideration of the table

While JET may, as a collective exercise, or individual JET members may,
the IETF collectively, and this WG, have no more business "peeking under
the covers" of JET than it does of the UTC.

Our interest is in the necessity, and sufficiency, of the table, for the
purposes stated, and nothing else.

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 Nov 2001 02:27:23 +0100

> the covers" of JET than it does of the UTC.

What James asked for was a description about the plan/policy for stability
of the tables, the same kind of statement we have got from UTC. For
Nameprep to work, it is important to know that the tables will never change
for assigned codepoints in the Unicode Tables. I.e. he asked exactly the
same thing we have asked UTC for the tables we get from them.

   paf

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 17 Nov 2001 20:37:49 -0500

YangWoo,

Thank you for the correction!

Eric

---

From: YangWoo Ko <[email-masked]>
Date: Sun, 18 Nov 2001 10:32:55 +0900

Dear all,

As one of Oct JET meeting attendees, I do not agree with Eric's memory.

> That was my understanding at the October JET meeting.

We did not adopt table. What we agreed are as following;

(1) Table proposed by CNNIC/TWNIC should be reviewed by other members
    like KRNIC/JPNIC. KRNIC/JPNIC will submit table revision request.
(2) CNNIC/TWNIC will prepare I-D in two weeks, and other members will
    review it, and CNNIC/TWNIC will submit it no later than cutoff date
    of Salt Lake City IETF meeting.
(3) JET will have another meeting before IETF to get a chance to find
    consensus on CNNIC/TWNIC's proposal. JET meeting will be held today
    Nov 18, 2001.

> > Korean pairs from the tables.

Regarding removal of "conflicting" cases, Yoneya from JPNIC proposed that
"Is it acceptable for CNNIC/TWNIC to remove all entries in which either 
TC or SC is used in Japan ?". But, I have not seen any answer to it.
In Korea, we have not yet submitted any revision request, except removal
of entries in which both TC and SC is used in Korea.

Regards

-- 
/*------------------------------------------------
YangWoo Ko : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 17 Nov 2001 20:44:19 -0500

Patrik,

I don't buy your reasoning, in either case (guarantees of UTC or JET work
product immutability), unless nameprep has a dependency relationship on a 
reference to a table, rather than to the table itself, at the point at
which the relationship was made.

Take a look at rfc954, it references the DDN, SRI-NIC, nets 10 and 26, all
as if they are immutable. In spite of the brokenness of the formal external 
reference, the referant, a protocol on port 43 and some data, continue to
exist.

I don't much care if the next big thing sweeps the UTC off into oblivion,
treating them as if they were the ITU in a working group is peculiar, and
doing the same with JET is just as odd. Sweeping the UTC off to oblivion
may take more, or less, than the next big thing ;-), but it is a _liaison_
problem, not a WG problem. Its Scott's problem, not "ours".

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 Nov 2001 02:57:29 +0100

> which the relationship was made.

The algorithm used in nameprep for versioning is based on the fact that UTC
have told us that they will not change the tables for assigned codepoints.

We are _not_ looking behind the curtains or evaluate whether we belive that
statement is true or not. We just wanted that statement.

The same way, the wg need a statement from JET.

The "trust" part is not what I am talking about. That is a problem of IAB
(not some random individual) as representative for external contacts.

If we asked for "trust", then we were to start "looking under the covers"
which you implied we did for JET because of this question from James.

We have not done so with UTC and we are not doing it with JET.

   paf

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 17 Nov 2001 22:51:49 -0500

Patrik,

As you (personally) are seeking an assertion without a mechanism for
validation, what you seek is not technical, and out of scope for a
working group. Technical liaison is necessary for a working group
attempting correctness, however, a bureaucratic liaison is not, and is
in the domain of the IAB, which may be random persons, or it may not be,
but that's NomCom's business.

See rfc2850, 2 (f), "Extenal Liaison".

The co-chairs of IDN have more than enough to do, with the limited means
they have, without attempting to also perform some opportunistic function
of the External Liaison, even at the request of document editors, who are
themselves no doubt acting in good faith.

The statement "the wg need a statement from JET" is "true" if the WG chairs
find that rough consensus exists to require some statement. This "truth"
however is still at odds with the External Liaison responsiblities of the
IAB. As co-chair of ENUM are you responsible for the institutional relation
with the ITU? That is the issue as I see it, a transient WG as the holder of
a fragement of an ongoing relationship, or the ongoing IAB as the party that
has that ongoing, and unified, relationship.

It doesn't help that you want an assertion without a mechanism for validation,
as a tossed coin is usually sufficient for that limited, and uninteresting,
end.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 19 Nov 2001 13:55:00 +0800

> find that rough consensus exists to require some statement.

Two clarification:

1. I never claim "the wg need a statement from JET" nor have said
   anything to that respect in my capacity as a co-chair. Please go
   back and read my mail (which I have clarify I have wrote as an
   "argumentive idiot" of the wg).

2. I am not performing any liaison activities as co-chair of IDN to
   JET or otherwise. This co-chair happened to be a member of JET too.

It appears I have to repeat myself twice for every mail I send out, the
second mail to to clarify in response to you twisting my words to mean
more than what it say. IMHO, it is a waste of bandwidth which adds no
further technical discussion to the group.

Therefore, this shall be the last time I shall repeat myself. From now
on, lack of clarification on my part to your interpretion of my mail
does not indictate any agreement of my part on your interpretion. I hope
others will do so likewise so we can all save more bandwidth to do more
useful work.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 19 Nov 2001 08:00:58 -0500

James,

If you want some contributor or external body to explain anything, but you
don't want that explaination to be made to, or benefit, this WG, then you
are wasting everyone's time in this WG suggesting someone explain something
to some outside of this WG. If that is what you want, than having such an
explination put into a draft that is subject to the change control of this
WG, or submitted to the IETF's I-D administrator for that purpose, is also
wasting everyone's time in this WG.

Please figure out what it is you want, either in your capacity as co-chair,
or in your capacity as contributor, and say it. At the moment, I'm concerned
enough about what was written in <010801c16fbf$e55fc4e0$2c8498d3@jamessonyvaio> 
to have sent a note to the Chair of the IAB on the subject of External
Liaisons, the subject of section 2.5 (f), of rfc2850.

The "policy and stability considerations" of anything, work product from
the UTC (the subject of Patrick's note), or from the JET (the subject of
your note) are not technical. Their work product, in so far as it is of
any interest to anyone working on independent interoperable implementations
of anything, is. The tables are in-scope, who made them and why isn't, for
this WG.

Incidently, the issue isn't your personality, it is the role of transient
WGs and institutional relationships. I appreciate that the first issue is
something rather higher on your agenda than on mine. It might benefit you
to read the related exchanges between people other than yourself to get a
better idea of the Working Group issue(s), for instance between Patrick and
I, on the same subject.

Eric

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 Nov 2001 15:58:05 +0100 (CET)

> purposes stated, and nothing else.

I think it depends on what we expect to do with the table (which isn't yet
obvious to me - different folks might have different plans here).

If the goal is to use such a table to provide guidance when 
registering chinese domain names I'd agree with you that the WG
wouldn't care much more than that such a technique and table exists.

But if we are expecting to use the table to create implementations that
codify the table e.g. as part of IDNA or some other IDN solution,
then I think the WG needs to know whether they need to handle
a revisions to the table and/or extensions to the table.

Thus this is a perfectly reasonable question to ask unless the WG has
already determined that the table will only be of a concern when registering
names.

  Erik

---

From: "Kenny Huang" <[email-masked]>
Date: Tue, 20 Nov 2001 15:33:15 +0800

Hi Patrik,

Thanks for your messages.  The official source of the table is described in the draft.
The table is not only for TSConv, but also applied for IDN(CJK) validation by accommodating
other script requirements. Detail CJK validation algorithm will be described in the next 
verion of TSConv before 21st Nov. Basically, unknown code point will pass CJK validation
function. For a valid code point, it will never be invalid in future revision. Only new invalid
code point will be added in future revision. The design ensure backward compatibility,
revisioning and stability. 

Kenny Huang

Secretariat, JET

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Patrik Faltstrom
> Sent: Sunday, November 18, 2001 9:57 AM
> To: Eric Brunner-Williams in Portland Maine
> Cc: Eric Brunner-Williams in Portland Maine; James Seng/Personal; 
> tsenglm@-poo$$$?.$$$j.tw; Erin Chen; liana Ye; [email-masked]; 
> [email-masked]

---

From: 曾黎明 <[email-masked]>
Date: Fri, 23 Nov 2001 09:21:57 +0800

Dear James:
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of James Seng/Personal
> Sent: Sunday, November 18, 2001 7:31 AM
> To: [email-masked]; Erin Chen
> Cc: liana Ye; [email-masked]
> Subject: Re: [idn] draft about Tradition and Simplified 
> Chinese Conversion[version01]
> 
> 
> > one character has different meanning and usage in different 
> CJK area,
> the
> 1. The original source of the table mapping is from A 
> Complete List of Simplified Chinese Characters and Dictonary 
> of Chinese Characters Variant.
> 
The Authority of  Complete List of Simplified Chinese Characters is PRC government, It MUST  be keep.  The  draft  reference it .
> 2. JET members have adopted these tables, combined them into 
> a single tables.
> 
> 3. JET members then later remove all conflicting cases with 
> Japanese & Korean pairs from the tables.
> 
> If these are true, then JET could be considered as the 
> authority for the tables mappings. 
       The implied result is not correct . The original authority of  this SC/TC mapping table can not be changed by referencer. 

L.M.Tseng