Subject: Re: [idn] An ignorant question about TC<-> SC

From: [email-masked]
Date: Fri, 26 Oct 2001 11:12:01 EDT

In a message dated 2001-10-26 7:25:59 Pacific Daylight Time, [email-masked] 
writes:

>  Why can't we simply label an IDN with the what language script it is in.

Be extremely careful with the words "language" and "script," and especially 
with mixing them in this way.

-Doug Ewell
 Fullerton, California

---

From: "ben" <[email-masked]>
Date: Fri, 26 Oct 2001 12:48:47 -0400

Hi Doug,

> with mixing them in this way.

Thanks for pointing out the confusion.  Perhaps just the word "script"
is better.  To clarify what I mean, it is to label a Chinese domain
name as <idn>.<traditional> or <idn>.<simplified> (and not
<idn>.<chinese> as this serves no purpose) inorder to take out the
guess work for the CDN users.

Thanks
Ben

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Oct 2001 19:32:40 +0200

> guess work for the CDN users.

This implies that the DNS server need to know how to do matchings between
different charsets (I switch term), for example between BIG5 and some
version of GB, or between ISO-8859-1 and ISO-8859-11. Given some 1000
charsets, the server need to have huge equivalence tables, because in DNS,
we only do exact matchings.

Instead of asking the server to do all of this work, one can force the
client to translate the local charset to one and only one. The server then
only need to know how to match within that charset. And, the client only
need to know how to map from the local charset to the unified one.

We then took one more step and asked the clients to also do normalisation,
so the servers can do matchings based on direct comparison on the bits
which is the representation of the domain name itself.

   paf

---

From: "ben" <[email-masked]>
Date: Fri, 26 Oct 2001 15:13:18 -0400

Hi Patrik,

