ALAC Statement IDN Issues

This is a combined statement to the current set of IDN issues within ICANN:

1. IDN are complex issues that differs from language to language, culture to culture

On 16th Jan, ALAC published the ALAC Statement on Final Report on Three-Character Requirement and Variant Management:

"ALAC believes that every culture and language is unique. Attempts to uniformly apply rules and restrictions across cultures and languages would inevitably lead to maladministation. Therefore, ICANN should be flexible in adopting different policy for different culture and language in its implementation of IDN policy."

IDN are complex issues that varies from language to language, culture to culture.

For example, IDN Variant for Japanese is an option, but IDN Variant for Chinese is a must-have. The IDN Variants complexity with Arabic-based languages is also different from Chinese-based languages. The former will increase user confusion if delegated to the root, the latter will reduce confusion unless delegated.

The limitation on 3 characters for IDN if removed, is a nice-to-have for many alphabet based languages but would be of utmost importance to Chinese. The degree of urgency also varies.

Therefore, it is understandable that ICANN get confusing feedback from different community with regards to IDN issues. On a same issue, different language and culture community often requires different policy or solution.

2. Synchronized IDN ccTLD for Chinese

The Synchronized IDN ccTLDs is a proposal to resolve some critical problems of the fast-track IDN ccTLD implementation.

Although the proposal facilitated the Board to make the resolution on completion of fast-track string evaluation of two Chinese-character IDN ccTLDs on April 22, which absolutely addresses the pressing need from the Chinese community and is warmly welcomed by At-large community, we have the reservation that the proposal should be generalized to cover the other language and culture.

ICANN may wish to limit the solution to script or language group, which would reflect ICANN's bottom-up, rather than one-set-fit-all, policy-making & implementing character.

3. Not every problem has a technical solution

Been a multi-stakeholders technical coordination body, ICANN seek inputs from and rely on the technical community very often.

But not every problem has a technical solution.

The Chinese SC-TC problem is a classic case. During the early days of IDN, it was proposed that SC-TC be handle within the IDN protocol. There was a long debate among the IETF Working Group participants and a strong push from the Chinese technical community.

If we have resolve SC-TC problem within the IDN protocol, we would not have issues like Synchronized IDN ccTLD. Unfortunately, it is impossible to deal with it at the protocol level because SC-TC mapping is almost 1-1 but not always. More importantly, such mapping will cause problems for the Japanese and Korean, both with also use the same Han ideograph like Chinese.

So when SC-TC was rejected at the protocol level, it encouraged the community, particularly the Chinese, Japanese and Korean to work together on RFC 3743 (Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean). The community understood some problem has to be resolved at the registration and administration policy level.

From RFC 3743:

"Addressing the issues around differing character sets, a primary consideration and administrative challenge involves region-specific definitions, interpretations, and the semantics of strings to be used in IDNs. A Unicode string may have a specific meaning as a name, word, or phrase in a particular language but that meaning could vary depending on the country, region, culture, or other context in which the string is used. It might also have different interpretations in different languages that share some or all of the same characters."

"Additionally, because of local language or writing-system differences, it is impossible to create universally accepted definitions for which potential variants are the same and which are not the same. It is even more difficult to define a technical algorithm to generate variants that are linguistically accurate."

It is technically impossible to resolve Chinese-based languages community at a technical level. Similarly, there are other languages likewise. Therefore, ICANN should not be deter from making a policy decision even if a technical solution does not exist if it serve the larger good of the community.

4. Act Global, Be Local

ALAC would like the encourage ICANN adopt the principle of "Act Global, Be Local" in the handling of IDN issues.

IDN matters to the heart of every internet users because it deals with their names in their native language. ICANN attempts to create generic policy would only result in causing linguistic problem for the different language community. Equal treatment imply equal pains for all.

ICANN should be more sensitive on the needs of different language group and be willing to adopt different policy for different group. While it may sound daunting to have different policy for potential hundreds of languages, we believe it will encourage more participation from different language/culture group within ICANN policy formation. More importantly, this may be the only viable and plausible solution to handling of IDN.

ALAC noted that the team recommended that variants not be delegated as TLD at this time. We believe that this is not an acceptable limitation for certain language group such as Chinese. More importantly, there are existing solutions to handle Chinese variants (RFC 3743 and RFC 4713) but there is no solution to handle variants in all languages. There is no reason for Chinese to be hold back due to the latter.

ALAC also noted that the team recommended further studies to be made on 1 character IDN TLDs. While this limitation are generally acceptable to most languages community, it has serious impact on Chinese. Every Chinese character is a "word" that has a meaning. As of Unicode 5.2, there are 74,394 Chinese character encoded. Once again, there is no reason such limitation remains for the Chinese.

We do not believe ICANN has the intention to marginalize any community specifically. But the recommendations as proposed have put Chinese Internet community in a disadvantage position.

James Seng
ALAC, IDN Liaison

Please find the following comments by Hong Xue.

2. Synchronized IDN ccTLD for Chinese

The Synchronized IDN ccTLDs is a proposal to resolve some critical problems of the fast-track IDN ccTLD implementation. Although the proposal facilitated the Board to make the resolution on completion of fast-track string evaluation of two Chinese-character IDN ccTLDs on April 22, which absolutely addresses the pressing need from the Chinese-language community and is warmly welcomed by At-large community, we have the reservation that the proposal should be generalized to cover the other language and culture. ICANN may wish to limit the solution to script or language group,which would truthfully reflect ICANN's bottom-up, rather than one-set-fit-all, policy-making & implementing character.

contributed by guest@socialtext.net on 2010-04-26 03:56:02 GMT

  • No labels