Subject: Re: Layer 2 and "idn identities" (was: Re: [idn] what are the IDN identifiers?)

From: [email-masked]
Date: Sat, 1 Dec 2001 21:04:13 EST

In a message dated 2001-12-01 16:35:38 Pacific Standard Time, 
[email-masked] writes:

>  Since nobody disbute with me, I take it as we are agree to
>  the above discussion.   I'd like to refer to my  I-D 
>  draft-liana-idn-map-00.txt  for more discussion in this direction. 

I absolutely DID dispute both the notion of language-tagging of IDN 
identifiers *and* the notion of tacit agreement to a non-consensus idea.  But 
I guess that wasn't the answer the author was looking for.

-Doug Ewell
 Fullerton, California

---

From: liana Ye <[email-masked]>
Date: Sat, 1 Dec 2001 20:04:14 -0600

Please provide your arguement, I have been waiting.

Liana

On Sat, 1 Dec 2001 19:23:34 -0800 (PST) Rick H Wesson <[email-masked]>
writes:
> 
> 
> On Sat, 1 Dec 2001, liana Ye wrote:
> 
> [snip]
> >
> > Liana
> Liana,
> we all do not agree, and don't take silence as an affirmation of 
> your
> position.
> 
> -rick
> 
>

---

From: liana Ye <[email-masked]>
Date: Sat, 1 Dec 2001 20:02:34 -0600

Please provide your reasoning.

Liana

---

From: "Bruce Thomson" <[email-masked]>
Date: Mon, 3 Dec 2001 12:49:23 +0900

Written by liana Ye:

> 
> And Chinese TC/SC example:
> <wind> has four code points in Chinese:
> TC, SC, TC radical, SC radical.
> 
> I believe there are other code points of <wind>  have 
> been allowed in UCS.  Isn't  it a time to use the 
> "equivalent character set" term? Or may we use 
> "equivalent codepoints" to stay away from the lanugage
> connotation?
> 

So you would like these four code points to be normalized and
indistinguishable? There must be a huge cultural difference
between Japan and China in their feelings about the language.

In Japan, there are two characters for "river" (sorry, I am
not going to look up the code points.) But nobody here
in Japan would see the logic of treating them as identical.
They are different, and these differences between characters
are part of the rich culture of the nation.

To be sure, there are some characters that are so old that
while they are still used in names (such as in my own home address),
they could be normalized into their modern equivalents without
complaint. But who is going to sort all this out in a reasonable
timeframe?

The CJK unification makes it even worse, of course, as decisions
made for China affect other countries.

What is the down side of treating these characters as different,
anyway? Worst case, a company with "wind" in its name might
have to register two or even four variations of the name.
Works for me.

Bruce

---

From: liana Ye <[email-masked]>
Date: Mon, 3 Dec 2001 02:01:11 -0600

> between Japan and China in their feelings about the language.

Bruce:

Using your arguement above:

0048; 0068; Case map

210B; 0068; Additional folding
210C; 0068; Additional folding
210D; 0068; Additional folding

1D407; 0068; Additional folding
1D43B; 0068; Additional folding
1D46F; 0068; Additional folding
1D4D7; 0068; Additional folding
1D573; 0068; Additional folding

So you would like these nine code points to be normalized and
indistinguishable? There must be a huge cultural difference
between English and French in their feelings about the language.

> have to register two or even four variations of the name.

I sincerely feel, you don't know what you are talking about.
And you don't understand what is going on with CJK 
users.  I don't even know how to start to discuss with 
you about your above comments.  May be after I have a 
good night of sleep, I can come up with new ideas.

Liana

---

From: liana Ye <[email-masked]>
Date: Mon, 3 Dec 2001 01:06:28 -0600

Thanks for the list of comments, and I'll try to make it 
more like a draft of from a group.

Liana

---

From: liana Ye <[email-masked]>
Date: Mon, 3 Dec 2001 01:36:48 -0600

I see that you have not read the I-D yet, and Deng Xiang 
has replied your Chinese vs. Japanese arguement, I 
will wait for your comment on the language-tag issue,
or anything not up to your standard.

Liana

