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

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message ----- 
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Soobok Lee" <lsb@postel.co.kr>; <idn@ops.ietf.org>; "Martin Duerst" <duerst@w3.org>
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
>