Re: [idn] ACE16x (An enhanced version of DUDE)

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

> That is a little simpler, yes, but base32 is not very complex.  Here's
> the C code:
>
It is simpler then... I know it is not a huge improvement... just my two
cents to the solution really.

> I proposed this map because I thought the slight increase in complexity
> was well worth reducing user frustration caused by transcription errors
> between 0/O and 1/l.
>
how likely will regular users type in ACE names?  If you expect that to
happen a lot then IDN is a failure...?...
Also, with ACE16x, a knowledgable system admin will be able to extract
codepoint information from the first codepoint and maybe be able to identify
the langauge of a domain.  I think this is also a worthwhile feature.

> >    - The initial value is set to 0x30 so that all domains beginning
> >    with a digit will be shorter when encoded
>
> That's a judgement call.  0x30 and 0x60 are both reasonable.  I chose
> 0x60 because it was my hunch that it would be useful more often.
>
agreed... the reason for 0x30 is as I have said is that I can see that a
leading digit would probably be more likely than a leading English letter
for a Chinese name, and it is the Chinese names that character spaces
becomes most precious in ACE.

> >    - ACE16x simply hex dumps most quartets improving process time
> >    both in encoding and decoding.
>
> Doing mapping using a small table is pretty quick, and besides, the
> process time of ACE is small compared to nameprep.
>
Destination servers/resources such as the http server probably wont have to
do nameprep but might have to do ACE if the display is to be consistent.
Which means ACE will be performed by servers so I think the process should
be as concise as possible.

Edmon