On Sun, 2 Dec 2001 18:51:02 EST [email-masked] writes:
> Liana wrote:
> Certainly, and I apologize for the tone of my previous post.
> 
> 1.  I did NOT agree with the concept of language tagging or script 
> tagging of 
> DNS identifiers, either for all scripts or for just a subset of 
> scripts such 
> as CJK; and I HAVE said so in the past.  DNS "names" are 
> identifiers, and 
> they are *not* necessarily words or true "names" in any natural 
> language.  I 
> mentioned the examples of "altavista.com" and "teoma.com" to show 
> that domain 
> names need not be identifiable as to language.  Liana responded that 
> it was 
> not necessary to identify the language of those two examples, since 
> they were 
> unambiguously representable in the Latin script, whereas domain 
> names encoded 
> with CJK characters could be mappable to other CJK characters.  But 
> I, and 
> others, HAVE stated many times that to provide a SC/TC mapping 
> strategy that 
> works for some characters but not others, and could provide some 
> nasty 
> surprises for Japanese users who do not equate these characters as 
> the 
> Chinese do, does not seem to be a viable part of IDN.  It might be a 
> nice 
> marketing solution, but it is not an engineering solution.
> 
> 2.  I did NOT agree that, had I and others remained silent about the 
> proposed 
> language-tagging scheme (which was not true in any event), this 
> would have 
> amounted to some sort of approval of the idea; and I DID say so.  
> Others on 
> this list, who have far more experience than I in IETF working 
> groups, have 
> stated that this is not the way IETF WGs operate.  Consensus is more 
> commonly 
> gauged using straw polls or by compiling lists of participants in 
> favor of 
> the idea and opposed to the idea, not by "pocket acceptance."
> 
> Having said this, I understand that Liana was trying to demonstrate 
> approval 
> of continuing the discussion, not necessarily approval of the idea 
> itself, 
> and I don't want to be in the position of trying to pre-empt the 
> introduction 
> of new ideas.  So I suppose it wouldn't hurt to look at the I-D, see 
> what we 
> think of it, and make our opinions known at that point.  But it is 
> NOT the 
> case that "nobody disputed" either this point or (1) above, and to 
> say so 
> made it seem like the author was merely ignoring opposing voices.
> 
> In a message dated 2001-12-01 20:05:03 Pacific Standard Time, 
> >> identifiers *and* the notion of tacit agreement to a 
> non-consensus 
> >> idea.  But

---

From: [email-masked]
Date: Mon, 3 Dec 2001 16:29:57 EST

> or anything not up to your standard.

Here are some specific concerns related to items in 
draft-Liana-idn-map-00.txt.

| The proposed ACE is a mnemonic encoding scheme,
| and is called StepCode [StepCode]. 

Hasn't AMC-ACE-Z already been chosen as the standard ACE for IDN?  I would be 
surprised if the decision were made to use two different ACEs depending on 
the language, or script, of the encoded text.

| U-s   U-p A-p
| U+0041  U+0061    a      (Latin Letter A case folding)
| U+2fc2  U+2ee5    yv2    (Han character fish for Chinese case folding)

Several Chinese speakers and other experts have already, repeatedly, claimed 
that SC/TC mapping is NOT a 1-1 operation like Latin case folding.  If you 
think your users will be satisfied with the 1-1 solution only, go right 
ahead, but if this turns out to be inadequate and you need to propose a fix, 
get ready to hear a lot of people say "I told you so."

| To facilitate end users for the speed of IDN access as well as
| compatibility with existing applications, it is RECOMMENDED that an IDN
| code exchange table inculdes applicable local display standards
| corresponding with each applicable codepoints in UCS.

Backward mapping tables to convert Unicode to legacy standards, for the 
express purpose of allowing end-user software to delay the transition to 
Unicode?  Does this sound like a solution for the future?

| It is REQURIED to register a language tag with IANA and its
| associated script range whenever it is modified. 

There is already a perfectly good update process in place for both ISO 639 
and RFC 3066.

| To use mixed scripts in one IDN label is NOT RECOMMEMDED for an
| early deployment of IDN.

This immediately outcasts the Japanese, who have every reason to mix 
hiragana, katakana, kanji, and romaji.

|         Alphabet Sys.  Consonant Sys.  Character Sys.
|
| From: 0020            0530            2e80
| to:   052f            1bff            d7af
|
| include:Latin           Armenian        CJK
|         Greek           Hebrew          Kanji
|         Cyrillic        Arabic          Kana
|         IPA             Devanagari      Hangul
|         Vietnamese      Malayalam       Yi
|                         Thai
|                         Lao
|                         Tibetan
|                         ...

