Internationalized Domain Names (IDN) Committee
Discussion Paper on Non-ASCII TLD Policy Issues
Summary of Public Feedback - Round 2
NOTE: This page quotes
excerpts from comments submitted via email in response to
the IDN Committee's second, revised Discussion
Paper on Non-ASCII TLD Policy Issues.
The quoted excerpts are presented in a structured manner, are meant
to be illustrative,
and are not necessarily full quotations.
I. 'LANGUAGE' AND 'SCRIPT' DEFINITIONS
Response from Kilnam Chon
The language character set, rather than language itself (in particular spoken language) is the one to be associated here. For example in Disadvantage, "Chinese-speaking community" is mentioned. In reality, we are discussing on CJK code (commonly called "Chinese Character"), not the Chinese-speaking. I hope IDN Committee Chair who is from Japan must be able to understand this issue. Technically speaking, we are dealing with the WRITTEN language for DNS, and the verbal (or spoken) DNS is not ready now (and not in near future).
Response from Martin Duerst, W3C Internationalization Activity Lead, PSO-PC Member
The paper acknowledges the basic difference between 'language' and 'script' in footnote [4], but I'm not sure that this distinction was always adequately considered in the body of the paper. Throughout the paper, the word 'script' appears 10 times, the word 'language' 53 times. This should be much more balanced. It is very important to realize that the number of languages is in practice at least one, and maybe two, orders of magnitude higher than the number of scripts.
I would like to use two examples:
Example 1)
Locate (or ask a properly legitimate body like the ISO to create) a table equivalent to ISO-3166-1, expanded to include names in all non-ASCII scripts. This would be a massive undertaking with enormous political complications.
It is good that the above paragraph says 'script', because while working on creating ccTLDs in various scripts seems to make sense, creating ccTLDs in all possible languages seems not advisable. [On the other hand, the above paragraph uses 'names', which are different per language, so this should be changed to something like 'identifiers'.]
Example 2)
A limit to the total number of TLDs eligible for delegation to a given geographic unit might be set at a number equal to the number of its official languages.
Here, 'languages' is used, but it should probably be 'scripts'. For example, Switzerland has three official languages, but should be very well served with the .ch TLD because all these languages use the Latin script.
The whole paper should carefully be reviewed for the use of the terms 'language' and 'script', and the choices should be made much more explicit.
Response from Kilnam Chon
Internationalized (Non-ASCII) Top Level Domain (iTLD) is fundamentally a long term issue, and the policy should address the long term issue (not just short term issues). We need to investigate on various issues such as; - Role of ICANN with respect to other organizations - Need to study on fundamental issues such as namespace in various languages as we are doing in Korea, validity of ACE approach,....
III. MIXING OF LANGUAGE CHARACTER SETS
Response from Kilnam Chon
There are three classes of domain names:
(1) ASCII only;
(2) Single language characters with optional ASCII;
(3) Multiple language characters such as Chinese with Thai and others
in this draft.
We need to enforce the second class at this stage with the third class as the long term issue. We need to be able to develop systems to handle single language characters first before we venture into the mixture of the language characters even if we do it. Technically speaking, we need proper localization for each internationalized domain name with well defined local language character set. Administratively, we need such an arrangement across language characters, too.
Response from Kilnam Chon
We need to have good, extensive dialogue with ccTLD community as well as GAC community and other relevant communities before we make any serious recommendation. The ccTLD community has not addressed on this issue seriously yet. Without such a bottom-up process, the consensus development would fail.
V. CULTURAL GROUPS / ETHNICITIES
Response from Kilnam Chon
The section 3 on Cultural Groups/Ethnicities may be merged to the section 2 on Languages since there no distinct difference compared with other sections.
VI. NEW DNS CLASS (FOR NON ASCII TLDS)
Response from Kilnam Chon
We may consider to implement Internationalized Top Level Domains (iTLD) in new class of DNS, rather than with ACE. Since iTLD is of long term issue, we may seriously consider such a radical, and clean approach.
Response from Kilnam Chon
We are defining the namespace for each language by assigning new iTLDs in the language character set. Thus, we need to approach accordingly. In particular, we need to analyze on the "first namespace", which is coEnglish (ASCIIde).
Response from Kilnam Chon
Many of the issues raised here may require academical, extensive workshops to develop necessary technical sound consensus.
IX. INDEPENDENT EVALUATION PANELS
Response from Richard Hill, Counselor, SG2 International Telecommunication Union
In its Discussion Paper on Registry Selection Considerations for non-ASCII Top-Level Domains, the IDN Committee notes that Independent Review Panels to evaluate the technical and financial aspects of new TLD proposals could be enhanced in the area of non-ASCII TLDs by including experts from existing international organizations such as the UN. Since the ITU is the UN specialized agency with responsibility for telecommunications matters, it would appear appropriate to suggest that, at the appropriate time, a dialog could take place with respect to the ways in which ITU could assist the IDN Committee in this area.
Response from Martin Duerst, W3C Internationalization Activity Lead, PSO-PC Member
The paper does not discuss at all whether or how the current convention of reserving TLDs with a certain number of characters (2) for ccTLDs will be extended to other scripts. There are various advantages to such a convention, but it has to be established very early on. The convention may be handled differently for different scripts. For example, for CJK, a single character could be enough, whereas for Cyrillic, three letters may be appropriate to avoid misunderstandings (the well-known py example).
XI. CREATION OF NON-ASCII EXTENSIONS TO ISO 3166-1
Response from Martin Duerst, W3C Internationalization
Activity Lead, PSO-PC Member
Partly in the body of the paper, but mostly in footnote [3], the proposals
are made to request ISO to create non-ASCII extensions to ISO 3166-1,
or to rely on national adoptions of ISO 3166-1.
While I do not want to completely reject such possibilities, it is important to note that ISO 3166-1 is designed to provide *unique* identifiers for countries and territories, and an extension of the identifiers in ISO 3166-1 to other scripts may therefore not be in the purview or interest of the responsible committee(s), and might also lead to confusion. Even without these concerns, creating a new ISO standard may take a long time, easily much longer than the potential users of IDN TLDs might want to wait.
As for nationally adopted versions of ISO 3166-1, they do translate the text of the standard and the country/territory names, but not the country/territory identifiers (which would be needed).
In consequence, I think it is quite important for ICANN to consider other sources or ways to define non-Latin script ccTLD identifiers.
Response from Siavash Shahshahani, .ir ccTLD Registry
ICANN's latest discussion papers (13 June) give a pretty good picture of the many difficulties facing the assignment of TLDs and registries in the non-ASCII world. Nevertheless, it is important to take practical steps NOW in order to avoid something like the '.com fiasco' where a single TLD has become synonymous with Internet in the eyes of the less-informed public with all the consequences that entails. A non-policy of drift and procrastination will only make for greater difficulties later on. I believe that Phase 1 of assignments should begin right after or simultaneously with the finalization of technical guidelines. Specifically, the following is proposed:
* Limit Phase 1 to SPONSORED gTLDs assigned to IDN units(to be defined)*
By an IDN unit I mean an entity of maximal size sharing three properties: (1)Script, (2)Language, and (3)ISO 3166 two-letter code
There are of course problems even with this. Thus, there are cases where it is not clear whether we're dealing with two distinct languages or different dialects of the same language. Also, language and script can cross ISO 3166 boundaries. But my suggestion would be to allow for smaller well-defined units whenever there is substantial local initiative. A process of natural selection and mergers will eventually shape the natural IDN units(which may ultimately cross ISO3166 boundaries), but this should happen spontaneously at the grass-root level. Less-used TLDs can become extinct over time.
Here are some advantages of limiting the initial phase to sponsored gTLDs:
A. These are clearly defined, more informative, and less likely to attract speculators.
B. Having a number of sponsored gTLDs around before more loosely defined non-sponsored gTLDs are defined in later phases will ease the pressure and the 'gold-rush' that may later ensue for more popular non-sponsored gTLDs.
C. Such small units are less likely to invite obtrusive governmental interventions specially in developing countries.
D. Small units allow for the gradual development of technical and administrative know-how necessary to run larger gTLDs or non-ASCII ccTLDs at a later phase."
Response from Martin Duerst, W3C Internationalization Activity Lead, PSO-PC Member
I have read your Discussion Paper on Non-ASCII Top-Level Domain Policy Issues (Revised Draft of 13 June 2002) with great interest. I would like to thank you for your important work in this quite difficult area.
While I think that your overall approach of being careful and trying to extend the experience with, and criteria for, the existing LDH TLDs, I have a few comments that I hope will contribute to the further improvement of the document and the eventually resulting policy.
I'm confused by the following sentence:
* Even if IDNs compatible with a given language at the second level of the TLD are permitted, enforcement of a restriction at the third or fourth level or beyond is likely to prove challenging.
Should this be something like "Even if only IDNs compatible with a given language at the second level of a given TLD"?
Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org .
Page Updated
05-Aug-2002
©2002 The Internet Corporation for
Assigned Names and Numbers. All rights reserved.