Subject: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration

From: Elisabeth Porteneuve <[email-masked]>
Date: Wed, 06 Feb 2002 03:35:18 -0800

Greetings,

Thank you to all for providing a lot of information, which
helps me to understand better the IDN difficulties.

I would like to ask the last question on Chinese letters subject
- my apology if the answer is well known to all but me.

There is an IETF draft document from Chinese team:
[TC/SC] XiaoDong Lee, Hsu Nai-Wen, Deng Xiang, Erin Chen, Zhang Hong,
Sun Guonian, "Traditional and Simplified Chinese Conversion" (16 Nov
2001)
http://www.ietf.org/internet-drafts/draft-ietf-idn-tsconv-02.txt

This document provide for straightforward function SC/TC in Unicode.

Why this proposal cannot be taken into account by IETF IDN WG?

We are speaking about DNS _labels_, and not _language_ (this has been
beaten to death since years, domain names are labels not language,
there is always an approximation, the accuracy is an exceptionnal
coincidence).

Taking this into account the SC/TC _labels_ conversion is therefore NOT
as complicated issue as _language_ translation, on which I could read
a lot in http://www.cjk.org/cjk/c2c/c2cbasis.htm

Please note there is many many cases in Latin when the meaning is
changed
by diacritical marks, but we can all live with current "LDH"
simplification and lack of accuracy.

Elisabeth Porteneuve

---

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Feb 2002 08:02:45 -0800

>Why this proposal cannot be taken into account by IETF IDN WG?

Elisabeth,

This entire topic, and all its proposals, have very much been taken into 
account by the IDN working group.  They have been taken into account at the 
cost of many months of delay, although this topic is actually outside the 
scope of the working group.

The topic calls for an algorithm that equates portions of different 
scripts.  This goes beyond the model of equating upper/lower case WITHIN a 
script.

In fact, this topic is an open research question with no generally accepted 
practise.  So even if the topic were within scope the solution would, at 
best, be very, very risky.

The risk is exacerbated by the fact that this technical approach does not 
scale well.  As soon as an approach like the TC/SC proposal is added, then 
we must find mappings for many, many other multi-script equivalences.  That 
effort will probably take years.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 7 Feb 2002 02:11:02 +0900

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
> scripts.  This goes beyond the model of equating upper/lower case WITHIN a

No. You are maybe pointing to my half-baked draft "look-alike normaliation + multicase ACE equivalence encoding ACROSS
cyrillic/greek/latin script",  not to CDNC's TSCONV-02 draft which attempts to
add  TC/SC 1:1 equivalence WITHIN the unified Han script block by borrowing the suggested framework briefed in my pre-draft. That
may let you mix up the two. TSCONV-02 is succeeded by TSCONV-03 that
takes brand new validation-based TC/SC filtering approach.

> effort will probably take years.

True. There are a huge set of "look-similar" equivalences in Unicode!  But, fortunately,
we have a  much smaller set of "look-identical" equivalences. for example, the size
of each set of equivalent cyrillic/gree/cherokee/latin characters is relatively small,
and the equivalent pairs are more easily found   than 'look-similar' ones.
If we restrict the problem space into the 'look-identical' equivalence,
we will reach the ideal goal  faster and we can avoid the scalability problem
in the proposed multicase encoding.

As for "look-similar" characters, we can recommend new disambiguating font sets for
IDN represenations. For LDH domains, we have already some font sets which
have '0' in slashed-zero shape to be easily distinguished from alphabet 'o'.

Soobok Lee

---

From: hoho <[email-masked]>
Date: Thu, 07 Feb 2002 11:29:10 +0800

Dear Dave,

Two comments:

1. The TC/SC problem or variant problem comes from Unicode and the
decision
   to adopt Unicode as the basis to develop IDN technology. If the
working
   group chooses to use Unicode as basis, then it becomes a partial
solution 
   to the "global" IDN problem because of this side-effect.
2. We do not want to delay your process either. Please refer to the
draft
   "Phased Implementation of Internationalized Domain Names in
Applications" 
   for more details.

-- Janming

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 6 Feb 2002 20:07:29 -0800

>    to the "global" IDN problem because of this side-effect.

This is exactly wrong. The decision to use the ISO/IEC 10646 
(Unicode) character repertoire was made to make IDN a global 
solution. Maybe I missed it, but what other solution has been 
proposed that is more global than using 10646? We already discussed 
this in detail on the mailing list many times, and no one came up 
with anything more global.

>    "Phased Implementation of Internationalized Domain Names in

The "phased implementation" draft is sure to cause a great deal more delay.

- The draft has serious technical errors: the list in section 1 does 
not even vaguely match the list given in Appendix B.

- As the draft admits, adopting the draft would have a very serious 
negative consequence on Japan and Korea. It is very insulting to say 
to people of other countries "because we have problems we cannot 
solve with our script, you will be reduced to using phonetic spelling 
of your names until we come up with a solution, even though we have 
failed numerous times in the past trying to do this". Discussing the 
political ramifications of this consequence could take years.

- The draft is open-ended about what code points would be prohibited. 
Discussing whether to also prohibit additional code points will 
certainly delay IDN. If you are going to make this draft actually 
represent all of the scripts for which IDN is not perfect, the list 
will be huge, and it will probably affect many billions more people.

If you feel that the IDN WG can deal with all those problems without 
delaying IDN, you have not been paying attention to the way this WG 
moves. :-)

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 7 Feb 2002 13:30:00 +0900

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>

> with anything more global.

Unicode is not designed for identifiers use but rather for
display or printing devices,  from the beginning. But,
Unicode is ever evolving to expand its application areass.
It's astonishing Unicode has not yet any concrete lists of 
TC/SC 1:1 and 1:n equivalences.
I admit UNicode is the best solution as for now , but not the sufficienly
mature solution  enough to serve the global language communities,
especially chinese. IDN deployment is not a reversible process.

> political ramifications of this consequence could take years.
 
Then, you should also admit that the opposite position (taken by this WG now)is also 
very insulting to chinese communities.

Soobok Lee

---

From: hoho <[email-masked]>
Date: Sat, 09 Feb 2002 10:27:01 +0800

Paul Hoffman / IMC 寫入：

> >1. If the working

My reading is that the current IDN is the best among those inferior solutions
although it is not perfect neither. Why don't you just admit that it does
produce
side-effects on Chinese? But, there is a chance for us not to hurt any part of
the global community. People cried for that for more than half a year, why you
guys still shut your ears pretending that this is noting?

> not even vaguely match the list given in Appendix B.

No, we do not suggest to delay the whole thing. We know our limitation.  As for

technical errors in the draft, we are happy to make necessary modifications.

> political ramifications of this consequence could take years.

Unfortunately, Unicode Consortium chose to unify the three languages
together. Well, it seems that we are facing a dilemma here. Either we choose
to damage Chinese Internet community and to make Japanese and Korean
happy, or we choose to make them all wait without damaging anyone. When
you say that, are you sure that Korean and Japanese feel happy for damaging
Chinese people? This is not the usual way how peace are maintained, isn't it?

-- Janming Ho, PhD
Deputy Direction
Institute of Information Science
Academia Sinica