Sorry, it's just not that simple.  There are plenty of alphabets and 
alphabetic characters encoded above U+0530.  That's probably why the Unicode 
Consortium, while providing a list of blocks of code points like the 
following:

    # Start Code..End Code; Block Name
    0000..007F; Basic Latin
    0080..00FF; Latin-1 Supplement
    0100..017F; Latin Extended-A

is careful not to imply that ranges of code points are permanently reserved 
for *classifications* of scripts like this.

You can tell that the three ranges listed here are arbitrary and bogus even 
for the CJK scripts, by noting that Korean jamos (alphabetic) are located in 
the "consonant system" block, while the Japanese syllabaries (kana) and 
precomposed Korean syllables are in the "character system" block.

| Some cultures often use more than two scripts within the same group,
| such as Japanese, but rarely using another script especially from a
| different group. 

As noted above, the Japanese use four scripts from two different groups.

| The main issue in IDN-Map
| is to identify character equivalent sets, and reduce the number of
| applicable IDN identifiers by 1) limiting the applicable IDN input code
| points to Plane 0 of Unicode table,

Has anyone else so far proposed that supplementary characters be flat-out 
prohibited from occurring in IDN identifiers?  Why should they be singled out 
as a way to "reduce the number of applicable IDN identifiers"?

| It is RECOMMENDED that reasonable studies are given to each language to
| classify script treatment model, and a cost vs. benifit analysis in select
| a long term script specific processing protocol to be embedded in IDN
| language specific modules.

This won't disrupt the schedule of the working group, will it?

| canonicalization

This word has no clear definition and is carefully avoided by Unicode, as Ken 
Whistler already explained.

| A string mixed with CJK and Kana is Japanese, CJK and Hangul mix is
| Korean. However, an all CJK character string MUST presumed to be in the
| primary language tag, that is Chinese, and registered as the only IDN name,
| unless the registrant requests a second and a third language to access the
| same IDN name.

Nothing prevents an all-Han string of any arbitrary length from being 
Japanese text.  The priority given to Chinese here is not likely to be well 
received by other groups.

| Also, it
| introduces more policy decisions, for example, an all CJK character
| trademark registrant may have to registrate in three languages to ensure
| the legitimacy of the trademark.

Wait just a minute.  Wasn't the whole idea of this language-tagging and 
CJK-folding scheme to PREVENT registrants from having to register an IDN 
identifier more than once?

| After all, a useful tool is to let its
| user to make decisions.

Some tools are interactive, others are not.

Finally, it is not yet clear to me whether the "idn-zh-" tag prefix is 
supposed to be embedded within IDN identifiers or specified separately.  But 
between this additional label and the use of the less efficient StepCode 
instead of ACE-Z, it seems that several bytes out of the precious 63-byte 
limit are required as overheard to support this tagging scheme.  If I 
remember correctly, it is CJK users (Soobok Lee is only the most vocal) who 
are most concerned about the space limitation and who want to find (or 
invent) the most efficient encoding system possible.  Will these other CJK 
users agree to this proposal?

-Doug Ewell
 Fullerton, California

---

From: [email-masked]
Date: Wed, 5 Dec 2001 01:17:36 EST

In a message dated 2001-12-04 20:11:19 Pacific Standard Time, 
[email-masked] writes:

>> SC/TC equivalence itself is far simpler than the "four winds, two eggs"
>> equivalences, and has quite a bit of merit. I won't express any
>> real opinion on it until I study it further.
>
> It is not so simple as to be able to be done _accurately_ by an 
code-based1-1
> bit-string matching process. There are semantic, syntactic and contextual
> considerations that require at the very least a morphological analysis 
process
> in order for TC/SC to be done with a reasonable amount of accuracy (i.e.
> orthographically).

Thanks for saying with some authority what I have apparently been unable to 
communicate effectively, namely that TC/SC is not merely a 1-1 operation 
comparable to Latin case folding.

-Doug Ewell
 Fullerton, California

---

From: liana Ye <[email-masked]>
Date: Tue, 4 Dec 2001 22:45:14 -0600

Hi, John,

  Excuse me for not putting my draft-liana-idn-map-00
to your attention.  To answer your questions I have 
following comments.

> > Correct except SC/TC conversion. There is solution on the desk,
> > so it isn't  possible, it's existence.
> 
> I'm unconvinced this is true.  Please convince me.
> 
> What I think we have is:
> 
> 	(i) A partial solution on the desk, one that deals with
> 	the 1-1 cases that do not have overlap with Korean or
> 	Japanese.

