[idn] summary of reordering discussion

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

----- Original Message ----- 
From: "Bruce Thomson" <bthomson@fm-net.ne.jp>
To: <idn@ops.ietf.org>
Sent: Friday, November 09, 2001 10:24 AM
Subject: Re: [idn] (bias) summary of reordering discussion


> I took a good look at the re-ordering draft, and would like to offer
> my opinion. The research is pretty thorough, and it is clear that a
> (conceptually) simple approach will give us an improvement over
> the non-re-ordered case.
> 
> However, although the concept is simple, the details are complex.
> It is easy to say that the complexity is buried in the code in some
> library and will not affect us, but actually it will affect us, as
> it has to be frozen into permanent, public document, and adds
> a whole new dimension of complexity to the specification of
> something which could have been quite simple.

Yes. The output RFC may have  huge list of reordering parameters and
may look complex to authors and readers, not to the end users.

As i pointed out in the draft, NFKC/mapping/prohibition lists in nameprep
also have  huge lists of characters. 
Nameprep's casefolding table contains roughly over 3000 code points involved.
Nameprep's prohibition/unassigned code points  tables also have huge lists
of code  ranges, 70/400, respectively. 

Current REordering lists 5500 code points involved in its table.
Just +2000 code points compared to that of nameprep.

Moreover, nameprep hidden complexity around  NFKC is hidden in the UTR15 document .
REORDERINg has no external authority to quote character frequency 
statistics  in order to make the drafting work look simple
as nameprep refers to UTC NFKC.

Nameprep and reordering  *deal with individual code points*.
That's the source of the inevitable document complexity.

Soobok Lee


> 
> I say that the benefits do not justify all of this.
> 
> Bruce
>