[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Character Variant Deployment at VeriSign

The TWNIC table was chosen so that we could minimize the exposure that we had with Chinese registrations and it was publicly available.  We are aware that this table will be superceded in the future and we will reapply that new table to the registration base. 
We can only apply rules to the registration base as they are available.  We are looking forward to seeing what KRNIC develops.
However, this leads to the very real problem of how the tables generated via the various nics get "approved" for deployment?
-----Original Message-----
From: AyeShil Jeon [mailto:asjeon@xxxxxxxxx]
Sent: Monday, May 19, 2003 8:31 AM
To: Kane, Pat
Cc: idn-reg-policy@xxxxxxx
Subject: FW: Character Variant Deployment at VeriSign

Then what if we define the table which contains only permissible characters in Korean
among Hangeul and Hanja including LDH with no variants at all,
would you apply it to your registration policy?
[Kane, Pat] We don't look at this as a character variant issue, but an IDN support issue.  If it makes sense to limit the number of code points available for a valid Korean registration, then we will consider it.  As a note, out of 900k plus IDNs in the com/net testbed greater than one third contain Hangul characters.  Out of those registrations, only 9 combine code points out of the character sets that you reference.  Six are combined with Katakana characters and three are combined with Hiragana characters.  It seems to me a lot of development and maintenance work go into this solution for something that rarely occurs naturally.
[AyeShil Jeon]
The key to the problem is input/display difficulties in the current computer environment 
based on KS X 1001:1998 (commonly known as euc-kr, korean local charset)
with the boundary of 2,350 Hangeul syllables.
Unix/Linux support 2,350 Hangeul syllables and 4,888 Hanja and most PDA or pocket PC
are in the same boat to prevent exhausting of memory although Hangeul related solutions
are gearing up being at the mercy of supporting the 11,172 Hangeul syllables, as a
Unicode-based system in the near future.
But the reality of today to deploy IDN is different a little bit from that.
And would you describe your position about below problem that
>might be happen in Hangeul :
>Some visual ambiguities such as some example between "ㄱㅏ"(U+3130 U+314F)
>"가"(U+AC00) which might make Internet users confused and bring in dispute,
>if VGRS keeps permitting those Hangeul Compatibility jamo.
>So there are only Unicode Hangeul Syllables in the table KRNIC gets underway. 
[Kane, Pat] Without a table describing what is permitted within a Hangeul registration it is difficult to have a position.  When following the IDNA RFC's there is nothing to restrict the use of those Unicode code points within IDN registrations. 
[AyeShil Jeon]
What brought VGRS here to adopt TWNIC's table?  Isn't it the registration policy to consider
each countrie's language-specific issue?  If you don't have such a table describing what is permitted
within a Hangeul registration,  I'm looking forward to seeing some positive sign of VGRS to adopt it when KRNIC make it.
Thank you,