Please read draft-liana-idn-map-00.txt Section 2.1.2.  
Each language has its own column of codepoints. 
While  A  maps  a  for Chinese, A can be mapped to a' 
for Japanese, and a'' in Korean. 

> 
> 	(ii) General agreement that, however many characters (i)
> 	covers, some Han characters, or even Han characters for
> 	which simplified forms (or traditional forms) exist, are
> 	not covered.
> 	
> 	(iii) No plan, at least none "on the desk", about how to
> 	deal with those other characters.

draft-liana-idn-map-00.txt has been available in 
IDN directory since Step. 12.  

> 	
> 	(iv) Fairly general agreement that at least some of the
> 	problem must be dealt with at a different sublayer or, at
> 	least, in some non-DNS mechanism.
> 
> It seems to me that, given the above, there are several possible
> paths forward, e.g.,
> 
> (1) Decide this is a client problem, to be used in special
> clients for Chinese-speaking people.   I would personally
> recommend again such a solution, both because I think it will
> tend to fragment the network and because client-based solutions
> are notoriously hard to maintain as one, e.g., figures out ways
> to deal with additional characters.   But, independent of that
> preference/ advice, the details of what one does in client
> software, especially client software that is not expected to be
> universal, is not an IETF problem and hence should be discussed
> somewhere other than on this list.

I agree with you that  
> special clients for Chinese-speaking people 

> tend to fragment the network and because client-based solutions
> are notoriously hard to maintain as one, 

This has been the experience with many client servers
in CJK areas already.  Even among CJK only, it is hard 
to do so.  It is best to remain in IEFT.

> (2) Conclude that TC-SC matching is a sublayer 2 problem.  If so,
> please move this discussion to the IRNSS list and, as specified
> there, either recast it in the terminology of the "DNS Seearch"
> document or explain why the model of that document is
> inappropriate.
> 

Prof. Tseng has given another good explanation.  To me,
the key is moving IDN identifiers through minimum layers.

> (3) Conclude that TS-SC matching is a sublayer 2 problem but that
> some machinery, beyond IDNA (with more or less the existing
> nameprep), needs to be put into the DNS sublayer to support it.
> If this is the case, we need better discussion of what additional
> machinery is needed and why on this list.  And, unless there is a
> flaw in the reasoning above, or a significant case not
> considered, the rest of the TC-SC discussion should still go
> elsewhere.
> 
>    john

Draft-liana-idn-map-00.txt has described an IDNA equivalent 
interface to applications, but much earlier than IDNA described 
toASCII and toUnicode terms. 

Draft-liana-idn-map-00.txt has defined script and script-mix 
independent normalization interface within the structure, 
while IDNA trying to stay away from it.

Draft-liana-idn-map-00.txt has described solution to CJK 
problems, satisfys both TC/SC and Kanji, Hanja for 
independent interpretations,  which is the problem 
you are trying to put in layer two without even a clear 
picture how to deal with them, which is also this WG is 
trying to scope out of  this list at this moment. 

So, James:

I have been discussed in the last several months:
1)  from details of programming of a string  anaysis
   to codepoint flow in a system control;
2)  from UCS codepoint as an IDN identifier to what a 
   character real is about;   
3) from one script to scripts implied in UCS table
   to user requirements of using them;
4) from one codepoint flow from the user to IDN to
  DNS and back to IDN to web page to system analysis
5) from one codepoint in CJK leads to trademark 
 disbute concerned by WIPO;
6) from Armenian "n" mixed use with Latin "n" to 
 illustrate the CJK problem, to imply blanket treatment
 of UCS codepoint is dangerous; 
is just the fool jumps in, while DNS experts laughing 
in sleeves.

My discussion of expert linguists views on written
 languages in the world, 
My promotion on phonetic codepoint encoding for the 
 users and facilitating globle communication, 
My request for Unicode experts' help on codepoints 
 issues, 
My linguistic experiences shared on this list,
 are all multilingual and distructive to 
Internationalized Domain Names efforts, and belongs
to the "Tangled Web". 

I have been stupidly enough to believe that 
when I said "CJK has to be treated in a data-centric 
programming fashion" will help to communicate 
why TC/SC has to be in with [nameprep].  All of 
these are language related and so are out of the scope 
of this group.  Thanks, Chair, and the Sacred group!

Regards,

Liana

---

From: liana Ye <[email-masked]>
Date: Wed, 5 Dec 2001 10:14:29 -0600

> comparable to Latin case folding.

