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

RE: Character Variant Deployment at VeriSign



Answers below.
 
Pat
 
-----Original Message-----
From: AyeShil Jeon [mailto:asjeon@xxxxxxxxx]
Sent: Saturday, May 17, 2003 12:50 AM
To: Kane, Pat
Cc: 'Paul Hoffman / IMC'; idn-reg-policy@xxxxxxx
Subject: RE: Character Variant Deployment at VeriSign

Thank you for your information. A few questions below.
 
> >By "Chinese" here, I assume you mean "CJK", yes? Unless I'm missing
> >something, VGRS doesn't have a way to know if a label that contains
> >only CJK and ASCII characters is Chinese, Japanese, or non-Hangul
> >Korean.
>
> The code points are CJK.  As you point out we have no way of knowing if
> these registrations are Chinese, Japanese or non-Hangul Korean so we will
> treat them all as Chinese when applying mapping rules.
>
> VGRS will be using a table that is available from TWNIC.
 
When KRNIC submits the table which contains the non-Hangeul (Hanja) Korean
in the near future, you are going to combine the table with the TWNIC's into one?
If not, you adopt it differently based on language tag?
 
[Kane, Pat] Any table that comes available will be deployed into production no earlier than 8/23 and if it is not published soon, it will probably be after that.  At that time, the language tag will be deployed.  As each table may be different, it is difficult to say how the tables will be deployed until they are published or at least until we see an early version of them.
 
> >-  We do not consider the bundles created to be the final correct bundles
> >since we know that we will be replacing the table.
>
> >It would be great if you (or any other registry!) could keep us
> >informed on how the table-making process is going. This is
> >particularly valuable for CJK, where different groups have made
> >different attempts at variant tables.
 
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.
 
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. 
 
 
Pat Kane
IDN Product Manager
VGRS
pkane@xxxxxxxxxxxx