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

From: [email-masked]
Date: Thu, 16 Aug 2001 22:17:12 -0700

I agree with Prof. Tseng's point.  And I suggest that
we shall collect inputs from each language users/engineers
 and ask them what do they think about their scripts should
be handled.  What are the non-semantic issues that 
could be dealed with [nameprep] type of simple scheme and 
benifit long term communication and identification of
a hostname on the internet. 

Liana

On Fri, 17 Aug 2001 11:14:37 +0800
=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?=
<[email-masked]> writes:
       If your statements are meant John is the God father , so no 
> one can
> pass over the line he defined , I will ask what is the goal of this 
> WG ?
> Does it is used to hurt other people in this world ?
>       IDN is very complex ,  but if  you try to neglect some truth 
> then the
> political issue will be introduced , then no one will be happy .
> 
> L.M.Tseng
>

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 13:56:56 +0800

As much as I agree with Prof Tseng well-intention, unfortunately, the
concept of "language" is out of scope for the working group.

This working is chartered to do "Internationalized access to Domain
Names". Unfortunately, domain names understand only "script" not
"language". It does not matter what you wish, it can't be done in Domain
Names (It can be done in some other mechanism of course).

And we are doing "Internationalization" not "Multilingualism". These may
just be terminology but the subtle differences in these terms makes a
lot of differences. I learn it the hard way for those who is with the WG
from the beginning.

Thus, I would modify your statement below to: "from each SCRIPT
users/engineers and ask them how they want their scripts to be use".
(ie. all han ideograph (CJK) users should talk about han folding
together if we going down the path of tsconv).

-James Seng

---

From: "xiaodong lee" <[email-masked]>
Date: Fri, 17 Aug 2001 14:16:36 +0800

James, some opinion of mine
----- Original Message ----- 
From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, August 17, 2001 1:56 PM
Subject: Re: [idn] opting out of SC/TC equivalence

> Names (It can be done in some other mechanism of course).

you said it. Maybe we could not handle language problems in IDN, but we could 
not forget that all script have language characteristics of themselves, especially for 
Chinese. Internationalization means all users could use their familiar  ways to use
domain name, not means all users must follow one ways.

> lot of differences. I learn it the hard way for those who is with the WG

Exactly, we are doing internationalization, but how do we explain for users what is 
internationalization, and what is multilingualism, I think ordinary users care about 
how to use , not what is.

> together if we going down the path of tsconv).

Prof. Tseng care more about users requirements, I think, a technology developed without
enough users requirements, it makes no sense.

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 14:44:09 +0800

One note:

The WG is chartered in a narrow manner to solve a particular problem.
And if we were to expand it to solve a larger-set of problem, we could
but it would mean we would probably have to restart almost all over
again.

I was also reminded once in a while by some folk in IETF that this WG
should be prepare to declare "no-solution" because it does not meet the
"user requirements" (that is vaguely defined unfortunately). But I
remind optimistic that we can find a solution to an "internationalized
domain names" problem with the limited scope we have.

However, should we want to start discussing on "multilingual naming"
problem, then either (a) it is out of scope for this wg or (b) this wg
should declare "there is no solution in domain names space" and lets not
waste time in this wg.

While I am incline to (a) (altho I have not hear any formal complain
that multilingual naming is out-of-scope), (b) is an option I am prepare
to take if this is the consensus of the wg.

-James Seng

----- Original Message -----
From: "xiaodong lee" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, August 17, 2001 2:16 PM
Subject: Re: [idn] opting out of SC/TC equivalence

---

From: "Kenny Huang" <[email-masked]>
Date: Fri, 17 Aug 2001 15:17:39 +0800

Hi James,

"A script is a written form of a language". Again, we may want to question :
"What is the goal of this WG" or "What is the need of non-English speaker" ?
Are you proposing we should setup a MDN WG to replace things have
done so far ?

Kenny Huang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of James Seng/Personal
Sent: Friday, August 17, 2001 1:57 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [idn] opting out of SC/TC equivalence

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 15:10:57 +0800

Hi Xiangdong,

Now, responsing directly to your note:

First, I hope we can agree that the wg is well aware of the TC/SC
problem (after such a long discussion thread) and we are all actively
seeking a solution to it. We may disagree with the approach but we are
certainly not disagreeing with the principle.

> domain name, not means all users must follow one ways.

Lets use logic to discuss this: A. domain names B. scripts C. languages

