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

From: Martin Duerst <[email-masked]>
Date: Sun, 28 Oct 2001 07:27:52 -0800

[JS: snip header again]

At 12:50 01/10/28 +0800, xiang deng wrote:

>On Sunday, October 28, 2001 12:41 PM, James Seng/Personal wrote:
>
> > > > 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.
> > >
> > > No, in HK and MO and mainland of china, many people use Mixed
TC/SC.
> > > 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.
>
>No, I do can type TC AND SC in a very usual IME without swich.

Can you give an example? What is the IME you are using? What is
the name you are using?

>And, we can not regulate the register behavior,  whether or not mixing
"TC"
>and "SC" is in one single label depend on customers.

I think it is possible to make some restrictions on registrations:

If a user registers a TC-only and an SC-only name for the same thing,
others are forbidden to register mixtures.

This is in my eyes the most reasonable approach to the TC/SC problem,
because:

- It avoids large numbers of registrations for domain owners
   (they can still register as many variants as they think end
    users will actually use, which is something they can influence
    by what forms they publish)
- It avoids DNS server load increases
- It allows to deal with 1-many cases much easier than proposals
   that have to do actual mapping.

> > Do you have any statistic on how many mixed TC/SC registration have
been
> > done so far?
>
>If there just has 1% or 0.1% , do you mean we can ignore it?

It could be that we can ignore it, or that we can look for
lightweight solutions.

>You mean the problem is so tiny that we can ignore it,

It may be that the solutions available are so complicated and
imperfect that we better decide to ignore the problem, even
if we think it's not tiny.

Regards,   Martin.

---

From: "xiang deng" <[email-masked]>
Date: Mon, 29 Oct 2001 10:36:04 +0800

> It could be that we can ignore it, or that we can look for

If A company register a SC-domain-name, and has a websit about it.
if B company is the challenger of A, he register a mixed TC/SC domain
name, and publish its websit.

Do you think this kind of cases will be minority?

The A company must face the disputation.But there will be 
so many variant domain names, A company will be tired to 
deal with it, Where is the intelligent property of domain name?
Whoes wrong?

Deng xiang

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 28 Oct 2001 19:30:04 -0800

>Do you think this kind of cases will be minority?

Yes, and it happens all the time with the current ASCII-only names. 
The traditional-simplified mappings will cause more of the same thing 
we see now.

>deal with it, Where is the intelligent property of domain name?

No one. That's the point. There is no technical means for determining 
all of the names that are similar for a particular audience. There 
are certainly non-technical human means for determining those names, 
and we currently use non-technical human means for dealing with the 
problems.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "xiang deng" <[email-masked]>
Date: Mon, 29 Oct 2001 12:24:32 +0800

> and we currently use non-technical human means for dealing with the 

Yes, if there is non-technical solution which is really available and applicable.
why not?

And, there isn't a total technical solution about it. But we still can do 
something which will help to limit the scope of influence and which
will be limit in techical scope.

Deng xiang

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 28 Oct 2001 21:27:05 -0800

>Yes, if there is non-technical solution which is really available 

Why not, indeed? No one here is saying that it should not be done. We 
are saying that it should not be mandated in a technical 
specification. There are many types of non-technical specifications 
that would be very useful here. We have been told that the JET group 
is coming out with one Real Soon Now, so that might address the 
problem in a suitable fashion.

--Paul Hoffman, Director

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 29 Oct 2001 06:30:22 +0100

--On 01-10-28 19.30 -0800 "Paul Hoffman / IMC" <[email-masked]> wrote:

> No one. That's the point. There is no technical means for determining all
> of the names that are similar for a particular audience. There are
> certainly non-technical human means for determining those names, and we
> currently use non-technical human means for dealing with the problems.

Paul is completely correct. The important thing is to have one well-defined
set of rules for "equality". Given these rules, three things can happen:

  - A registry can create well-defined rules for what can be requested
    to be registered
  - A registry can create well-defined rules for what goes into the
    DNS zonefile given a registration request
  - The dispute resolution process for a specific domain can define
    their rules, and come up with their own practice for decision making

What is NOT acceptable is to have rules which doesn't settle down, changes
all the time etc.

Just like Paul I see too many players trying to come up with engineering
solutions to real world problems which have to do with "matching of words"
and not "matching of identifiers" which DNS is about.

      paf

---

From: Erin Chen <[email-masked]>
Date: Mon, 29 Oct 2001 15:50:35 +0800

Paul Hoffman / IMC ¼g¤J¡G