Unfortunately, I am not as technically knowledgable as you are so I
rather not comment on what you have wrote.  However, what I am certain
is that you have illustrated the fact that
applications/clients/users/servers/etc can be made to take advantage
of this explicit labeling of what "script" an IDN is in and over time
(with people writing appropriate applications) can be developed into a
very powerful and useful system.  (Unlike TLD such as ".gov", ".ca"
which serves next to no purpose from an IDN's perspective.)

Thanks,
Ben

---

From: [email-masked] <[email-masked]>
Date: Sat, 27 Oct 2001 10:26:30 +0800

Hi !  Mr. Patrik Fältström:
        The problems of TC/SC in IDN come from the large amount of  chinese
SC characters which are derived from TC coexisted in UNICODE  table.
1. The SC announced in 7, March,1964 from PRC and re-announced in 24, June,
1986 are all characters in quick-written form which are derived from
original TC and most of them are the same meaning and used only in PRC.
These SC/TC characters are listed in "Total Table of  Simplified Characters"
in the announced documents.  In Taiwan , we have one  variants dictionary
related to Chinese, Japanese, Korean  in our web sites of Ministry of
Education .
http://140.111.1.40/fulu/fu5/fu6.htm
        CJK characters have about 4000 most-frequently-used characters , a
lot of TC/SC are in these catagory. If we remove some SC that are common
used in Japan(about 123 characters in PRC announced total table ) and all
1-n mapping characters,  there still have about 2000 pairs of
PRC-only-SC/TC 1-1 mapping characters. The probability of mixed TC/SC with
the same meanning will be very high.  As IDN is the identifier name in DNS ,
the confusing caused by using the same meanning  SC to replace the same
meanning TC from user will  let chinese IDN in troubles.
2. The SC, TC are co-existed for printing and display , they can not be
unified or one-way mapped (normalized) to one representaive code-point.
Because Japan, Taiwan, Korean use the TC part in their normal-written form.
On the other side, China use the SC part in quick-written form, but HK and
Mo will  use TC/SC mixed . TC/SC have different code points , so, it cause
the problems of  2^N registration records and consistency of  NS delegation.
3. TC/SC MUST be coded in bi-directional way to support
may-be-recoverable-display and comparison without care 1-1 mapped TC/SC in
LDH-DNS server.  It  MUST NOT be solved by forced-translating to one of
TC/SC.

L.M.Tseng

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 27 Oct 2001 08:58:45 +0200

--On 01-10-27 10.26 +0800
"=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<[email-masked]> wrote:

> It  MUST NOT be solved by forced-translating to one of
> TC/SC.

I have not said it should. I like and appreciate the recommendation the
Unicode Consortium gave the IETF, and that is to _NOT_ do unification of
TC/SC or even try to come up with matching rules.

Instead, multiple registrations in DNS, one for the SC and one for the TC
version is recommended.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 27 Oct 2001 08:54:40 +0200

--On 01-10-26 15.13 -0400 ben <[email-masked]> wrote:

> However, what I am certain
> very powerful and useful system.

No, you misunderstood. It is exactly the contrary.

Comparison of characters from two different charsets is extremely
difficult. It can not be done effectively for all combination of charsets.

Only way of dealing with this problem is to map each of the two charsets to
one, and then use comparison rules for that charset.

This is the model which works in DNS, and that is why this wg have chose
this path. This has already been discussed, and discussing this again
doesn't help this wg make progress.

IF you want to start to tag a string (in whatever charset) with meta
information such as language, geographical location of creator of the data,
date and time when the string was created, and use this information when
you do a matching decision, then you talk about something different than
DNS, something which looks like a keyword system. John Klensin has
described such systems in drafts which have circulated on this list.

    paf

---

From: "ben" <[email-masked]>
Date: Sat, 27 Oct 2001 10:31:45 -0400

Hi Patrik,

I am not doing a good job in explaining my idea.  I am working on
actually setting up the entire system (for testing and data gathering
purposes) and I will let you know when it is completed so that you can
see exactly what I mean.

Thanks
Ben

---

From: "xiang deng" <[email-masked]>
Date: Sun, 28 Oct 2001 10:06:00 +0800

> Instead, multiple registrations in DNS, one for the SC and one for the TC

Yes, multiple registrations in DNS is better than do nothing. 
But, there are still some problems can not solve:
1). Just do one for the SC and one for the TC, it isn't enough. Because other 
person can register mixed TC/SC domain name. How to deal with the disputations of
registration. Such disputations will not disappear, if we have no real solution about it.
it's policy issue.

2). multiple registrations in DNS can solve a part of the issue, How to solve the 
delegation issue of subdomain and keep the consistency. 
it's technology issue.

3). if we provide multiple registration solution for customs, we must guarantee the multiple
records belong to one custom. but from technology view, we can not guarantee it.

Deng xiang

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 28 Oct 2001 10:37:50 +0800

> registration. Such disputations will not disappear, if we have no real
solution about it.

Such mixed TC/SC is possible but not useful in practice. It is neither
"TC" or "SC" and using it is fairly complex to use. Perhaps some
statistic of how many such TC/SC mixed label been registered in practice
will be useful.

> delegation issue of subdomain and keep the consistency.

Agree.

> records belong to one custom. but from technology view, we can not
guarantee it.

I presumed you mean from a "policy view", not technology because if we
cannot guarantee from technology view, ie there is no technology, then
we cannot do so in IDN anyway

-James Seng

---

From: "xiang deng" <[email-masked]>
Date: Sun, 28 Oct 2001 12:04:50 +0800

On Sunday, October 28, 2001 10:37 AM , James Seng/Personal

> statistic of how many such TC/SC mixed label been registered in practice

No, in HK and MO and mainland of china, many people use Mixed TC/SC.
This is fact we can not avoid. 

> we cannot do so in IDN anyway

No. In current profile of IDNA, there is no technology. 
But this does not mean that there no technology solution, and you  know it, 
but you refuse to accept this fact.

If we can not guarantee the solution satisfy custom's requirement, the answer is:
let user to suffer it, because there hasn't techonolgy solution(as your words) and 
we will push this  defective solution.

Deng xiang

---

From: "xiang deng" <[email-masked]>
Date: Sun, 28 Oct 2001 12:15:19 +0800

