|
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 XXXX@YYYYYY.jp
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
--------------------------------------------------------------------------------
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]. |