> >>  > > Do you have any statistic on how many mixed TC/SC registration have
> >>  been
> >>  > > done so far?
> >>  >
> >>  >If there just has 1% or 0.1% , do you mean we can ignore it?
> >>
> all of the names that are similar for a particular audience.

If we consider TC/SC are not the names similar but just like
Uppercase/Lowercase English letter. But we do not want TC/SC
to be folding to one side.
User can use all TC(Uppercase) or all SC(Lowercase) or mixed
TC/SC(Uppercase/Lowercase) as they presumed. And we need the DNS
treat TC/SC(Uppercase/Lowercase) as the same when compare with
cache RR.

> There

If you think of TC/SC requirement is non-technical human means,
then hou about Uppercase/Lowercase English letter deal in DNS?

> --Internet Mail Consortium

Erin Chen

---

From: [email-masked] <[email-masked]>
Date: Mon, 29 Oct 2001 17:04:20 +0800

Hi ! Patrik Fältström :
----- Original Message -----
From: "Patrik Fältström" <[email-masked]>
> What is NOT acceptable is to have rules which doesn't settle down, changes
        Right , the PRC-only-SC is derived by some fixed rule and keep more
than 40 years.
> and not "matching of identifiers" which DNS is about.
            The terminology "word" is very easy confused between chinese
speaking and non-chinese speaking people. The "chinese word"  may be
presented as multiple Han character phrase and single Han character. 1-n
mapping is based on phrase , so it is content sensitive. But the 1-1 mapping
, especially the PRC-only-SC  that is derived from TC based on quick-written
form , that are characters with the same phonic and can be replaced each
other in character position of word phrase or word. The basic unit in CJK
code point is a single-character , it is also a single-character-word with
some meanning.  An identifier is just a string of symbol , the character
symbol in CJK has inherent meanning in each character, "a" "b" "c" have no
explicit meanning in each characters ,  but  CJK characters have , the
combination of them means the combination of meanning with each character's
meaning. That is why the identifier of CJK characters have more information
density in them. Even the characters has individual meanning , you can not
forget it is only a character in a string of identifier.
           1-1 mappimg TC/SC characters can be direct replaced each other,
but they are not presented in each area by the forbidden native code
encoding. The UNICODE based character input and display like win2000 has
break the separation  barrier . Now, the mixing of TC/SC is more like the
case of ASCII character.
           Matching with word is not the work of  layer 1 DNS , but
matching with identifier is . Even the identifier is composed by CJK
single-character-word , it is an indentifier and the 1-1 mapping TC/SC is
the script characters  too. The single chinese character has inherent
meanning like a word .  But  the IDN chinese identifier is composed by these
single character word , you can not forget the fact CJK character is a
character. 1-1 mapping of TC/SC is not to do the conversion of whole phrase
meanning. It only try to reduce the complexity of  combination in
pair-replacable-characters but with the restriction to dispay them in user
favor fom.

L.M.Tseng

---

From: Erin Chen <[email-masked]>
Date: Mon, 29 Oct 2001 17:56:14 +0800

Patrik Fältström �g�J�G

> � - A registry can create well-defined rules for what can be requested
> ��� to be registered
> � - A registry can create well-defined rules for what goes into the
> ��� DNS zonefile given a registration request
> � - The dispute resolution process for a specific domain can define
> ��� their rules, and come up with their own practice for decision making
>

As mentioned in draft TSCONV, there are mainly 3 categories of TC/SC
conversion. They are 1-1 , 1-n , n-1

In the case of 1-1 , do not to care about the meaning. the matching of TC/SC
can be achieved by a matching function or a finite matching table. That is to
say matching of TC/SC can be done as Uppercase/Lowercase English letter
(EX: A-a).

If we say matching of Uppercase/Lowercase English letter belong to
"matching of identifiers", what is different from 1-1 TC/SC ?

As regards to 1-n and n-1 , it need to know more information such as the
meaning of the phrase or sentence. Such kind of TC/SC would be deal in higher
layer service.

> ����� paf

Erin Chen
�
�

---

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

> problem in a suitable fashion.

I'm not sure what's your meaning.  I always hear two voices:
1. go to UTC.
the requirements are:
(1) preserve the characteristic of TC /SC.
(2) compare without care of TC/SC.
TC and SC are different character, there needn't mapping from 
TC(SC) to SC (TC), it will make a character disappear. 

2.two records solution, one is SC form and the other is TC fom.
it's not applicable.

Deng xiang

---

