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

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

----- Original Message ----- 
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: <idn@ops.ietf.org>
Sent: Wednesday, October 24, 2001 1:32 AM
Subject: [idn] (bias) summary of reordering discussion


> On the questions posted:
> 
> 1. Efficient - I accepted that reordering produce a shorter ACE string,
> sometimes as much as 20%. This means instead of a "zq--zxcvbnmasdfg"
> label, I get a "zq--zxcvbnmasd". I do not buy the arguments it is
> helpful to naked eye, to memorised or save RAM however.

  the 20% is just the mean average. 40% improvement is not rare for
   most frequency words, especiall in the case of hangul 9-letter KRNIC ( 29->16).
   and Tokyo Univ in Han ( 11->7 ).

  i mentioned the limit in mobile device's narrow LCD panel and precious ram/rom resources.  
  Also Good for visually impaired one or childrens and elder ones and for me .
  
  In the case of  sub-ML.ML.com, The sum of saved characters
   are multiplied by 2 with reordering.

  Take this into your considerations.

> 
> 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.


> 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.

> 
> 4. Stability of reordering - Lee's countered with the arguments that
> reordering tables would never changed. I am not sure if that is possible
> but I agree with the assessment that it is possible to design reordering
> to be stable. However, I like to see explictive statement in future
> draft.
> 
> 5. Future additional of code points / changes to reordering - Lee's
> proposal is a two prefix solution, using prefix as a versioning tag. I
> do not like to solve a problem by creating others, especially one which
> makes it even more complex. Lee have yet to address the process of how
> future additional of code points or changes to reordering could be done.
> (IDN WG is not going to exist forever...I dream of finishing our work
> one day).

 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.

 You have misunderstanding of my proposal. 

> 
> 6. Reordering is never ending task - Lee's countered that so is
> Nameprep. My thoughts is two wrong dont make one right. (OTOH, Nameprep
> which is based on UTC work have explicit principles on how it can be
> done. And Nameprep is not subjective to frequency analysis changes which
> reordering is)

 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.... 
 

Soobok Lee