[idn] Re: REORDERING: stability issues and UTC solutions

["James Seng/Personal" <jseng@pobox.org.sg>]

Firstly, lets not try to twist the whole argument to Normalization,
which you are doing here. We are talking about Reordering so lets focus
on it.

> My  question was that:
>   1) newly-approved TAGALOG characters X,Y  have   NFC X -> Y,
>   2) old Nameprep/ACE encodes X.com and Y.com as two distinct ACE
labels,
>       because it don't know about NFC X -> Y
>   3) new Nameprep/ACE encodes X.com as the the same ACE label as
Y.com's
>       with NFC  X -> Y.

My shortest answer is for you to read UTR#15. It is already addressed
there.

>   If X.com and Y.com are taken by two distinct registrants, there will
>     be a mess. of course, it should have be blocked by careful
registries.
>   Even if new ACE libaries are distributed, some old ACE tools will
still
>     try to send X.com dns queries which may fail.

No it wont. Patrik Faltstorm have already discuss this possiblities and
the work around this. It was one of the version of Nameprep but I
realised it is no longer in -06.

> Are you saying ?:
>    Tagalog folks may come back  with complaints about old nameprep
>    which has no NFC X->Y, saying "unfair treatment!" ??

No, I am saying REORDERING. Lets keep the topic on REORDERING.

> 1) last resort: somewhat tricky
>
> Future TAGALOG may provides two sets of TAGALOG basic alphabets.
> One set A in official lexicographical ordering and the other set B
> is in frequecy ordering (sub-optimal one OKAY) with 1:1 NFKC defined
> from A onto B.
> Then all tagalog basic alphabets in Set A will be "reordered by NFKC"
> in nameprep , not in ACE. A and B share the same font.
> Then valid ACE labels of TAGALOG script only contains characters from
B.
> This may have some problems in comparisons which i have no full
analysis.

Okay. This should go into ISO10646 SC2/WG2 then.

> 2) UTC solution
>
> IF UTC accepts REORDERING as an official normalization form like
> NF-REORDERING , then we need no such tricks like above, and
> TAGALOG support can be done within that NF in the new
> NAMEPREP steps:  mapping/NFKC/PROHIBIT and then NF-REORDERING .
>
> Frequency tables are always sub-optimal in its nature, and
> marginal frequency fluctuation will occurs to make marginal
> efficieny changes, but in most cases, i am sure, it will benefit
> most of TAGALOG labels, and that's why i push REORDERING into UTC.
>
> In conclusion, 2) is the my preferenece.
> It's the best way for acquiring stability and authority and
applicability
> of REORDERING.

Okay. This should go into UTC.

Both your solution unfortunately cannot be done in this WG.

-James Seng