Excuse me for jump in, I have been keep silent on this 
view,  and I'd like to comment on this issue now. 

TC/SC is not merely a 1-1 operation, if you only compare it 
with Latin case folding in what the names imply:

TC/SC is a subset of Han, and Han is subset of C,J,K.
Latin is a super set of English, French,....

Can you see the flaw on such a comparison?

So when you look at Latin in the context of UCS code points, 
since UCS is the set we are hoping to use blanketly in IDN,
then Latin is a subset of (Latin + Armenian + Cyrillic + Hebrew)
since I think this is the area that Latin is mostly likely be 
used too.  

So this means if you compare TC/SC set of 1-1 cases
then the  Latin is 1-1.

If you compare TC/SC with 1-n, n-1, 1-1, that is in Chinese, 
then Latin should be put into UCS Plane 0, 1, 2 too. 
So this Latin is n-1, 1-n too.

If you compare TC/SC in the sense of C,J,K block, 
then Latin + Armenian is the minimum case to think about.

Cheers.

Liana

---

From: "Michel Suignard" <[email-masked]>
Date: Wed, 5 Dec 2001 12:09:00 -0800

Liana, stop associating Armenian with Latin in your explanation. All
writing systems based on Latin and the single writing system using the
Armenian share nothing except maybe some punctuation. It doesn't make
sense to make a parallel between
(Latin + Armenian + Cyrillic + Hebrew) and (CJK), because in the first
group no writing system share characters between the subsets (although
I would even object at creating such a 'logical' collection of largely
unrelated scripts), while in CJK all writing systems use characters in
the same CJK blocks.

I doesn't help to explain the issue of TC/SC which is a valid concern
for CJK users by using flawed analogy to a non existing model.

I myself see a need to help Chinese users deal with TC/SC, but I don't
see it to belong in the scope currently covered by IDN.

Michel

