ICANN ICANN Email List Archives

[gtld-guide]


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

IDN-related Comments on gTLD Applicant Guidebook

  • To: gtld-guide@xxxxxxxxx
  • Subject: IDN-related Comments on gTLD Applicant Guidebook
  • From: "Wil Tan" <wil@xxxxxxxxxx>
  • Date: Mon, 8 Dec 2008 02:22:26 -0500

Following are my personal comments on the draft gTLD guidebook:


-----------------------------
With reference to Section 2.1.1.3.2, p.2-8, String Requirements,
Policy Requirements for Generic TLDs:

"Applied-for strings must be composed of three or more visually
distinct letters or characters in the script, as appropriate."

While this requirement makes sense for alphabetic scripts (including
ASCII), it does not fit the usage model of many east Asian scripts.
For example, many concepts in Chinese, Japanese and Korean are easily
and aptly represented with one or two characters. Imposing this
requirement will preclude them from being used in an intuitive manner
for speakers of these communities.

Recommendation: remove the restriction in accordance with the findings
in the GNSO Reserved Names WG Report (Recommendation #5):

"Single and two-character U-labels on the top level and second level
of a domain name should not be restricted in general. At the top
level, requested strings should be analyzed on a case by case basis in
the new gTLD process depending on the script and language used in
order to determine whether the string should be granted for allocation
in the DNS. Single and two character labels at the second level and
the third level if applicable should be available for registration,
provided they are consistent with the IDN Guidelines."

*http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm



-----------------------------
With reference to Section 2.1.1.3.2, p.2-8, String Requirements,
Requirements for IDNs:

"The label must meet the relevant criteria of the ICANN Guidelines for
the Implementation of Internationalized Domain Names."

Being the registry of the DNS root zone, ICANN should work with the
communities whose orthographies require variant handling for the
formulation of its delegation policies (employing reservation and
bundling if applicable). Examples of such communities are Chinese and
Greek. Specifically, according to the ICANN Guidelines for the
Implementation of Internationalized Domain Names Version 2.2,
Guideline 7:

"Domain registries will work collaboratively with relevant
stakeholders to develop IDN-specific registration policies, with the
objective of achieving consistent approaches to IDN implementation for
the benefit of DNS users worldwide."

Recommendation: ICANN should allow additional variants to be specified
in IDN TLD applications where languages requiring variant handling are
involved. It should also work with relevant stakeholders to develop
policies for the given language, in accordance to RFC 4290*: Suggested
Practices for Registration of Internationalized Domain Names.

* http://tools.ietf.org/html/rfc4290



-----------------------------
With reference to Section 1.3, p.1-16, Information for IDN Applicants:

"Applicants for IDN gTLDs will also be required to provide the
following at the time of the application:"

"1. Short form of string (English). The applicant will provide a short
description of what the string would mean in English."

A string may not have to be meaningful; it could be a new concept
introduced by the applicant.

Recommendation: Change wording to "Intended usage of the string"


"2. Language of label (ISO 639-1). The applicant will specify the
language of the applied-for TLD string, both according to the ISO's
codes for the representation of names of languages, and in English."

In cases where a label is meaningful in multiple languages, the
applicant may not want to restrict registrations only to a single
language. Listing a single language here portrays the idea that it is
the official/primary language of the TLD.

Recommendation: Change "language" to "languages".


Also, it is better to ask for the "Primary Language Subtags" and, if
applicable, the corresponding "Extended Language Subtags" in RFC 4646.

Recommendation: Change "ISO 639-1" to "the 'language' ABNF production
in RFC 4646 Section 2.1"


"3. Script of label (ISO 15924). The applicant will specify the script
of the applied-for gTLD string, both according to the ISO code for the
presentation of names of scripts, and in English."

ISO 15924 has redundant scripts that are unnecessary for this purpose.
It is better to require the Unicode Script property as defined in UAX
#24.

In many cases, multiple scripts are allowed and do not pose an issue.
For example, Han+Katakana+Hiragana is common Japanese, and many
Chinese company names contain characters Latin + Han.

Recommendation: Change "script" to "scripts", and "ISO 15924" to "UAX #24".


"6. Its IDN table. This table provides the list of characters eligible
for registration in domain names according to registry policy. It will
contain any multiple characters that can be considered "the same" for
the purposes of registrations at the second level. For examples, see
http://iana.org/domains/idn-tables/.";

The wording of "the same" is imprecise and may cause confusion.

Recommendation: Change wording to match Section 3.1 of ICANN
Guidelines for the Implementation of Internationalised Domain Names:

"Its IDN table. This table contains the aggregate set of code points
that it makes available, along with equivalent character variants, if
applicable. The recommended table format can be found in the IANA TLD
Repository of IDN Practices."



-----------------------------
With reference to Section 2.1.1.3.2, p.2-8, String Requirements,
Requirements for IDNs:

"Must be fully compliant with Normalization Form C..."

This requirement most likely stems from IDNA2008 uses Normalization
Form C (NFC). However, IDNA2003 uses the more conservative
Normalization Form KC (NFKC) though there is no normative requirement
for IDN2008-compliant software to perform backward compatible mapping.

ICANN should alert the applicants to potential security issues of
applying for a string that is not also closed under NFKC, and to
encourage them to investigate backward compatibility, software and
user input issues prior to submitting the application. It is likely
that such strings will be flagged for string stability review.


Sincerely,

Wil Tan
Zodiac


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

Privacy Policy | Terms of Service | Cookies Policy