Skip to main content
Resources

Summary and Discussion of Comments on the Proposed Revision to the ICANN IDN Guidelines

The following is a summary of the actions taken by the working group for the revision of the ICANN Guidelines for the Implementation of Internationalized Domain Names ("the Guidelines"), in response to comments received on the initial proposed draft version 2.0. On the basis of detailed consideration of these comments, the draft was modified and forwarded to the ICANN Board for endorsement. The differences between the initial and revised versions of the draft should be readily apparent upon direct comparison of those two documents. The present text provides an additional discussion of the working group's response to the submitted comments, as well as an overview of the process leading to the final proposed draft.

Timeline:

20 September 2005: The working group posted an initial draft version 2.0 of the Guidelines for public comments at http://icann.org/announcements/announcement-20sep05.htm.

23 October 2005: The comment period ended and all contributions that were received can be seen at http://forum.icann.org/lists/idn-guidelines/.

31 October 2005: The working group posted a statement of acknowledgement of the interest and efforts of everyone who submitted comments, together with a description of the revision process. The public comment forum was re-opened to allow for continued discussion of direct relevance to the Guidelines, and IDN in general. It was, however, clearly indicated that only the comments received within the first period would be considered during the preparation of the proposed final draft version 2.0 of the Guidelines. See http://icann.org/announcements/announcement-31oct05.htm.

7 November 2005: The final proposed draft version 2.0 of the IDN Guidelines was posted together with the present overview. The final proposed draft is now pending ICANN Board endorsement.

Disposition of the present document:

Comments are grouped here according to the basic issues they address, but are not presented in prioritized order. Although the formal desirability of an explicit point-by-point response to each submitted comment is recognized, a summary presentation of manageable length is likely to be a more productive contribution to the substantive discussion.

Anyone who would like a more detailed response to any individual point than what is found below is welcome to request further clarification on the public forum, where the working group will provide further explanation as rapidly as possible.

Discussion of received comments:

Scope and Disposition: Concern was expressed about the draft revision of the Guidelines not being a significant enough departure from version 1.0 to be meaningful. The official endorsement of version 2.0 would risk engendering a false sense of adequacy, making it less likely that untreated key issues would receive sufficient attention.

The working group never intended version 2.0 to be a final statement and has been discussing more extensive subsequent action from the outset. The group recognizes that it may not have indicated clearly enough that the current incremental revision is being put forward as the last such change to the parent document. However, the need for a clear and immediate response to the urgent issues discussed below was taken as an overriding concern. The version 2.0 Guidelines were seen as an appropriate vehicle for doing so, despite any of their remaining shortcomings in format or substance. With the proposed final draft, the initial format of the Guidelines is being brought to the end of its editorial path. The working group has now begun the reframing of the Guidelines completely in a manner appropriate for further development as a Best Current Practices (BCP) document, for which formal IETF status will be sought.

Authority: Question was raised about the way in which the working group was formed, and the lack of participation of individuals external to TLD registries but with expertise in IDN implementation.

The purpose of the revision exercise was to incorporate the experience of TLD registries that support IDN in an updated version of the Guidelines. At the request of several signatories to the initial Guidelines, ICANN staff convened a group of TLD registry representatives by inviting the Registry Constituency of the GNSO, and the ccNSO Council (which does not have a separate registry constituency) to designate the members of the present working group.

The members of the working group consulted with external experts during the course of their work. The intention, throughout, was for the result of that action to be put to forward for the consideration of all interested parties. The corresponding public forum elicited a wide range of detailed commentary, and the forum has been reopened for the further consideration of anything that may have been overlooked.

It is recognized, nonetheless, that a broader more formal forum is necessary. Although external to the working group's mandate, it may be appropriate to note that the ICANN President is in the final stages of designating an IDN Committee with a constituency embracing all concerned stakeholder groups.

Enforcement: The utility of the Guidelines was seen as being severely limited in the absence of binding enforcement mechanisms. An opposite view was also expressed, questioning the legitimacy of any attempt at uniform regulation of the IDN practices of TLD registries. The propagation of TLD policies to autonomously operated lower level registries was also a concern.

The TLD Registries that participated in the preparation of the revised Guidelines are all firmly committed to implementing them in their entirety, and expect many other TLD registries to adopt them on the same terms. The draft text has been clarified in regard to the direct applicability of the Guidelines to the gTLD registries, with the intention of their being suitable for all other registries, including those at the second and lower levels. Mechanisms for imposing compliance on TLD registries that do not wish to ascribe relevance to the Guidelines are not within the working group's ability to articulate or effect. The working group agrees that mechanisms for the propagation of IDN policy into delegated subdomains is a significant matter requiring further treatment.

Wording: Attention was called to the unsuitability of the Guidelines containing terminology that was appropriate to a formal normative instrument, but not fitting in a non-compulsory recommendation.