On  Sunday, October 28, 2001 10:49 AM, Martin Duerst wrote:

>At 10:06 01/10/28 +0800, xiang deng wrote:

> >On  Saturday, October 27, 2001 2:58 PM, Patrik F$BgM(Btstr$B‹N(B wrote:

> This is a valid concern. It is ultimately a policy issue. But
> it should be possible to produce some data/guidelines (e.g. as
> an informational RFC) that registrars/registries can adopt.

> It is much easier in such a context to deal with 1-n correspondences
> than it is if an actual mapping is required.

Thanks. 

> I'm not really a DNS expert, but I think with something called
> CNAME or DNAME, there is a very easy solution that will keep
> consistency.

No, we can't keep consistency. 
Mr. James has agree with my opinion.

> It's the customer's job to do that, and the registrar's job
> to help them. No need for this WG to do anything.

If the fact is as your said. If a user register a domain name which include 
Chinese characters, he must register all variant forms of the domain name.
Then he can protect his intelligent property of this domain name.
why? just because he want register a Chinese domain name?
This answer will not satisfy any person.

Deng xiang

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 28 Oct 2001 12:42:21 +0800

> Mr. James has agree with my opinion.

Let me clarify. I am saying this is a problem we need to look into. I
did not say there is no solution.

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 28 Oct 2001 12:41:14 +0800

> This is fact we can not avoid.

Yes, TC & SC are used in some place. Many text also have mixed TC/SC.

But I am saying mixing "TC" and "SC" in one single label is uncommon
simply because it is difficult to type. You need to switch from TC IME
to SC IME repeatively.

Do you have any statistic on how many mixed TC/SC registration have been
done so far?

> but you refuse to accept this fact.

Wait, read my reply again. I am saying what you said is a "policy view"
not a "technology view". Whether we have this technology or not is not
my point.

If there is a technology to do TC/SC, then we can either do it at IDNA
or registration. If there is no technology, then we can do none.

> we will push this  defective solution.

It is all engineering trade off. No solution is perfect.

-James Seng

---

From: "xiang deng" <[email-masked]>
Date: Sun, 28 Oct 2001 12:50:28 +0800

> simply because it is difficult to type. You need to switch from TC IME

No, I do can type TC AND SC in a very usual IME without swich.
And, we can not regulate the register behavior,  whether or not mixing "TC" 
and "SC" is in one single label depend on customers.

> Do you have any statistic on how many mixed TC/SC registration have been

If there just has 1% or 0.1% , do you mean we can ignore it?

> It is all engineering trade off. No solution is perfect.

You mean the problem is so tiny that we can ignore it, 
I think you are cheat yourself, because you know Chinese characters.

Deng xiang

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Sun, 28 Oct 2001 14:13:35 +0800

> simply because it is difficult to type. You need to switch from TC IME

As I know, mixing TC and SC may be neither uncommon nor difficult.
1. Most IMEs in Traditional Windows 2000 can support TC and SC
    directly without switching, even they can let the user type in
    Japanese characters without switching. It is not unusual for one IME
    to support all, or as many as possible, Unicode characters if the system
    supports Unicode. For examples, the phonetic imput method and the
    Boshimy input method. The former is the default method in all Chinese
    systems and almost every Chinese or Taiwanese who uses computers
    knows how to use it easily. The later is widely used by many people
    who want to have high Chinese input rate, especially for professional
    users.
2. In cases of "Taiwan" and "Taipei", the TC and SC characters for the
   first character "Tai", U53F0 and U81FA, are both widely and
   interchangeably used in Taiwan. You can find examples of mixed uses
   in Chinese Web sites, such as TAIpei City Government, National
   TAIwan University, TAIwan Semiconductor Manufacturing Company
   (TSMC), and so on. If we support top-level IDNs in the future, every
   domain and host below IDN.tw will have AT LEAST two records,
   one in  IDN.U53F0-wan and the other in IDN.U81FA-wan.

Chun-Hsin

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 28 Oct 2001 14:28:23 +0800

>     to support all, or as many as possible, Unicode characters if the
system
[snip]

On Windows, you install 2 IME, one for TC and the other for SC. You
toggle between these two while you key in.

>    in Chinese Web sites, such as TAIpei City Government, National

They are both Traditional form one is T-T, the other is T-S. Both exist
on a TC IME.

I can understand the big problem of TC and SC domain names.

I am not too sure of the problem of "mixed TC & SC" identifiers. Please
do provide some statistic if you can. Thanks.

-James Seng

---

From: Martin Duerst <[email-masked]>
Date: Sun, 28 Oct 2001 15:58:58 +0900

>    one in  IDN.U53F0-wan and the other in IDN.U81FA-wan.

This is a very specific case (there are others like this, but
not that many). For companies/organizations, they should just
register both variants. For the top-level domain, there should
be only one. It would probably be U53F0-wan. Please note that
this is very similar to two-letter combinations for countries
in ASCII; to a certain extent, people just have to learn them,
e.g. that it's 'jp' and not 'ja' for Japan,...

Regards,  Martin.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 28 Oct 2001 09:11:38 -0800

>Yes, multiple registrations in DNS is better than do nothing.

Good, we agree here.

>But, there are still some problems can not solve:

And here too!

>person can register mixed TC/SC domain name.

If anyone on this list has said "just do one for each", they are 
incorrect. The right solution is "do as many as are needed". That 
number will change with names, of course.

>How to deal with the disputations of

Exactly right. It has nothing to do with the IETF. The IETF has never 
dealt with the exact same policy issue for *any* language, nor have 
we even started writing up policy proposals for any. Many examples 
have already been given, such as "color" and "colour", or "koln" and 
"köln". Although not identical, these types of examples have the same 
kinds of problems to end users as Traditional and Simplified Chinese 
do.

>delegation issue of subdomain and keep the consistency.

Yes, but not one for the IDN WG. This affects all host delegations, 
not just ones that use internationalized names, and it has been a 
real-world problem for over a decade. If people have technical 
solutions for this very thorny issue, they should definitely bring 
them to the DNSEXT working group.

>records belong to one custom. but from technology view, we can not 

Exactly right. That is the way it is for all languages (including US 
English), and it will affect everyone the same when we 
internationalize the DNS. In fact, it will also affect everyone the 
same for every internationalized protocol, not just DNS. There is no 
protocol now that says "mail sent to [email-masked] should be 
delivered to [email-masked]" even though those two are more 
equivalent to English-speakers than traditional and simplified 
Chinese characters are to Chinese-speakers.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Mon, 29 Oct 2001 02:18:18 +0800

> toggle between these two while you key in.

I'm curious about why you are so confident that I must install
TWO IMEs, one for TC and the other for SC. Do you use TC
Windows 2000 daily? :-) I don't know whether you do, but I
do use TC Windows 2000 to input TC quite often. Besides,
sometimes I also use the same input method software to input
SC and Japanese characters for Web queries, althouth it is
designed specially for TC.

Anyway, I'm sure I can install ONE IME to input TC and SC
together. As examples, let's try to input the second Chinese
character of China, U570B for TC and U56FD for SC, by
any ONE of the input methods I mentioned in my last message.
(The example character means country/nation in English.)

Method 1. Type "EJI6", specifying the pronouncing of the
example character, into the default TC phonetic input method
of TC Windows 2000, and it will list lots of characters with
the same pronouncing in pages, 10 candidates per page.
Among them, if you choose Candidate 1, you get U570B,
the TC example character. Or if you choose Candidate 5
on the 2nd page, you get U56FD, the SC example character.

Method 2. Type "OKD" into the Boshimy input method
software for TC Windows 2000. (This input method is widely
used for most users who want to input TC characters fast.)
Among the prompt candidates, Candidate 0 is U570B,
the TC example character, and Candidate 2 is U56FD,
the SC example character.

In addition, Mr. Xiang Deng had also explained that he can
type TC AND SC in a very usual SC IME without switching.

So it is clear that we don't need to install TWO IMEs to
input mixed TC and SC in TC Windows 2000. The user also
does not need to toggle between TC and SC while input. It
is natural that one TC input method software aims to make
the user input as many Unicode characters (and as easy)
as possible. Indeed, almost every add-on TC input method
software can support far more HAN characters than those
defined in Unicode, since some other charsets define more
characters than Unicode. The market will drive the software
company to do so, becoming a Uni-input method software
and supporting as many HAN characters as possible.

I sincerely hope you get chance to try the above examples
and verify them.

> I can understand the big problem of TC and SC domain names.

It depends on how you define TC and SC. You can also say
it is an example character that can be found in both TC and
SC. As I know, several characters in SC scripts and Japanese
scripts are *commonly*  and interchangeably used in Taiwan,
and part of them are supported in TC charsets. Chinese people
can recognize these kinds of characters equivalently.

Personally, I prefer to say they are big problems of HAN
domain names rather than TC-SC domain names. As an
example, there are three Han characters in Unicode for
my surname 'Wu', one of the top ten surnames in Taiwan:
U5433 for TC, U5434 for SC, and U5449 for Japanese.

> do provide some statistic if you can. Thanks.

As I know, due to current TC/SC registration policies in the
*running* testbeds that support the tsconv draft, you can not
get the precise statistics.

Chun-Hsin Wu

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Mon, 29 Oct 2001 02:41:01 +0800

> e.g. that it's 'jp' and not 'ja' for Japan,...

According to your suggestion, we should also have only one
form for the second Chinese character of China, and you might
prefer U56FD (for SC) rather than U570B (for TC). I doubt
how many Chinese can accept your suggestion. *_*

I don't think the case is similar to two-letter combinations for
countries. It's more similar to that we should have only one
word for America, United States, and USA. For example,
people have to learn it is 'USA', and you can not use
neither 'United States' nor 'America' as the TLD. I also doubt
how many Americans can agree with this idea. :-)

