[idn] ACE37

["Edmon" <edmon@neteka.com>]

One thing I forgot to point out:

From: "Adam M. Costello" <amc@cs.berkeley.edu>
> It doesn't look as simple as DUDE to me.  To me it looks no simpler than
> AMC-ACE-W, which is as efficient as ACE37 for CJK, as efficient as DUDE
> for single-row scripts, and more efficient than DUDE for Latin-based
> scripts.  Whereas AMC-ACE-W's complexity is in a state machine, ACE37's
> complexity is in encoding/recognizing lots of different patterns.

DUDE uses a similar algorithm to determine the significance of diff, which
in turn determines how many b32 characters to use:

diff value                                    DUDE Form
----------------------------------------------------------------------------
diff<=0xF                                 <"0"+quartet>
0x10<=diff<=0xFF                  <"1"+quartet><"0"+quartet>
0x100<=diff<=0xFFF              <"1"+quartet><"1"+quartet><"0"+quartet>
0x1000<=diff<=0xFFFF
<"1"+quartet><"1"+quartet><"1"+quartet><"0"+quartet>
0x10000<=diff<=0xFFFFF
<"1"+quartet><"1"+quartet><"1"+quartet><"1"+quartet><"0"+quartet>
0x100000<=diff<=0x10FFFF
<"1"+quartet><"1"+quartet><"1"+quartet><"1"+quartet><"1"+quartet><"0"+quarte
t>

Here you see that there are 6 different scenarios as opposed to ACE37's 5
scenarios.  Both DUDE and ACE37 needs to determine the significant bits of
the resulting diff to come up with the correct form.  So perhaps it doesnt
look as simple (because I created these charts in the draft), but in effect
it is the same.  You could refer to the procedure comparison I did in my
draft in Section 1
<http://www.ietf.org/internet-drafts/draft-chung-idn-ace37-00.txt>


Edmon