ICANN ICANN Email List Archives

[sync-idn-cctlds]


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

Comment on Proposed Implementation Plan for Synchronized IDN ccTLDs

  • To: sync-idn-cctlds@xxxxxxxxx
  • Subject: Comment on Proposed Implementation Plan for Synchronized IDN ccTLDs
  • From: Hong Xue <hongxueipr@xxxxxxxxx>
  • Date: Sat, 10 Apr 2010 11:57:18 +0800

My previous submission on April 8 cannot be downloaded. Please delete that
one and replaced with the following text. Thanks.




Comment on Proposed Implementation Plan for Synchronized IDN ccTLDs

Hong Xue, Chinese Domain Name Users Alliance

April 8, 2010



The Proposals seem a follow-up to the Fast Track IDN ccTLD Implementation
Plan. Given that a request for a synchronized IDN ccTLD must have completed
the String Evaluation in the Fast Track Process, the proposals, obviously,
are patches to redress the insufficiency or unthoughtfulness of the original
one. Although no one would really appreciates the patchwork, which would
inevitably complicate the implementation, these remedial proposals do
capture the most critical issues, particularly multiple corresponding
strings deemed equivalent to one IDN ccTLDs. The issues are by no means new
to the community or ICANN. During the policy develop process and
implementation plan drafting process, the string equivalence or variants
issues were repeatedly, consistently and vocally addressed by a few
non-Latin script communities. For instance, both ALAC and APRALO made the
submissions. After so many rounds of public consultations, it has been
widely understood that solution to equivalent strings or variants is the
center piece for implementation of IDN ccTLDs in the relevant IDN
communities. No solution available, hardly IDN ccTLDs workable. This is why
there were strong repercussions from the IDN communities after the Fast
Track implementation took off. It is indeed positive that ICANN eventually
moves to solve such “significant” problem for the communities. If the Fast
Track was crafted to address the pressing need of non-Latin script users and
non-solution to equivalent strings or variants would pose “significant
problem for the community”, I cannot help but ask why such measures could
not be incorporated into the implementation plan in the first place and have
to be deferred to such a supplementary document.


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

Privacy Policy | Terms of Service | Cookies Policy