Regards,

Chun-Hsin Wu

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Mon, 29 Oct 2001 03:03:07 +0800

> get the precise statistics.

For example, if you register a two-char Chinese domain name
in one of the four combinations: SC-SC, SC-TC, TC-SC, and
TC-TC, the other three combinations will be reserved to
prevent confusion and dispute in the future.

I'm not so sure whether my explanation can answer your
question. WARNING: I do not know the policies
thoroughly. Just for your reference.

Regards,

Chun-Hsin Wu

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Mon, 29 Oct 2001 04:33:37 +0800

> how many Americans can agree with this idea. :-)

For full-name DNS, White House may need to register at least
three records:
    "America"."USA"
    "United States"."USA"
    "USA"."USA"
If they forget to register "United States of America"."USA",
some other one may register it validly. This may imply that
every IDN customer must know and register all combinations
of the domain name he wants to register.

Besides, users must know
    "America"."America",
    "United States"."United States"
and so on that not ending with "USA" are invalid as
full-name DNS.

WARNING: This analogy can not reflect all problems
of Han characters (CJK+SC+TC). Analogize further
with caution. Hope I do not confuse you in an
unexpected way.

Sincerely,

Chun-Hsin Wu

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 10:30:31 +0800

Just one comment: Domain names are identifiers, not names.

-James Seng

---

From: "xiang deng" <[email-masked]>
Date: Mon, 29 Oct 2001 17:19:40 +0800

On Sunday, October 28, 2001 1:09 PM, Martin Duerst wrote:

> Assume somebody registers SSSS as a domain with name servers,...
> and registers TTTT CNAME SSSS, why would that not guarantee that
> everybody looking for foo.SSSS and for foo.TTTT would get to
> the same machine(s)?

Yes, I give the other example:
IN NS SSSS.foo
SSSS IN A 1.1.1.1

IN NS TTTT.foo
TTTT IN A 1.1.1.1

How to config the 1.1.1.1 and its subdomain?

Deng xiang