[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Character Variant Deployment at VeriSign
Answers below.
Pat
> 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