The draft was modified in this light, limiting the most restrictive terminology to the use of the term 'will', and striking all instances of the term 'must' (with one exception, as is obvious in the document itself).

IDN at the Top Level: Concern was expressed about the Guidelines not covering the appearance of IDN in top-level labels.

The Guidelines have been rephrased to clarify preparedness for the appearance of IDN at the top level. Additional work is in progress specifically about this, for example, at http://www.icann.org/announcements/announcement-14sep05.htm. The outcome of such action is not yet possible to foresee, and thus out of scope for the current revision to the Guidelines. The working group recognizes that there are urgent requirements, particularly as they relate to alphabets written right-to-left, and in the ideographic realm. Working group members hope to contribute meaningfully to the resolution of the pending concerns.

IANA Registry for IDN Tables: Comments were received about the need for modifying the functionality of the IANA registry for language tables to correspond to changes between the 1.0 and 2.0 versions of the Guidelines.

These comments have been forwarded to the IANA with a recommendation that they be implemented. The IANA registry recently went through a first series of structural and procedural modifications, and additional changes are planned following the endorsement by the ICANN Board of the final version 2.0 of the Guidelines.

Inclusion-based vs exclusion-based policies: A large number of comments addressed various aspects of the fundamental approach to stating the repertoire of characters available for IDN registration. The two primary approaches are to establish an extensive list of characters that may not be used (blacklist), or only to permit characters that have been explicitly listed (whitelist).

Although the two methodologies can be integrated, the proposed version 2.0 of the Guidelines remains inclusion-based. Any further nuance to this will be one of the key topics for further development as the BCP successor to the Guidelines is prepared. A detailed response to every relevant viewpoint contributed to the present public forum would require a lengthy document of its own, and the preparation of such a statement is seen as a component of the preliminary work toward the BCP.

Visually confusable characters: Considerable commentary was focused on the need for detailed means for preventing the appearance of visually similar characters in contexts where this could be deliberately exploited and was not offset by valid linguistic requirements. Similar concern was expressed about permitting characters that are neither letters nor numbers, but might appear as though they were.

The major step forward taken by the 2.0 revision of the Guidelines is its restriction of the characters that may appear in a single label to a single script. Languages that require the use of multiple scripts may be accommodated only subsequent to the statement of clear case-by-case rules about how the requisite scripts may be intermingled. As with the previous point, this is a topic that will require extensive elaboration as the BCP is prepared.

Auxiliary marks: Several comments said that the initial draft did not adequately define or describe necessary characters that are neither letters nor digits but nonetheless were necessary to indicate some essential aspect of a label.

The proposed Guidelines have been reworded to clarify this. Specific reference to essential punctuation marks has been removed.

Unicode vs Punycode: Several comments suggest that the Guidelines define the scope of an IDN registration in terms of both its Unicode and ASCII encoded representations.

The wording of the draft has been altered accordingly.

Tagging formalisms for indicating language and script: Several comments suggested that there was no need to co-opt identification procedures that had been developed for other purposes, if there was any need for tagging at all.

All references to tagging or structured means for labeling character tables, other than by narrative description, have been removed from the draft.

Constraint on trademarks: One comment took the one-label/one-script rule to apply to entire domain names thus placing undue restriction on the representation of trademarks.

Different scripts may appear in a single domain name. Indeed, this will be the case with any IDN using more than the basic LDH repertoire, for as long as top-level labels are restricted to LDH.

Support for WHOIS implementation: A comment was received suggesting the IDN Guidelines to cover issues related to WHOIS.

A range of issues relating to WHOIS are under consideration by dedicated task forces under the GNSO. The members of the Guidelines working group provide input to that action via separate channels.

Citation: Attention was called to expected changes in some of the normative documents to which the Guidelines make reference.

With one exception, all such references have been removed from the proposed final draft. In the remaining instance an incorrect citation has been corrected.

Appended "Additional Remarks": Question was raised about the purpose of the material under the final heading.

This was a component of the version 1.0 Guidelines and appeared useful for contextual information about the Guidelines. The largest portion of that text has now been removed from the proposed version 2.0.

Evaluation of version 1.0: Comments were received about lack of clear rationale for differences in stringency between the 1.0 and proposed 2.0 versions of the Guidelines, and the absence of a detailed evaluation of the experience with version 1.0.

Work was initiated with version 2.0 in response to what was being widely publicized as an emergency situation with immediate risk of visually confusable characters being exploited for fraudulent purposes. The TLD registries wished to indicate the seriousness with which they are taking the security concerns, and make a clear commitment to effecting meaningful changes to their IDN policies in the shortest time possible (which the one-label/one-script rule, if nothing else, is intended to accomplish). They recognized from the outset that doing so would by-pass necessary evaluative consideration which, yet again, is something to which the working group intends to return as more deliberate attention is paid to the preparation of a significantly more robust successor document.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."