----- Original Message ----- From: "James Seng/Personal" <[EMAIL PROTECTED]> To: "Soobok Lee" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Martin Duerst" <[EMAIL PROTECTED]> Sent: Sunday, October 21, 2001 11:22 PM Subject: Re: REORDERING: stability issues and UTC solutions
> 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. I read http://www.unicode.org/unicode/standard/policies.html and http://www.unicode.org/unicode/reports/tr15/#3.1_Corrigendum. Would anyone suggest more ? Soobok Lee > > > 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. YEs. When New script is added. Soobok lee > > > 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 >