Your reasoning:
domain names handle script. A->B
script are used by languages. B->C
Therefore, domain names handle language. A->C

basic logic tells us that the last statement is not always true. And in
this case, domain names is not able to handle language. This is a known
limitation of domain names.

> Exactly, we are doing internationalization, but how do we explain for
> users what is internationalization, and what is multilingualism, I
> think ordinary users care about how to use , not what is.

Agree. Very few people recongized the differences.

While there is an desire to solve 100% of the users problem today, all
developments started with one small step at a time. Without solving the
first 10%, we wont know what the next 10% problem. This wg is not the
first nor will be the last one to solve the whole I18N problem. It is
one of the puzzle piece for the IETF and there are many other puzzle to
solve in future. So lets not put too much task upon ourselves.

> enough users requirements, it makes no sense.

And so am I. This is why I can understand Prof Tseng's well-intention.

But the "users set" in IETF context are not limited to any particular
locale so the opinion to the solution may be slightly different due to
different perspective.

Anyhow, lets not argue further on these details anymore but lets focus
on doing the job. The tsconv draft requires more work so lets put more
effort into that to make sure it is completed.

*cheers*

-James Seng

---

From: "xiaodong lee" <[email-masked]>
Date: Fri, 17 Aug 2001 15:31:08 +0800

Hello James
I think we made some misunderstanding on the difference between language and scripts.
I do have no interest to handle language problem in DNS, it is not a good idea as you know. :))
I mean that some problem like TSconv is a language problem originally in some sense. but it 
is not only a language problem finally.  
Right is you basic logic, so I suggest to handle such problem differently too. we need to adopt 
a properly ways to divide the problem into different part, and handle them in different method.
I agree with you, we should try to find a effective solution. we need try, including me.  :-))
ok!
Xiaodong Lee

---

From: [email-masked] <[email-masked]>
Date: Fri, 17 Aug 2001 16:06:52 +0800

Hi James,
             I  think you can display these chinese characters in your
system, so you can make
the explaination , and  tell me the answer how to treat them ?
TC(統) , SC(统)
TC(頻),  SC(频)

They are  the same chinese characters in pairs but they are coded with
different  UNICODE .
Does they are like the problems of   " fi " ?
And  tell me  why  ａ　Ａ　should  be mapped to ASCII  "a" or "A" ?

I don't expect  this WG to solve all the equivalence of TC/SC. I just want
to know what is the guideline to reduce the confusing troubles in nameprep ?
Why so amall set of  PRC simplified quick-written scripts are not case
folding problem ?

L.M.Tseng

----- Original Message -----
From: "Kenny Huang" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, August 17, 2001 3:17 PM
Subject: RE: [idn] opting out of SC/TC equivalence

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 17:05:34 +0800

Dear Prof Tseng,

> the explaination , and  tell me the answer how to treat them ?

These example stated at first level simplication of chinese by radical.
They are equivalent in most context of Chinese language so I think we
can both agree on this. And yes, it is not handled in current
normalization or nameprep.

How can we solve this? Many ways, each one with its pros and cons. I
will provide some suggestions but I am sure there are other ways:

1. Do it inside Normalization Form KC (Standard Track)

Speak to the Unicode Consortium, convience them that these two ideograph
are equivalent and put into NFKC. This will go directly into Nameprep so
long Unicode Consortium agree with it since Nameprep just uses the code
points from Unicode Consortium.

The people at Unicode Consortium would probably question if these
ideograph are equivalent in Kanji and Hanja or olden Vietnamese so we
need to prepare for that.

Pros: it would be part of Nameprep standard. And if NFKC accept this, it
would also solve in other I18N efforts in future, and not just IDN.

Cons: we need to go thru the review process in Unicode Consortium.

2. Do this "optional folding" pre-Nameprep (Informational based)

We would define these mappings within IETF, but published it as
Informational based as an optional folding for Chinese system only.

Pros: We do this within IETF with probably assistant from other group
for review. It also open Nameprep for localized foldings depending on
other set.

Cons: It may be difficult to determine what optional folding rules
should apply for a name. A Japanese (or Cyrillic) names could be entered
using GBK for example and which rules do we apply? And who has priority
to decide what folding mechanism? The registrant of the name or the user
of the name? Is 中国.com a Chinese domain name "zhongguo.com" referring to
China.com or is it a Japanese domain name "chugoku.com" referring to
another place in Japan?

3. Do this in the zonefile (Best Current Practice?)

