ICANN ICANN Email List Archives

[ft-implementation]


<<< Chronological Index >>>    <<< Thread Index >>>

TWNIC’s Comments on Draft Implementation Plan for IDN ccTLD Fast Track Process

  • To: ft-implementation@xxxxxxxxx
  • Subject: TWNIC’s Comments on Draft Implementation Plan for IDN ccTLD Fast Track Process
  • From: Erin Chen <erin@xxxxxxxxxxxx>
  • Date: Wed, 07 Jan 2009 18:41:57 +0800

TWNIC’s Comments on Draft Implementation Plan
for IDN ccTLD Fast Track Process

7 January 2009

In response to the ICANN call for the comment on the Draft
Implementation Plan for IDN ccTLD Fast Track Process, we would like to
submit some of our suggestions and recommendations.

1. Handle the IDN variants as equivalent in the ccTLD with the associate
IDN table

It is positive that ICANN clarifies the information about the notion of
IDN tables on 26 November 2008. The Draft Implementation Plan for IDN
ccTLD Fast Track Process is come out according to IDNC Final Report and
complied with IETF IDNA standard and ICANN IDN Guideline. In the ICANN
IDN Guideline, it indicates that it is the guidance for implement IDN,
not only in the second-level domains but also in the top-level labels.

Per the IDNC Final Report and consistent with the ICANN IDN Guidelines,
an IDN table support by an IDN registry, which means the IDN table will
be implemented on the second-level domains, and consistently, its
top-level domain. That means the whole IDN labels will implement the
same IDN table.

However, if ICANN do not handle the IDN variants as equivalent in the
ccTLD with the associate IDN table, it would raise the users’ confusion
and destroy the Internet order. At least an alternate BLOCK or RESERVE
solution with the associate IDN Table come out to go with the IDN ccTLD
Fast Track, would avoid most of the potential problem. So, we strongly
advise the Draft Implementation Plan for the IDN ccTLD Fast Track
Process must take this issue into account.

(Note: The suggestion on consistence of terminology: Regard the “IDN
table”, “character table”, “language/script table”….etc., if they mean
the same thing, it is better to be consistent. Or, there should be more
explanations about each of them.)


2. Details regard String Confirmation Process

The details are not clear regarding the DOCUMENTATION provided by
linguistic expert or organization and the String Confirmation Process.
For instance, the definition and format of the endorsed documentation
required, the selecting criteria and formation process of the linguistic
experts who perform the linguistic process check, the process of
checking the documentation submitted by the requestor, and the time
schedule and process details, etc. We suggest ICANN should clearly
define and announce the details as early as possible, and retain the
reasonable time frame for the potential requestor.


3. The ultimate mission of linguistic process check is to assure the
aspiration of the local community

Regarding the UNGEGN manual, as we know, it is one of references for the
name of territories. However, it should not be the only one reference,
which has some inconsistent with some other standard (Ex: ISO 3166-1).
How to handle the inconsistent in the fair and just way to conform to
current status is crucial. In the case of conflict occurred with local
community cognition and requirement, paying respect to the local
community’s choice should be taken into account.

In 5.1.1 The Preparation Stage of Module 5,,it mentions that the
requestor needs to identify: Language( or script), selection of the
string, and IDN Table, as well as the documentation of endorsements
including:
“
1. Support from the country or territory that the selected string is a
meaningful representation of the country or territory name.
2. Support from the country or territory for the selected registry operator.
”
Corresponding in the 5.5.2 String Confirmation Process, “the String
Confirmation process is initiated with a validation that the process for
self-certification of linguistic requirements is completed”.

According to the criteria defined in the Draft Implementation Plan, the
selected string is endorsed by the local community and the linguistic
expert, which is sufficiently to reflect the current status and the
choice of the local community. According to RFC1591, the essential
responsibility of (IDN) ccTLD is to serve the local community, and we
think that the external verification of the local community’s choice is
inappropriate. If verification process is a must, what the external
linguistic experts can do is to check whether if the selection of string
is following the procedure, but not to deny the local community’s choice.


=============================================================
Erin Chen
Senior Engineer
Taiwan Nerwork Information Center (TWNIC)
4F-2, No. 9, Roosevelt Rd., Sec. 2, Taipei 100, Taiwan, R.O.C.
TEL:886-2-23411313‧FAX:886-2-2396-8832



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy