Subject: [idn] IDNA ACE fallbacks and REORDERING

From: "Soobok Lee" <[email-masked]>
Date: Fri, 12 Oct 2001 10:46:21 +0900

It is well known that  han font set require very big memory (RAM) spaces.

For 16*16 font,  20992 *  16*16 * (1byte / 8bit) =  0.6 mega bytes
For 24*24 font,  20992 *  24*24 * (1byte / 8bit) =  1.5 mega bytes

For truetype fonts, it may reach 10 Mega bytes.

Therefore, many non-asian handheld devices and even PCs 
won't support  han/hangul rendering to save precious memory resources.
In that case, IDNA-application "SHOULD" show the ACE format of han labels
as the enclosed IDNA section recommends.

THat is, if you send an email to your european friend  with your [email-masked]
idn email address,  your friend's PDA (or PC) may not display your han/kana email address
but instead will display ACE format of your email address.
In that case, email address verification relies on eye-comparisons.
Without REORDERING applied, the length of the fallback ACE email address will be
much longer than could have  been shrinked by 10 characters with REORDERING
for many typical email addresses.
Hundreds of longer ACE email addresses will fill  the address book, and exhaust
precious flash memory resource in his/her PDA.

Like DNSSEC, future DNS extensions may require more spaces for long resource 
requests/responses. REORDERING help to solve the problem of lack of spaces 
in DNS packets. Even now, shorter ACE labels will  make it
easy  transcriptions and administrations and eye-comparisons. 
Many non-asian people would prefer to see and verify shorter ACE labels rather than
exotic han/hangul native-script labels which they cannot recognize at all.
Copy&Paste becomes more convenient with shorter ACE labels.

Full Reordering support for major 12 scripts  only requires 13 kbytes memory ram spaces.
This small memory requirement is much less than those for huge font sets,legacy-to-UCS
mappings, and NFKC codes and case mapping tables and prohibition lists in nameprep.

If you are doing cost/benefit analysis on REORDERING, please take these factors into
your considerations.

Thanks.

Soobok Lee

--------------------------------------------------------------------------------

http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-03.txt

2.1.4 Avoiding exposing users to the raw ACE encoding

All applications that might show the user a host name that was received
from a gethostbyaddr or other such lookup SHOULD update as soon as
possible in order to prevent users from seeing the ACE. However, this is
not considered a big problem because so few applications show this type
of resolution to users.

If an application decodes an ACE name but cannot show all of the
characters in the decoded name, such as if the name contains characters
that the output system cannot display, the application SHOULD show the
name in ACE format instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to transfer
the name correctly to other programs. Programs that by default show the
ACE form when they cannot show all the characters in a name part SHOULD
also have a mechanism to show the name with as many characters as
possible and replacement characters in the positions where characters
cannot be displayed. In many cases, the application doesn't know exactly
what the underlying rendering engine can or cannot display.

In addition to the condition above, if an application decodes an ACE
name but finds that the decoded name was not properly prepared according
to [NAMEPREP] (for example, if it has illegal characters in it), the
application SHOULD show the name in ACE format and SHOULD NOT display
the name in its decoded form. This is to avoid security issues described
in [NAMEPREP].