We would define these mappings in the zonefile for DNS and hence
irregardless how the user type it in, they will end up with the same
resource records.

Pros: It is an opertional issues for Chinese domain names. Registrant of
names would controll what is equivalent and what is not and that may be
defined as a policy on a per-zone basis.

Cons: There would be multiples entries in the zonefiles but they can be
solve by software implementation to generate these entries on loading.

Therefore, there are many solutions to the TC/SC problem. Which path to
take would depend on the tsconv author decision and the wg consensus. No
solution is perfect and it is all engineering trade-off.

Speaking for myself, I would love to see this get done in (1) because it
means it will solve it for other protocol, not just domain names in
future. But I am not sure how to address Unicode Consortium concern. I
am strongly against (2) approach because it will solve the problem by
creating other problems. Implementation experience have been proven to
be very headache to maintain and 'guess' optional foldings to be
applied. I believe (3) is a reasonable approach altho not a perfect
solution either.

> And  tell me  why  ａ　Ａ　should  be mapped to ASCII  "a" or "A" ?

Problems like "fi" and "a" vs "A" are handled in Nameprep not because
IETF decided so, but rather the code points from Unicode Consortium have
these mappings/normalization.

IETF is not in the business to define codepoint because we are not
script or language expert. We leave it to other groups who have more
expertise and we reference their work. Thus, this question is most
appropriate ask to the Unicode Consortium, and not in this WG.

> Why so amall set of  PRC simplified quick-written scripts are not case

God knows I agree with you. :-)

But this is a question which this WG have no answer for since it
references it code points from other place.

-James Seng

---

From: [email-masked] <[email-masked]>
Date: Fri, 17 Aug 2001 21:01:00 +0800

Dear Co-chair James :
          I  only point out  PRC simplified quick-written (草書) characters,
these characters are exactly the same as traditional formal-written (楷書)
characters , but they have different scripts font , so it is different in
UNICODE.  These characters can be quickly recognized by the small difference
in components (糸),  (頁)  . In Taiwan , if we writte them quickly, it is
the form of  SC(统) SC(频) , but big5 character set is similiar to Japanese
Kanji , it is the normal-written traditional scripts form .  So , Japan,
Korean , Taiwan has not use these  quick-written SC scripts .
          If you use windows outlook mail and you trust its correctness, you
can verified it by change the  format code type to any language:  SJIS ,
koren, big5, gb2312(that is GBK).  If it is not one of the character set ,
it will be displayed as an blank mark in SC(统) SC(频) .   So,  people of
Japan , Korean can not get feelings of why some (not all) TC/SC  equivalence
is needed .
          1.The major assumption is based on a well normalized UNICODE , but
it is not true in CJK area, because people are use different code system(
gb, big5, SJIS, UNC-KR).
          2. You can not expect all people to change to UNICODE at one
night.
          3. Global TLD , like ML.COM  is  pre-mature , ML.jp Ml.tw, ML.cn
can be work in their own way, but ML.com based on unicode mixing them
together then produce  confusing status.
          4. IE had help VeriSign/NSI  to resolve  ML.com ,  the external
auto.search.msn.com server and laguage-tagged HTTP parameters can solve
these complexity easily.  In my feeling, the server auto.search.msn.com will
be  a special super ROOT of name server  in the furture . The situation is
happen .

         We discuss many things in this WG for the  reasons that we all
support DNS, but if the conflicts can not be solved and more hurts are
happened again over again in the  proposed IDN system .
         I can understand the difficulties of IDN WG,  but the major
problems are  based on some false assumptions , and so many nonsense
forbidden concepts are preassigned,  these will let DNS  become  too old to
act as a furture name system.

L.M.Tseng

---

From: "Suzanne Topping" <[email-masked]>
Date: Fri, 17 Aug 2001 10:17:07 -0400

----- Original Message -----

> solve in future. So lets not put too much task upon ourselves.

This is not the only issue which is beyond the initial scope of the WG. Is
there a mechanism in place for putting these issues into a holding bin for
later work? IDN is sure to be an evolving system. The first pass will be
just that; the first. Not the final. We have to look at this evolution as a
phased event, and we won't all be happy with the first iteration.

Perhaps if people felt more confident that a path forward exists, and knew
the process for working within it, focus could be better aimed at what needs
to be dealt with immediately. James, can you please outline the WGs method
or plan for phasing in expanded levels of support? Does such a plan exist?

Suzanne Topping
BizWonk Inc.
[email-masked]