-----Original Message-----
From: liana Ye [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2001 8:14 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Layer 2 and "idn identities" (was: Re: [idn] what are the
IDN identifiers?)

So when you look at Latin in the context of UCS code points, 
since UCS is the set we are hoping to use blanketly in IDN, then Latin
is a subset of (Latin + Armenian + Cyrillic + Hebrew) since I think this
is the area that Latin is mostly likely be 
used too.  

Cheers.

Liana

---

From: "Michel Suignard" <[email-masked]>
Date: Wed, 5 Dec 2001 16:52:40 -0800

This has nothing to do with the CJK TC/SC issue. It should be a
guideline to registars to avoid registering mixed scripts 'names' when
they don't make sense. And finding any similiarities between Latin
characters and Armenian characters is a far fetched example. It doesn't
take much when reading an Armenian document that it is not Latin, even a
single word is sufficient. Thinking that Armenian or Hebrew for that
matter could be confused with Latin characters is simply incorrect.
It is a global issue of any large character set repertoire that you may
have some confusion possible between 'look-alike' characters. Nameprep
is there to simplify somehow the issue, registars guidelines are another
part .

And I don't know what you are talking about when you say that you know
the user's language from input processing, globalized platforms have
input mechanism that are typically independent from language context.
The only thing that is known at input time is a code point. Upper layers
may decide to apply heuristic to guess a language but that is clearly
beyond the scope of input mechanism in modern input processing
mechanism. And there is not such a thing as the selection of a 'language
symbol set'.

The only case where there is a reasonable determination of 'language'
for input is East Asian Input Method Editors (IMEs), and it could be
reasonable to assume that an application layer could offer some TC/SC
services before feeding the code points to a DNS service in that case
for CJK characters (but even that is not a simple case to solve because
of the contextual ambiguity as mentioned several times in this forum). 

Frankly you are not helping by creating these unrelated 'analogies' with
other languages and scripts that have nothing to do with the issue at
hand.

Michel

(PS I should add that I am also a Unicode technical director and the
project editor for ISO 10646)

-----Original Message-----
From: liana Ye [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2001 11:29 AM
To: Michel Suignard
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

It doesn't matter from input processing, 
because you know the users' language. It is 
defined by the user when they select the 
language symbol set.  

But when you turn those symbols into codepoints
and strip the language context, then comparing 
them in languageless context of IDN, the problem is
arised.  That is the reason I have to put Latin
together with Armenian to make the CJK problem 
a little easier for people do not know CJK.  There are 
6 lower case letters similar with Latin [a-z].

Liana

On Wed, 5 Dec 2001 12:09:00 -0800 "Michel Suignard"
<[email-masked]> writes:
> > >> SC/TC equivalence itself is far simpler than the "four winds,
> two
> > eggs"
> > > in order for TC/SC to be done with a reasonable amount of
> accuracy
> > (i.e.
> > > orthographically).
> > 
> > Thanks for saying with some authority what I have apparently been 
> > unable to communicate effectively, namely that TC/SC is not merely a

> > 1-1 operation

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 7 Dec 2001 13:14:20 +0800

> To get IETF interested in a solution, there are typically two step.
> 1. Conviencing the IETF it is a worthwhile problem to solve
> 2. Presenting the solution to the IETF

...and conviencing the IETF it is a feasible solution

james

---

From: liana Ye <[email-masked]>
Date: Fri, 7 Dec 2001 00:21:13 -0600

On Fri, 7 Dec 2001 11:36:37 +0800 "James Seng/Personal"
<[email-masked]> writes:
> Liana,
> 
> I think you are way out of line here so please drop that line of
> argument, especially one which get personal.
> 
> You may be frustrated at a evil that does not exist. I shall try to
> summaries what John's email to Deng few months back said, hope that
> will help you understand the IETF.
> 
> For TC-SC, I think the group is pretty much convienced of the 
> problem
> and something we should at least attempts to solve. We already cross
> that barrier. Any further examples of why TC-SC should be solved etc
> would only frustrate others who is already in part 2 of the problem, 
> ie  finding the solution. 

I did not know we have that consensus until now.

> Any analogy of other scripts to TC-SC is never going to be accurate,
> whether you use Latin + Armeniam, or Japanese, or anything. Human
> language by definition is complex, that makes our job even harder, 
> and
> each language is unique in its own way. In this sense, actually 
> Michel has a point, more than you care to admit.

If I admit it, it would be taken as there is no reasonal 
solution for us too.  

> Going back to our topic of the two step, given that the group is in 
> part
> 2, what we need are proposed solutions. And so far, I dont think the
> group here is convienced of any solution is worthwhile to pursue.
> Sometimes we may have to say, "Sorry it is not possible to be done 
> with
> the existing technology we have now" even though we may agree with 
> part 1.
> Repeating part 1 again and again will not help anything because we
> already convienced of it, just not part 2, the solution.

I am glad that you are telling me, we are in step 2 now. 

> To give you an analogy (one that is harder to dispute of course :-),
> when IDN first started, we always on a basis that the group may 
> declare
> "no solution" as the conclusion. In fact, we may jolly well still do 
> so now, ie, we declare "no solution".
> 
> And to give you another example of the 2 step process, reordering is 
> one 
> which we have a reasonable solution (part 2). Unfortunately, the 
> group
> here is not convience at the problem it solves is worth solving 
> (part 1). In IETF, this is typically known as "solution looking for a
> problem".  Therefore, do we still keep reordering in the pool in 
> hope that there will be a "problem" which will crop up in the future,
or 
> lets drop it? It is a question the group have to ask ourselves.
> 
> -James Seng

Okay, let us move on then. 

Reordering is an effective technique used by itself 
when data organization is not a primary concern of a 
system design.  If the whole UCS flatly goes into AMC 
and scrambled up, reordering adds to it and gaining
a few bytes, the complexity is not a big issue.  No one is
going to care after 5 years when it become stable and 
in place, no one is going to debug it either anyway.  
Most of us are going to enjoy the few bytes we have 
saved here.   If  the idn architecture goes for a flat 
Unicode treatment, I say keep it.

My concern is the UCS code table is already complex 
for us to deal with, and I do respect the Unicode 
techinical directors  who have done a hell of a job to 
organize them into the current form.  This is the 
first step of data-centric programming. 

1) The current codepoints organization provides 
  reasonable clue for us to use language tag 
  to solve our problem, the tags are dependent to
  the positions of the codepoints imply, it shall not
  be altered by reordering;  
2) Phonetic codepoint encoding will enable us to 
  diagnosis codepoint problems in DNS, which is
  dependent on the UCS code organization too. 
If we are using language tag and phonetic encoding
then the majority of IDN names are sortable and 
diagnosable in DNS, which are not subjected for 
 AMC encoding.  This is my assumption,  a readable 
IDN naming in DNS format will be much in demand, 
such that  the code points, left out of phonetic encoding, 
to be fed into AMC will be scattered cross UCS table, 
and the benefit from reordering diminishes.  In either
of the above cases, I say drop it.
 
Liana