From: "xiang deng" <[email-masked]>
Date: Mon, 29 Oct 2001 18:06:10 +0800

> and not "matching of identifiers" which DNS is about.

we fall into a loop. we all know the registration solution isn't a solution in fact,
there are technical issues. it can't be a advice from a engineering organize.
but we still  discuss it as a topic.

Deng xiang

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 29 Oct 2001 11:43:52 +0100

--On 01-10-29 17.56 +0800 Erin Chen <[email-masked]> wrote:

> In the case of 1-1 , do not to care about the meaning. the matching of
> TC/SC can be achieved by a matching function or a finite matching table.
> That is to say matching of TC/SC can be done as Uppercase/Lowercase
> English letter (EX: A-a).
> 

Because the 1-1 mappings of SC/TC are not part of any work by ISO or
Unicode Consortium and because these bodies which work with characters
explicitly have told the IETF that only doing a partial solution is NOT
good. Just like the same bodies have not added mappings between codepoints
in parallell scripts in Eastern/Western Europe.

If it was possible to do such tables, I am a beliver that we would have
seen them. And even if it was possible, the Unicode Consortium would not
have told us that it is was not possible. Just because the tables will be
forever partial.

You say in this mail that it is better to have SC/TC mappings for some
codepoints, but not all. What do you think the users would say about that?
Is that really what you want?

It is better to not have any table at all and ask the registrant to do
multiple registrations. This can happen explcitly or implicitly when a
request comes from the registrant all depending on the policy the registry
has on registrations.

This is how things have worked in DNS since it was invented. This is
nothing new, or special for chinese characters.

    paf

---

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

Deng Xiang,

Could you explain why "registration solution isn't a solution"?

Not every one of us knows why...(so please dont say "we all know...")

Thanks.

-James Seng

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 29 Oct 2001 12:20:06 +0100

--On 01-10-29 18.06 +0800 xiang deng <[email-masked]> wrote:

> we all know the registration solution isn't a solution in fact,
> there are technical issues.

Be careful when you write "we all know...".

Multiple registrations is a solution to the problem, and the recommended
one by Unicode Consortium for the SC/TC issue.

  paf

---

From: "xiang deng" <[email-masked]>
Date: Tue, 30 Oct 2001 10:37:26 +0800

> Not every one of us knows why...(so please dont say "we all know...")

1.Adopting multiple records solution - analysis
If a multiple records solution are adopted, and all possible 
TC/SC forms of a single Chinese domain name are added into a 
zone file as the different forms of one identical domain name, 
then this approach has the following weakness:
(1)2^n problem. To ensure a Chinese domain name both TC/SC to 
be correctly resolved, 2^n records must be registered and all 
the records point to one IP address (Note: n indicates the total 
number of the TC/SC variants of the domain name). Chinese has 
over 4,000 variants, and most of them are in common use, a single 
ordinary domain name may have dozens of, hundreds of even thousands 
of TC/SC records, if all of them are to be registered, then total 
number of registrations will explode. In order to protect their 
domain name, users must register 2^n domain names, registration 
cost will increase rapidly, and this is obviously not practical.

(2)The lower level delegation domain name servers may adopt a 
different domain administrative policy or they simply don't support 
multiple records registration, therefore the consistency of TC/SC 
domain names cannot be ensured.

(3)How to ensure that the 2^n records are to be owned by a single 
registered user? This is also an inevitable question, if this cannot 
be ensured, there are will be a large number of domain name 
disputationes. Different registration authorities has different 
registration policies, even if the registration policies can prevent
gTLD and ccTLD practice; they don't have control over secondary or 
tertiary domain.

2.Adopting TC only records and SC only records solution - analysis
TC only records and SC only records solution has the following weakness:
(1)Not applicable to Hong Kong and Macao where both TC and SC are used, 
simplified Chinese is not used at all in Taiwan, TC only or SC only 
records cannot meet the requirements of the users.

(2)This approach cannot solve technically delegation domain problems either.

(3) How to ensure that the two kinds of records are to be owned by a 
single registered user? This is also an inevitable question, if this 
cannot be ensured, there are will be a large number of domain name 
disputationes. Different registration authorities has different 
registration policies, even if the registration policies can prevent 
gTLD and ccTLD practice; they don't have control over secondary or 
tertiary domain.

Please don't say what I say include policy issues, which havn't 
relationship with IETF, because you advise that this is a solution, 
but meanwhile, you don't take care of relevant policy issues 
caused by the solution.

Deng xiang

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 30 Oct 2001 11:43:30 +0800

