IDN Liaision's Report, 31 August 2009
> “The first step is to support the implementation of Internationalized Domain Names (IDNs) so that businessmen in Russia or India, as just two examples, can use their native languages and language scripts to write their domain names, and can access written information and other content in the same way. ... the roll-out of IDNs over the next year is a small but enormously important step for the ICANN community and for the broader global Internet community.” - Rod Beckstrom, CEO of ICANN
Status of the Fast Track Implementation:
ICANN is in the “last steps” of making IDNs a reality at the top level. IDN ccTLD fast track process is to be implemented first, followed by the introduction of IDN gTLDs in the root.
Staff anticipate that the remaining tasks to be finalized before the Seoul Meeting and hope to launch the Fast Track process in Q4, 2009, shortly after the Seoul Meeting, subject to Board Approval.
IDN gTLDs are to follow the publication of the v3.0 of the applicant guidebook, which is expected to be published before the Seoul meeting. It is targeted to open applications for IDN gTLDs in Q1, 2010 as indicated by a report by Tina Dam at the APNIC meeting in Beijing recently.
The most important of the Remaining Tasks:
One of the tasks relate to the process of Evaluation of the requested strings will have to be checked by the DNS stability panel. The status of the DNS Stability panel is that a contractor has been designated and the specific members have been approached and being hired. There are other internal processes that need to be finalized, related to the process of performing linguistic checks – whether the requested string is a meaningful representation of the country or territory in the formal script of the country or territory. On this task, some support processes are to be established. Some of the support processes are UN focused and some are not, and a few of these internal processes are on the last steps of being finished. Also changes are being made to the ICANN website to accommodate IDN related processes including better user participation.
The contentious among the outstanding issues relate to the the definition relationship of IDN TLD managers with ICANN. This may eventually be defined as a mandatory arrangement which is similar to the accountability framework ICANN has in the case of ccTLDs or a even lighter arrangement for exchange of communication or agreements to comply with technical standards only.
Staff expects to finalize all this before the Seoul meeting so everything could be placed for approval by the Board during the Seoul Meeting.
IDN Cost Considerations: Staff completed their analysis and it is likely that there would be a processing fee of US $ 26,000 per application + an annual fee. The annual fee may be tiered, (for e.g. free for the countries and territories that give away IDN registrations for free) and may go upto between 1 and 3% for annual support in most cases.
The issue of Variant characters:
One solution proposed is to reserve the desired variant and block other variants and the other solution is to delegate the desired variant and block all other variants. The feedback received so far points to disagreement whether either or one of the solutions is stable. An implementation support team is being established and the results to be published before the Seoul Meeting. However, if the support team does not come up with a solution in the short-term, Fast Track implementation would still proceed, with some initial limitations and some arrangement for manual checks.
On the issue of Number of Characters in the gTLD string, a proposal is to be published before the Seoul Meeting. The IDN gTLD process is expected to begin by opening up for applications in Q1, 2010.
Update on Technical Preparedness for the introduction of IDN TLDs: Internet drafts published by the IETF:
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. These are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. Drafts are considered “work-in-progress”.
1. The Unicode code points and IDNA draft-ietf-idnabis-tables, Network Working Group of the IETF, August 10, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-tables-06.txt
Abstract: This document specifies rules for deciding whether a code point, considered in isolation, is a candidate for inclusion in an Internationalized Domain Name.
2. Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale, Network Working Group of the IETF, August 13, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-rationale-11.txt
Abstract: Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components.
3. Internationalized Domain Names in Applications (IDNA): Protocol, Network Working Group of the IETF, August 9, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-protocol-14.txt
Abstract: This document is the revised protocol definition for internationalized domain names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalizing Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.
4. An updated IDNA criterion for right-to-left scripts, Network Working Group of the IETF, August 7, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-bidi-04.txt
Abstract: The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI rule for IDNA labels.
5. Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework, Network Working Group of the IETF, August 9, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-defs-10.txt
Abstract: This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set.
6. Mapping of Characters in IDNA, Network Working Group of the IETF, August 20, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-mappings-03.txt
Abstract: In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "make sense", which were then encoded and passed to the domain name system (DNS). The current version of IDNA presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions taken by an implementation between user input and passing permitted code points to the new IDNA protocol.
7. Right-to-Left scripts for IANA Network Working Group of the IETF, August 30, 2009
Link: http://www.ietf.org/id/draft-ietf-idnabis-bidi-05.txt
Abstract: The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI rule for IDNA labels.
- Sivasubramanian Muthusamy
ALAC IDN Liaison
31 August 2009
