Re: [idn] (bias) summary of reordering discussion

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

>   the 20% is just the mean average. 40% improvement is not rare for

The mean is 20% from your data. The result I got using my data is around
12%, which I send you. Either way, I accept it improves efficiency
somewhat.

> > 2. Compression efficient in future since statistic - Lee's counter
that
> > compression "always SHORTER labels than usual". Mathematically, it
can
> > be proven this is wrong (very basic pigeon hole principle).
> >
>   ALready answered. You may have missed that.
>    0.3% hangul labels get longer by 1 character, while 99.6% labels
got shorter
>     by greater amounts. the net gain is always positive for each
length N.

Using *existing* data. I am talking about data in future if/when we
reach saturation. (No, never say we never going to run out. That is what
we say of IPv4).

> > 3. Referencing from established I18N organisation - ISO14651 is deem
> > inappropriate and I agree with it. No alternative was proposed.
>
>   sub-optimal tuning parameters not revealed to outside of ACE. they
need authorities ?  i think it need not.

Yes, I feel strong enough that we should.

>  Already answered. read my recent articles.
>  new reordering support of new script in Tandem with newer nameprep
for
>  the new script. no new prefix needed if there will be no change
>  in existing stable reordering tables.

Okay. Then who and how you going to define these new reordering table?
What is the process? Do we publish new version of reordering RFC? Or do
we do this as an IANA action (if so, where is the IANA consideration).

Does this explain why I really like to see an authoritive source who
would ensure continouity in the work?

>  You have misunderstanding of my proposal.

If you stop changing your proposal in every email, I think I have a
better chance to keep up to date with it.

>  Statistical Frequency is always sub-optimal tuning parameters. better
than not.
>  What's your position on engineering tuning paramters in various
>  protocols ?, eg. Ethernet packet length, ttl, flag length in tcp/udp
etc....

My position? What have protocol tuning have to do with code point
tuning?

IETF is a well-known wire-protocol expert group. We exist original to do
so.
But are we code point expert?

-James Seng