Since I am going to reply this with a registration side policy, some of
the points I raise is non-technical in nature. Take note.

> the records point to one IP address (Note: n indicates the total

In practice, you only need to add 1 to 4 records (or as many as
required) into the DNS, the most common variant of the name. The
registrant could choose which the n.

The registry could forbid the registration of other 2^n possible
(including TSTTS, TSSST, TSTSS etc which is not likely to occur).

> cost will increase rapidly, and this is obviously not practical.

registration cost is not a point of discussion - it is a business issue.
If C offers TC/SC protection vs another V which doesn't, the market
force will decide who will wins out.

> domain names cannot be ensured.

Then that is the problem on the lower delegation. If the owner of the
domain names decide not deal with the proper handling of his delegation
and causing user confusion, then it is his/her choice. Eventually, he is
going to suffer from the consequences.

> disputationes.

By proper designing your database to handle this. On DNS, use
CNAME/DNAME as neccessary. This is basically not a technical problem.

> Different registration authorities has different

Do you mean a ccTLD C should have a control over the policy over another
gTLD V or another ccTLD J?

> 2.Adopting TC only records and SC only records solution - analysis

I did not answer any of the problem raise here because I think no one
here thinks you should only do TC only or SC only.

-James Seg

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Oct 2001 19:49:10 -0800

Deng:

Thank you for the two analyses. This is a good basis for discussion 
for the users of many languages, not just Chinese.

>then this approach has the following weakness:

Why did you assume that all forms must be added? I thought it was 
generally agreed that a name that consisted of, say, four traditional 
characters would probably only have two forms (all-traditional, and 
all-simplified). A small number of names would have one or two more 
(maybe TTTS or STSS), but that the number would almost always be very 
much less that 2^n.

>cost will increase rapidly, and this is obviously not practical.

Why is there any cost at all? If there is general agreement that all 
sensible spellings should be registered at once, why should a 
registry be able to charge by the record instead of by the name?

>domain names cannot be ensured.

Exactly right. This is precisely the same problem faced in every 
language that has spelling variants or meaning variants. In fact, it 
also appears when company A buys company B and they try to run their 
domains in parallel.

>gTLD and ccTLD practice; they don't have control over secondary or

Indeed. A single registry can ensure that all spellings of a name are 
held together in the one zone, but they cannot assure anything in a 
lower zone, and cannot assure anything in a different registry. 
Again, these problems are the same for almost every language.

>gTLD and ccTLD practice; they don't have control over secondary or

This sounds exactly right, and problems 2 and 3 match those above.

--Paul Hoffman, Director

---

From: "xiang deng" <[email-masked]>
Date: Tue, 30 Oct 2001 12:59:32 +0800

Paul:

I'm sure you know it's a problem of IDN in fact, it's not created.
To refuse the existence of the problem will not help to solve it.

It isn't ASCII vs Chinese characters. IDN provide the platform for
all scirpts include ASCII and Chinese character and others. When 
IDN is created, it belongs to the whole world, anyone have selfish
motive haven't the qualification to say I'M IDN MEMBER.

IDN is important for all of us, we hope the dream of IDN to be true.
In my opinions, the right way is To dig the problem and Solve it. 

Deng xiang      and other comments below:

> (maybe TTTS or STSS), but that the number would almost always be very 

n indicates the total number of the TC/SC variants of the domain name.
if a record named ABCD have 2 variants ( B->b, C->c),
there have 2*2=4 records:
ABCD  ABcD  AbCD  AbCD
So all 4 forms must be added into a zone file.
 
> registry be able to charge by the record instead of by the name?

TC/SC is not spelling issue, TC/SC is same in anywhere, they just
are different in structural form.
 
> also appears when company A buys company B and they try to run their 

TC/SC is not spelling variants and is not meaning variants.
My friend, my English is poor, please don't embarrass me.
 
> Again, these problems are the same for almost every language.

Yes, there are about 2000 pairs of TC/SC. 
every language has the same situation?
 
> This sounds exactly right, and problems 2 and 3 match those above.

thanks for your comments.
Deng xiang

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Oct 2001 07:39:14 -0500

--On Tuesday, 30 October, 2001 12:59 +0800 xiang deng
<[email-masked]> wrote:

> Paul:
> 
> I'm sure you know it's a problem of IDN in fact, it's not
> created. To refuse the existence of the problem will not help
> to solve it.

I don't believe anyone is trying to "refuse the existence of the
problem".  Certainly I do not, nor have I seen even a hint that
Paul, or Patrik, or others have done so.
 
> It isn't ASCII vs Chinese characters. IDN provide the platform
> for all scirpts include ASCII and Chinese character and
> others. When  IDN is created, it belongs to the whole world,
> anyone have selfish motive haven't the qualification to say
> I'M IDN MEMBER.
> 
> IDN is important for all of us, we hope the dream of IDN to be
> true. In my opinions, the right way is To dig the problem and
> Solve it. 

I think we are all in complete agreement on that topic as well.
Where there may be a difference of opinion is about the problem
to be solved and the process for solving it.

(1) The Process

There are really two steps in the IETF.  The first step is
explaining to others that there is a problem to be solved and
convincing them.  You and your colleagues have done a very good
job of this, perhaps better than you realize.  Almost everyone
is convinced.  If anyone is not convinced, anyone who still
believes this is not a problem, they have been strangly silent.

The second step requires that a proposal be put before the WG.
A very specific proposal, that can be evaluated against _all_
criteria.  This is important for many reasons, but perhaps the
most important is that the solutions for "IDN" (including
solutions for TC <-> SC) exists in a very constrained solution
space, e.g., 

	* The DNS must work globally: Local-only solutions are
	quite easy, but most fragment the Internet and the IETF
	cannot accept a solution that encourages fragmentation.
	
	* More generally, the DNS must continue to work.  If we
	could start over and redesign the DNS itself to do IDN
	better, we could examine a broader range of solutions.
	Note that two approaches to "starting over..." within
	the DNS context have been put on the table, and that the
	WG has expressed little interest in either.  One is the
	series of suggestions that require EDNS mechanisms and
	the other was the proposal to move toward a new DNS
	Class, on that was multilingual from the beginning.
	Each has disadvantages, but they would permit changing
	the DNS rules.  As far as I can tell, the DNS has not
	chosen to change the DNS rules, and I haven't see you or
	your colleagues arguing for either of these approaches.
	
	* The solution that improves matching for one language
	may not destroy matching for another language.

	* Unicode is a given.  Several of us believe that design
	decisions made in Unicode are making the IDN work harder
	than it might be otherwise ("Han unification" is just
	one of these decisions).  But the IDN WG can't change
	Unicode, there are no other _global_ coded character
	sets around (waiting for another one would take a _very_
	long time), and I fear we need to figure out how to make
	it work.  If you have other proposals, they should be
	taken to either the Unicode Consortium, or to ISO/IEC
	JTC1/SC2, or to some other recognized global standards
	body and brought back to the IETF only when they have
	agreed with you on a solution.  Arguing in the IDN WG
	about what, e.g., UTC, should do or ought to have done
	is useless, whether you make those arguments or I do.

And so on.

Without a specific draft, the rest of us can't help you in
evaluating these things; we just go around in circles.

(2) The Problem.

Again, we are in agreement that there is a TC <-> SC problem.
What is not clear is whether that is a problem that can be
solved in the DNS.  No one is suggesting that, if it can't be
solved in the DNS, it is not a problem.  Instead, several of us
have been working very hard on alternatives that could be used
if the DNS is not adequate.  And, again, our hypothesis that the
DNS is not adequate for this problem is just an hypothesis.
Your proposal could convince us otherwise, but, for that, we
need to see a proposal.

   regards,
     john

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 30 Oct 2001 16:27:00 +0100

I should have stayed silent and not have written the last mail.

Sorry.

   paf

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 30 Oct 2001 08:09:30 -0800

I should try to clarify a few things.

There have been some objections on this list to Han Unification. While there
are often typographic differences between fonts used for Han ideographs in
different countries, what is encoded represents the fundamental character,
as defined by the IRG (Ideographic Raporteur Group). This group reports to
ISO/IEC SC2 WG2, the ISO WG responsible for ISO 10646. As stated elsewhere,
the IRG includes official representatives from China, Japan, the Republic of
Korea and DPR of Korea, Taiwan via the Taipei Computer Society (TCA), Hong
Kong, Singapore, the US, and the Unicode Consortium.
Han unification is mostly irrelevant to the TC <-> SC issue. The major
stumbling block is not that the TCs are unified across different countries,
but that accurate TC<->SC mappings are (a) not 1-1, (b) contextual, (c)
dictionary-based.

If there were a recognized 1-1 subset mapping between SC characters and TC
characters, I don't think unification would be an issue in matching. For
example, it would matter little to Japanese users that an SC character could
be typed in instead of one of their TC characters, so long as two different
TC characters used in Japan were *not* matched. This could be done as long
as the mapping never identifies two different TC characters with the same SC
character.

It should be also made clear that the Unicode consortium is not at all
opposed to the development of a TC <-> SC mapping. However, it is not a
trivial process. The best body to take on that work would be the IRG --
given the composition and expertise of its membership. The process of
arriving at a uniform, well-developed, agreed-upon mapping would probably
take some substantial time, and from that mapping one would have to extract
the 1-1 subset. As stated elsewhere, the consortium has not seen evidence
that such a mapping is required in IDN (given other mechanisms), and does
have considerable concern that it would slow down the IDN development
process even further.

---

From: [email-masked] <[email-masked]>
Date: Wed, 31 Oct 2001 02:10:57 +0800

Hi ! All:
             Someone give me the following information about  UTC joint
meeting.

http://www.unicode.org/unicode/consortium/utc-minutes/UTC-088-200108.html

IETF - IDN Name Preparation
[88-A51] Action Item for Michel Suignard: Give comments to Mark Davis and
Cathy Wissink on IDN name prep for them to forward to the appropriate
people. [L2/01-318]
[88-C5] Consensus: The UTC would like to see a paragraph added to the IDN
Internet Draft, Preparation of Internationalized Host Names, regarding name
preparation, which would clarify that alternate names may need to be
registered to handle variant spellings for different languages and
simplified and traditional forms. [L2/01-318]

[88-A52] Action Item for Mark Davis, Cathy Wissink: Write and submit a
paragraph on alternate names to the IDN working group. Include Michel
Suignard's comments. [L2/01-318]

[88-A53] Action Item for Asmus Freytag: Suggest text for UAX#15 Unicode
Normalization Forms about IDN name preparation. [L2/01-318]

Properties
[88-C6] Consensus: The UTC does not guarantee that casing preserves
normalization form, but in the future such a requirement may be considered.
[L2/01-321, 327]
[88-A54] Action Item for Lisa Moore: Forward the UTC response on preserving
normalization form when casing to Kent Karlsson. [L2/01-321, 327]

==========
          From the point of view of  TC/SC conversion . No chinese expert
will try to solve this problem in one simple approach.  The HAN scripts
mapping  can be divide to 1-1, 1-n, m-n catagory.  The 1-n , m-n are
sementic sensitive , they are language related and MUST be treated in high
level , so 88-C5 can be applied to these scripts by alternate name
registration.
          But ,  in actual case , PRC-ONLY-SC  that are directly derived
from TC used in China and some foreign country. Most of these PRC-ONLY-SC is
modified with the radical of quick-wriiten  form and they are frequently
used characters in chinese text. So it has high probability to mixed them or
confusing in browsing. Some of these PRC-ONLY-SC are 1-n  that can be
recognied and remove to 1-n catagory , and some of  SC are the same as
Japan's modified Kanchi , if they are different in meaning , then it can be
move to  1-1 local mapping table that belong to other catagory to reduce the
side effect of different language.  The final small set of  1-1 mapping
PRC-ONLY-SC/TC  can be get from the original PRC announced documents. If
these table is combined with the AMC-ACE-Z encoder/decoder with case
anotation output to ACE string, We can get a module that can input  TC/SC
unicoded data and  encode it to ouput  ACE string with pre-defined case ,
the reversing  to deocde ACE string with case will recover to each original
TC/SC by this module . It may be  forced the case to diplay a prefered TC/SC
form to meet the requirement of AP to display them.
          The encoder/decoder will recover to the original  TC/SC unicode
point , so UNICODE table will not be changed.
          By the same ACE string with different casing ,  LDH-DNS server
compare the ACE label case-insensitively . So 1-1 mapping TC/PRC-ONLY-SC
scripts are the same symbol of  name-identifier.
          The 1-1 mapinng PRC-ONLY-SC/TC encoding can not solve all the
problems of  TC/SC convertion . But it can reduce the complexity by level-1
DNS, so the 2^N problem can be reduced to a manageable condition.
          Based on the table that PRC  announced and keep more than 40
years.  It can be keep work quickly without to spend much time to argue.
This approach is not try to do the best or complete perfect solution. But by
this way , solving TC/SC conversion in each level , many troubles can be
reduced to be more managable.
          The numbers of  TC/SC 1-1 mapping pair is a scale factor,  2000
pairs are more than  26 pair of ASCII with 2 order of magnitude , people can
not remember them easily.

L.M.Tseng