At 10:24 01/10/22 +0900, Soobok Lee wrote: >We have no TAGALOG characters X,Y now. >After we finalized nameprep/ACE, >TAGALOG script may be added to Unicode. >Then, > > > 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, > >unassingned code points are allowed in query from old version nameprep. >X.com Y.com are passed through into DNS servers which have no stored tagalog >labels before TAGALOG is added, but begin to accept it after it's approved >& added.
That makes a lot of sense. Or do you want to say it doesn't. > > 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. > > > > > 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. > > >this case is described in stringprep-00, section 6.3 paragraph 3. >that query should fail. Old nameprep/ACE applications should send >Y.com instead of X.com even when it gets native X.com from html page >(human input should contain only Y.com, not X.com). Well, it shouldn't get X.com from the webpage, because the web page should also be normalized. Please see http://www.w3.org/TR/charmod :-). Regards, Martin.
