ICANN | Report of the Internationalized Domain Names Internal Working Group of the ICANN Board of Directors

Report of the Internationalized Domain Names Internal Working Group of the ICANN Board of Directors

Posted: 28 August 2001

Report of the Internationalized Domain Names Internal Working Group of the ICANN Board of Directors

Click here to enter the Public Comment Forum on introduction of internationalized domain names (IDNs).

TABLE OF CONTENTS

The ICANN Board established the Internationalized Domain Names (IDN) Working Group at the ICANN meeting in Melbourne in March 2001. The Board directed the Working Group "to identify the various internationalization efforts and the issues they raise, to engage in dialogue with technical experts and other participants in these efforts, and to make appropriate recommendations to the Board."

After preparing a mission statement, the Working Group asked the ICANN community to respond to three surveys addressing technical questions, policy questions, and questions concerning current services relating to IDNs. Fourteen entities and individuals responded to these surveys prior to the ICANN meeting in Stockholm in June 2001, where the Working Group chairman presented a status report. After the Stockholm meeting, the Working Group received an additional eleven responses to the original surveys and follow-up questions the Working Group had put before the ICANN community. Additionally, members of the Working Group engaged in consultations with entities such as the Multilingual Internet Names Consortium, the Arabic Internet Names Consortium, and JPNIC.

The ICANN community strongly supports the deployment of IDNs. There is broad recognition that IDNs will increase Internet use by the majority of the world's population, whose native scripts are non-Latin. However, several issues need to be resolved so that IDNs can be deployed in a manner that does not harm the stability of the Internet.

Significant technical questions must be addressed because the domain name system was originally designed to handle only Latin scripts in ASCII format. There are two primary technological approaches for using non-Latin scripts as domain names. One approach involves sending domain names over the Internet in local encodings such as BIG5 or UTF-8. Because this approach may require reconfiguration of the servers throughout the Internet, it is referred to as a "server side" approach to IDNs. The second approach involves translating the local encoding into ASCII Compatible Encoding at the user's computer. Since this approach requires users to install the appropriate translation software into their computers, this approach is referred to as a "client side" approach. In addition, there are hybrid approaches, which involve changes on both the client and server sides.

Each of these approaches has technical and practical advantages and disadvantages. The absence of a clear "best approach," and the many tradeoffs, makes the task of the Internet Engineering Task Force's Internationalized Domain Name Working Group, the body charged with selecting a standard, particularly difficult. However, delay in the adoption of a standard may encourage the development of alternative roots for IDNs. The IETF appears to be leaning in favor of adopting a client side approach. After a standard is selected, the deployment of applications such as email will still take time. Additionally, the special requirements of particular scripts will have to be addressed.

The deployment of IDNs will increase the opportunity for cybersquatting. Survey participants recommended a variety of measures, particularly increased use of UDRP arbitrators familiar with non-Latin scripts, to combat this problem.

The existence of IDNs will also create a demand for top level IDNs. Respondents provided different suggestions for approaching this potentially contentious and divisive issue.

To date, well over a million IDNs have been registered. Many of these are "live" to varying extents. Although respondents indicated that they would migrate to the standard adopted by IETF, this large number of registrations places pressure on ICANN to address the issues raised by IDNs expeditiously.

Accordingly, the Working Group makes the following recommendations. The ICANN Board should do everything in its power to facilitate the adoption of an IDN standard by the IETF. It should urge members of the IETF IDN WG to find expeditiously the best solution that can be adopted and implemented in a timely fashion.

Second, ICANN should charter a steering committee with representatives from the supporting organizations, the GAC, and the Working Group to advise the Board on policy issues relating to IDNs. The steering committee would focus on the three policy areas identified by the GAC in its Melbourne Communiqué: promoting interoperability; preventing cybersquatting; and applying competition, market access, and consumer protection principles. Because time is of the essence, the steering committee should be convened as soon as possible, and it should present the Board with its work plan and schedule at the ICANN meeting in Marina del Rey in November 2001.

The ICANN Board established the IDN Working Group by approving resolution 1.39 at the ICANN Board Meeting in Melbourne, Australia, on 13 March 2001. The resolution stated:

"In order to promote better understanding of the technical and policy issues surrounding the internationalization of domain names, the Board designates an internal working group … to identify the various internationalization efforts and the issues they raise, to engage in dialogue with technical experts and other participants in these efforts, and to make appropriate recommendations to the Board."

The Board designated Masanobu Katoh as the chair of the Working Group, and Karl Auerbach, Ivan Moura Campos, and Vinton Cerf as members.

In April 2001 the IDN Working Group posted its mission statement on the ICANN website. The mission statement stated that the Working Group would engage in fact finding concerning three clusters of questions:

The mission statement makes clear that the Working Group "sees its charter as limited to fact finding for the purpose of educating the board and the ICANN community so that ICANN can fulfill its mission of technical management of Internet domain names and IP numbers. The working group will not set technical standards for IDNs."

The Working Group prepared three surveys designed to obtain answers to the three clusters of questions set forth above. These surveys were posted on the ICANN website on 30 April 2001, with a return date of 10 May 2001. Additionally, the surveys were emailed to numerous entities and individuals involved with IDNs. Prior to the June 2001 ICANN meeting in Stockholm, the Working Group received 14 responses.

Members of the Working Group also met with entities involved with IDNs to gather information. M. Katoh attended the meeting of the Multilingual Internet Names Consortium (MINC) in Melbourne on 14 March 2001. M. Katoh attended the Founders Meeting of the Arabic Internet Names Consortium (AINC) in Amman, Jordan, on 1 April 2001.

At the June 2001 ICANN meeting in Stockholm, M. Katoh presented a status report on the activities of the IDN Working Group at the Public Forum. The report summarized the survey responses received to that point. At the Public Forum, members of the ICANN community provided reactions to the status report and the IDN issues it raised. The IDN Working Group invited the ICANN community to submit comments on the status report and additional responses to the surveys through July 31. Additionally, the IDN Working Group stated that follow-up questions would be posted on the ICANN website, which would also have a 31 July 2001 return date.

Follow-up questions were posted on the ICANN website. As of 1 August 2001, an additional 11 survey responses were submitted to the Working Group. Further, M. Katoh participated in ChinaInet 2001 in Beijing on 11 July 2001 and the Keidanren-JPNIC workshop in Tokyo on 13 July 2001, where IDNs were discussed.

1. What different technologies currently enable the use of non-Latin scripts as domain names?

Different respondents identified between two and four basic approaches. In over-simplified laymen's terms, the domain name system was originally designed to handle Latin script in ASCII format. This made sense at the time given the early development of the Internet and the DNS in the United States and Western Europe. There are two basic approaches for handling IDNs. One is sending domain names over the Internet in local encodings such as GB, BIG5, SJIS, or in a Unicode Transformation Format such as UTF-8. This approach may require reconfiguration of servers throughout the Internet in order to maintain full interoperability. Indeed, some suggest that the entire DNS may have to be redesigned to accommodate these various scripts. For this reason, this approach can be referred to as a "server side" approach to IDNs.

The second approach is translating the local encoding or the Unicode into ASCII Compatible Encoding (ACE) at the user's computer. One variant of this approach is Row-based ASCII Compatible Encoding (RACE). The domain name then goes out over the Internet in ASCII. The translation approach requires users interested in employing IDNs to acquire the appropriate software to effectuate the translation into ASCII. For this reason, this approach can be referred to as a "client side" approach to IDNs.

Various parties have proposed a variety of specific implementations of these two basic approaches. Additionally, some have proposed hybrid approaches, which require changes on both the client side and the server side.

For example, RealNames Resolution Services involves a cooperative approach between Microsoft, RealNames and VeriSign. The user types a local encoding, such as UTF-8 IDN, into her Internet Explorer browser. The Internet Explorer browser determines that the name is not a valid ASCII name, and then forwards it to a RealNames server rather than the DNS. The RealNames server converts the UTF-8 IDN to an ASCII string, which is then sent to the VeriSign multilingual testbed for resolution.

2. What are the strengths and weaknesses of the technologies referenced in Question 1? Please give concrete examples.

The main advantage of the server side approach is that it requires no implementation on the client side; the users likely to employ IDNs already have local encodings installed on their computers. The server side approach may also permit more characters than the client side approach. Disadvantages include the significant time which may be required to implement fixes on Internet servers throughout the world (e.g., changes to infrastructure such as mail transport agents - 8 bit clean processing); the possible development of alternate roots once fundamental changes to the DNS are undertaken; and name equivalence. The same encoding value could represent different character sets, which could lead to security problems.

The main advantage of the client side approach is that it requires no implementation on the server side, which theoretically will make it faster to implement. Disadvantages include users having to install conversion software; difficulties in converting local character sets such as JIS into Unicode which must then be converted in ASCII; limitations on the length of domain names (see response to Question 9 of Survey A); and intellectual property issues (see response to Question 11 of Survey A).

The RealNames system addresses the client side problem of installation by relying on Microsoft's Internet Explorer, which apparently in versions 5.0 and higher already includes the necessary module to direct the UTF-8 IDNs to the RealNames server. The RealNames system addresses the server side problem of reconfiguring servers around the world by running its own set of servers, which it can easily reconfigure as needed. A potential issue with the RealNames system is that it is a proprietary solution tied to Microsoft and RealNames. It is unclear whether other firms would be able to participate in the system on competitive terms.

According to respondents, for some scripts there is more than one local encoding scheme. Further, some language have more than one script -- traditional and simplified Chinese, for example. Chinese also has a very large number of characters. In Arabic, spaces within phrases change the meaning and form of a character, and in Hebrew, certain characters can be omitted. These features present complications for both approaches discussed above. Sam Malenfant suggested that some problems could be addressed by the manual entry of multiple versions into the DNS at the time of registration. Additionally, Eric Brunner-Williams noted that European scripts become "ASCII gibberish" under ACE transformation. i-DNS.net commented that some scripts have no input method engine, lack a font renderer or do not have standardized scripts.

4. To the extent there are weaknesses in the technologies, what groups are working to develop solutions?

The Internet Engineering Task Force (IETF) has an Internationalized Domain Name Working Group (IDNWG), which is hard at work on this matter. Other groups include the Unicode Consortium, MINC, the Unicode Technical Committee, ISO JTC1/SC2/WG2 and JTC1/SC2/WG22, W3C Internationalization Activity, and the Chinese Domain Name Consortium (CDNC). Some respondents suggested that the specific issues relating to particular scripts (see response to Question 3) should be resolved at the local or regional level.

5. What are the different solutions under consideration? Which are the most promising? How much longer will it take to develop a solution that works?

Many respondents stated that the IETF seems to be focusing on Internationalized Domain Names in Application (IDNA), which involves a client side approach. Walid has announced that it has a patent which it claims reads on aspects of IDNA. Putting the patent issue aside, some respondents state that the IETF is at least six months away from completing its work.

Several server side approaches are being promoted. Some will require extensive redesigning of the DNS, and may take as long as a decade to fully implement.

6. Currently there are no accepted standards for IDN. Is this because there are competing technologies, or because the underlying problem is sufficiently difficult that a "best" solution has not yet emerged?

Several respondents observed that the IDN problem is extremely complex, and that there is no ideal solution. Moreover, there are different stakeholders, and different approaches have different advantages from different points of view. Neteka identified the following stakeholder "camps": system administrators/operators; end users; and technologists. Register.com observed that "because of the critical nature of the DNS to the Internet community, it is important to develop an in-depth understanding of the pros and cons of all possible solutions, and to move towards adoption in a manner that does not jeopardize the stability of the Internet." i-DNS.net stressed that there will never be just one solution or standard. Over time, whatever approach the IETF selects will be modified and improved.

7. Do the existing "testbeds" and pre-registrations help or hinder the resolution of the technical issues relating to IDN? In what manner? Would the testing impact the ongoing operation of the Internet?

Most respondents felt that the operational experience from legitimate testbeds can be helpful in moving solutions from theory into practice. It flushes out areas where additional development s required for ancillary services. i-DNS.net further stated that "market demand will not wait for a technically perfect solution …" Some respondents acknowledged, however, that some of the testbeds could be seen as attempts to force the Internet community to accept certain technologies despite their appropriateness or quality-what one respondent described as "mindshare capture." Further, some respondents noted that some testbeds might lead to the establishment of an alternative namespace beyond that recognized by ICANN, which in turn could lead to user confusion.

One respondent observed that user expectations concerning the testbeds needed to be managed carefully. Users may be under the impression that the testbeds are an operational part of the Internet, and may view technical failures within testbeds as operational problems rather than a normal part of the testing process.

John Klensin further noted that "ill defined test beds" and "just send 8 strategies" "create the risk of damage to existing, conforming, and deployed software…." See also his response. (Question 16 of Survey A).

Stefan Probst stated that VeriSign's testbed placed registrars in a difficult position. On the one hand, ISOC discouraged IDN registrations in advance of the adoption of standards, while on the other hand, failure to register meant loss of customers. Registrants likewise had to choose between heeding ISOC and protecting their names from cybersquatters. Eric Brunner-Williams stated that the VeriSign testbed removed $35 million from the pool of capital available for funding work on IDN enablement.

8. Are natural languages so complex, rich and varied that a true IDN system that responds completely to user expectations is beyond current technological capability? Can the problem be solved incrementally in a manner that does not interfere with the operation of the entire domain name system?

Several respondents noted that the domain name system was never intended to serve as a "directory service" which could consistently find the appropriate result to a natural language query. Although the DNS was designed from the outset to reduce certain language related errors, for example, its case insensitivity, it is not capable of distinguishing between variants of words even in English, or other nuances of language.

For this reason, several respondents believe that issues involving natural language and the context-sensitive expectations of users are outside the proper scope of the IDN exercise. They see domain names simply as identifiers, and the IDN exercise as aimed at adding support for a wider range of scripts to be used as identifiers in the DNS. i-DNS.net noted that "a workable solution and acceptable solution … does not need to perfectly cater [to] every single nuance in a language. Compromises can be found…" Milton Mueller stated "[D]omain names are just unique, hierarchically organized identifiers for computers or other resources on the Internet. Their primary function is technical. Policy should NOT be based on the assumption that domain names should be something more than that. It will prove extremely dangerous and counterproductive to attempt to make them approximate 'natural language' and all its inherent contextual ambiguity. Such a path will lead to complex, expensive and ultimately futile attempts to regulate and control the use of DNS labels on a worldwide basis. Thus, ICANN policies that attempt to be sensitive to extremely local and culturally specific variations in scripts must be avoided. Whatever problems of this sort arise as a byproduct of technical change can be handled through regional treaties and national systems of laws."

Others, however, believe that the nature of domain names has evolved from its origins, and domain names now represent a person's or corporation's identity on the Web -- an evolution from identifier to identity. As such, the DNS should try to incorporate natural language rules to the extent possible. Directory service layers above the DNS are one way of addressing this growing need.

Respondents caution that natural language issues should be addressed at the local level. Users need to be educated about the limits of the DNS so as to moderate their expectations. And the injection of natural language rules should be done in a manner that does not threaten the stability of the Internet, particularly by undermining the unique name approach.

9. How do different technologies affect the size limitation of domain names? What, if any, are the possible solutions?

Domain names are limited to 255 octets, with no more than 63 octets per segment (i.e., between periods). Different representations of character sets require a different number of octets. Because encodings of non-Latin scripts often require more octets than Latin scripts, IDNs cannot be as long as Latin-script domain names. Some respondents suggested this is more of a problem in client side than server side approaches. Further, DUDE may perform better than RACE in this regard. Technical experts are considering various compression algorithms to increase the number of non-Latin characters which can be included in a domain name. Sam Malenfant also suggested using more than one level, e.g., one word or one syllable per level.

10. Do IDNs pose special problems for the technical operation of Whois databases? If so, what problems? What are the possible solutions?

VeriSign GRS observed that the "Whois services must be internationalized if the domain names they hold are internationalized. One possibility is internationalizing the Whois protocol itself, along with clients and servers. Another is adopting the IDNA approach: IDNs would be stored in an ACE format and Whois clients would convert internationalized user input into ACE format before querying a Whois server." Several respondents believed that a long term solution required a server side approach.

11. Are any IDNs related technologies covered by patents or other intellectual property rights? If so, will this have an affect on the implementation of IDNs?

According to Register.com, "several companies claim intellectual property rights over various portions of the IDN solution space." For example, Walid recently received a patent which it claims reads on aspects of the IDNA solution under consideration by the IETF. Walid has stated that if the IETF adopts a standard which requires use of technology disclosed in any Walid patent, Walid will grant "a non-exclusive license on reasonable and non-discriminatory terms and conditions, based on the principle of reciprocity…." Several respondents expressed concern with this patent, and indicated that the IETF was taking it into account in determining whether to proceed with the IDNA solution.

Neteka has patent applications pending on its multilingual technology. Neteka claimed that its technology is freely available as open source.

Stefan Probst supported adoption only of technologies available under an Open Source License.

12. Are you participating (or have you participated in) the IETF standards process for IDN?

13. Once IETF adopts an IDN standard, how quickly will it be incorporated into applications such as browsers? Are any problems with this incorporation anticipated? What can the IETF and ICANN do to facilitate the incorporation process?

Several respondents observed that the speed of adoption will depend on the solution chosen and the treatment of intellectual property rights relating to the standard. Walid believed that if the IETF adopts a client side approach, major application suites could be upgraded "within a few months." On the other hand, Walid claimed that a server side solution will follow a much slower deployment cycle. An infrastructure -based solution could take as long as 10 years to deploy fully.

According to respondents, the IETF can facilitate the process by adopting a standard as quickly and prudently as possible. ICANN should support the IETF's efforts and the eventual standard.

Milton Mueller noted that ICANN "does not have and should not have any authority to select from among competing technical standards and require registries or registrars to employ one of them exclusively. ICANN was never intended to be a standard-setting or enforcing organization. It is purely an assignment authority within the framework of Internet standards."

14. Will the IETF standard be interoperable with other IDN standards? What can be done to eliminate interoperability problems (assuming not all ccTLDs adopt the IETF standard)?

Respondents concurred that given the wide range of IDN approaches, it is unlikely that the IETF standard will be interoperable with all IETF deployments. Neteka claimed that its hybrid solution will reduce interoperability problems. i-DNS.net suggested the use of a "Universal Client" to ease interoperability problems. Walid noted that adoption of technical standards is voluntary, but market forces will promote standardization and uniformity. VeriSign, however, believed "that compliance with an IETF standard should be a requirement for all ccTLD and gTLD operators now offering IDNs."

15. Are there other end user needs concerning IDN which need to be addressed?

Respondents identified the following issues: backward compatibility; use of IDNs in document contexts, such as URLs embedded in HTML or XML documents; linguistic sensitivity; and introduction of symbols and punctuation. Neteka also urged recognition of the average user's lack of technical sophistication, and inability to install major modifications or plug-ins. Eric Brunner-Williams listed the applications which must use IDNs: ftp, ssh, telnet, smtp, Whois, tftp, finger, http, kerbers, pop, uucp, nntp, ntp, snmp, bgp, irc, nfs, and afs.

i-DNS.net identified the biggest concern as FUD - fear, uncertainty, and doubt -- concerning the viability of IDN and its impact on the DNS.

Neteka again stressed difficulties users will encounter with client side solutions, particularly that "the average user[s] will not immediately understand why they might be able to access multilingual domain names using their existing system."

John Klensin observed that ICANN should "protect the Internet against abuses of the DNS that create the risk of damage to existing, conforming and deployed software, or of ambiguous or non-unique naming. The risks in those areas of ill-defined testbeds, "just send 8" strategies, encouragement of multilingual cybersquatting, etc., are considerable and have been identified repeatedly to ICANN. The solution is to start warning the relevant domains of the impact, with the potential of starting a redelegation process … if they continue to encourage these efforts. If, as I suspect is the case, ICANN is effectively powerless to do this, then admit that and get out of this area until the various issues sort themselves out in the marketplace."

Eric-Brunner Williams stressed the readiness and prevalence of UTF-8 and 8-bit clean technologies.

17. (Follow-up question.) During the public forum discussion of IDNs in Stockholm, several members of the public observed that adoption of an IDN standard was "the easy part" of the IDN process. What are the "hard parts" we have to look forward to? Why are they going to be so hard?

TWNIC indicated that even after adoption of a standard, the related deployment of applications, e.g. email, can take several years: "The deployment of those kinds of large scale services in infrastructure level is extremely difficult." An anonymous respondent noted that the special requirements of local languages and characters must be resolved in the whole architecture. Inevitably, different users will have different requirements, which will involve different solutions. Thus, there will be a constant coordination. i-DNS.net stressed that the standards will continue to evolve, so constant updating will be needed.

1. What is your view of the value of IDNs? Who will benefit from them? Is there any empirical proof of these benefits? Who will IDNs harm?

Respondents generally had a very positive attitude towards IDN. They observed that most of the world's population does not use Latin script as its native script. IDNs, accordingly, will increase access to and use of the Internet. Additionally, IDNs will increase access to this population by businesses and organizations which now are constrained by Latin script domain names. Respondents generally were not able to identify empirical evidence of these positions, other than the large number of IDN registrations to date. Eric Brunner-Williams stated that "empirical proof of these benefits are available from operating system vendors who lowered their internationalization and localization (i18n and l10n, resp.) costs and extended their markets outside the English language education markets in the early 1990's, from market data on the expansion of i18n/l10n capable systems outside of the English language education markets over the same period of time, and from studies on the transformation of institutions from simple contexts to complex contexts.

At the same time, some respondents noted that IDNs will increase the opportunity for cybersquatting. JPNIC suggested that IDNs may make Internet use more difficult for visually handicapped users: "visually handicapped users may suffer from the difficulty in identifying the domain names they want to type in, because pronouncing English alphabets is much easier than vocally identifying Japanese characters among over 2000 different characters." Carlos Amengual suggested that IDNs can cause problems for "people in non-ASCII countries operating sites with (perfectly understood and valid) ASCII-ized versions of the domains, if they miss their IDN equivalents." Eric Brunner-Williams stated that "those harmed by extensions to identifiers used in the DNS are those who have 'bet their business on English Only,' which includes some political groups and business entitles in the United States and other English-using countries…"

2. Does the translation or transliteration of a trademark or other name constitute a violation? Does the answer to this question vary depending on the legal system? Do trademark treaties and other international agreements speak to this issue?

There are national variations in trademark law, but in many countries the translation or transliteration of a mark could be considered infringing if it is likely to confuse the public as to the origin of the goods and services. Additionally, in countries which recognize dilution, a translation or transliteration could be considered dilutive. A respondent indicated that this issue is addressed in Article 6bis of the Paris Convention.

JPNIC observed that the translation or transliteration of foreign trademarks into Japanese may result in a character string which infringes a Japanese mark.

Kobe Yabe observed that Chinese, Japanese, and Korean share similar characters which may have a completely different meaning. This may lead to conflicting registrations.

3. Will the existence of IDNs increase the incidence of cybersquatting? In what manner?

Most of the respondents observed that whenever new registration opportunities arise, new opportunities for cybersquatting present themselves. Some added that IDNs were no more susceptible to cybersquatting than Latin scripts. Others felt that certain scripts to pose special problems. According to JPNIC, some Kanji characters are very similar to one another. Some respondents noted that adding new scripts may pose a linguistic challenge for trademark owners monitoring for violations of their marks.

Carlos Amengual cites specific problems relating to extensions of the existing ASCII character set, e.g. ASCII characters with accent marks.

Kozo Yabe observed that Japanese companies have encountered many incidents of cybersquatting in the VeriSign testbed.

Eric Brunner-Williams summarized the issue as follows: "Fundamentally the existence of IDNs increase the incidence of cybersquatting in three distinct forms, by increasing the total available namespace in which cybersquatters operate, by making a larger repetoire of characters available to form 'off-by-one' ('invisibly differerent') identifiers and by making 'alternate sense or form' identifiers possible in a vastly enlarged set of alternate character repetoires (language)."

4. What measures can be taken to minimize cybersquatting? Which of the following measures is most important -- a "sunrise" period for pre-registration; a functioning Whois database; or a functioning UDRP system?

Some respondents felt all three measures were of equal importance. Others opined that an effective dispute resolution mechanism was the most important measure, although the procedures may not necessarily conform to the ICANN UDRP in its current form. At least one respondent observed that sunrise measures were problematic because they entangled the registries/registrars in the domain name disputes. Eric Brunner-Williams stated that the Whois database raises privacy concerns.

Kozo Yabe stated that if VeriSign had used a sunrise period for registrations in its testbed, it could have prevented many cybersquatting incidents. Mr. Yabe indicated that as yet there is no viable Whois database for identifying all IDN registrants. With respect to the UDRP, the service providers do not have enough panelists familiar with Japanese and other Asian languages. Additionally, WIPO will not accept pleadings in Japanese, even if all the parties are Japanese. This leads to delay and increased expense for the parties. Eric Brunner-Williams suggested using a mechanism such as "nameprep" which prevents visually similar charcters from being used in identifiers. He also suggested use of "restricted vocabulary approaches to automatic translation…."

5. What groups within and without ICANN should consider these policy issues? How should these groups proceed?

The respondents generally supported ICANN's consideration of issues raised by IDNs. Some respondents hoped to see a vigorous IDN working group in the DNSO, and the formulation of concrete recommendations. Respondents also encouraged cooperative efforts with MINC and other groups such as IETF, CDNC, and JET.

6. What other legal and policy issues are raised by IDN? How should ICANN address them, if at all?

One respondent suggested that communication between registrars and registries need to be improved. Several respondents suggested review and possible modulation of the UDRP. In particular, ICANN should consider new dispute resolution providers capable of handling IDN disputes. JPNIC also noted that a particular script is often used in more than one country, i.e., beyond the territory of a particular country code registry.

7. (Follow-up question.) Presumably there will be a demand for top level IDNs, i.e., [IDN].[IDN]. What role should ICANN play with respect to the selection of these top level names and their registries? What should be the role of the country code registry of the country where a particular script is a native script? And what if a particular script is a native script in more than one country?

Kozo Yabe indicated that registrars are very interested in moving forward with [IDN].[IDN]. He believes that this could "split the Internet" and lead to alternate roots. He encourages ICANN to watch this situation carefully and respond appropriately. TWNIC specifically recommended that ICANN should play the role of single authoritative root manager and encourage [IDN].[IDN] testbeds. TWNIC believed that current ccTLD managers should have the right to decide whether to continue providing testbed service and to serve as [IDN].[ccTLD] or [IDN].[IDNccTLD] managers. For [IDN].gTLD and [IDN].[IDNgTLD], TWNIC believed that the country where the language is spoken should have priority with respect to managing the domain. If a language is native to more than one country, ICANN should encourage the formation of a cooperative organization. ICANN should also "fully respect the culture and customs of the region where majority of certain language users are living…."

Likewise, i-DNS.net suggested that ICANN work "hand-in-hand with MINC, AINC, JDNA (and other regional or global legitimate consortiums/bodies formulated to facilitate the development of Internationalized Domain Names) as well as in-country authorities and linguistic experts in the selection of these multilingual variants of TLD's. As per its credo, ICANN should work closely with all Internet stakeholders and take on the role of a coordinating body for all local policy-formulating organisations."

CNNIC echoed the sentiment "that without proper IDN management policy, there is a danger of 'balkanization' of the Internet." To avoid this result, CNNIC stressed that IDN management should not be controlled by commercial interests. Cooperative organizations formed by the Internet communities who speak languages other than English should play an important role in relevant IDN management, provided that they operate within the DNS and under the coordination of ICANN. ICANN and the IDN community should start with the easy issues before moving to the hard ones. Specifically, ICANN and the ccTLD managers should first work cooperatively to develop appropriate .[IDNccTLD]. Once those are in place, ICANN, the ccTLD managers, and the appropriate regional organizations can address the far more complex issue of .[IDNgTLD].

Kilnam Chon identified an additional wrinkle: languages such as Tamil and Kurdu which are not the major language in any country. For these languages, there may not be an appropriate ccTLD manager. Similarly, Eric Brunner-Williams said that ICANN should attempt to meet the needs of "endangered," "minor," or "lesser taught" languages.

8. (Follow-up question.) Several respondents indicated that cybersquatting should be fought through greater use of regional dispute resolution procedures. Should ICANN encourage the development of these RDRPs? Should it establish criteria for RDRP providers? Or should it encourage the existing UDRP providers to increase the number of panelists familiar with non-Western languages?

TWNIC suggested that ICANN allow ccTLD managers to establish their own RDRPs. UDRP providers should cooperate with the ccTLD RDRPs to solve IDN related disputes. Eric Brunner-Williams stated that ICANN should require existing UDRP providers to increase the number of panelists familiar with non-Western languages, and to delegate responsibility to regional providers. i-DNS.net noted that UDRP is an English based system which must be adapted when dealing with local languages. In particular, the dispute should be managed in the local language, not English.

1. What IDN services do you currently offer? Please provide materials (such as promotional materials or advertisements) describing these services. How much do you charge for these services, and how do these prices compare with the prices for the non-IDN equivalent?

Several respondents currently offer IDN registration services. TWNIC offers registration for free; VeriSign GRS and JPNIC charge the same for IDN registration as for ASCII registration. Several respondents provide software and other tools relating to IDN activities, including IDN resolution. i-DNS.net also provides DN mail services.

2. Are you registering [IDN].gTLD, [IDN].ccTLD, or [IDN].[IDN]? Please describe any other domain names you may be registering.

Walid is registering [IDN].[IDN]; VeriSign GRS is registering [IDN]. gTLD; several country registries are registering [IDN].ccTLD. JPNIC also indicated that it is offering registration of mixed Japanese/Latin character strings.

Walid provides only IDN registrations, while most other respondents register domains in both IDN and Latin scripts.

4. Are the IDNs you have registered "live"? That is, can they be resolved in an end-user application, or are you just offering pre-registration of IDNs?

IDNs registered in the Walid registry are useable with the Walid WorldConnect client software. TWNIC users can resolve their IDNs in web and email applications. JPNIC IDNs can be resolved in end-user applications. In the VeriSign GRS testbed, IDNs are still designated as a third level domain, where resolution is possible in an end-user application. The RealNames system, for example, currently offers IDN resolution through the VeriSign testbed.

Some respondents indicated that they would go live once the IETF adopted a standard.

6. What technology do you employ, or do you intend to employ, for your IDN system?

VeriSign GRS and TWNIC employ NamePrep for converting the IDN into ASCII Compatible Encoding (ACE). TWNIC also is testing BIND software to support clean 8 bit (native encoding) and UTF-8 encoding. CNNIC uses "multi 8-bit encoding." Walid employs its WorldConnect, WorldTools, and WorldApp technology for ACE transformations. Neteka offers NeDNS and NeR2R in a hybrid approach. i-DNS.net stated that its IDN technology is being adopted by more than 30 registrar, registry, and strategic partners.

7. As you know, IETF has not yet adopted standards relating to IDN. If adopted, do you intend to comply with these standards when they are adopted? Please explain your policy regarding technical standards.

Most respondents indicated that they would comply with the IETF standards when they are adopted.

Most respondents treated this information as proprietary. According to Walid's submission, VeriSign GRS has registered 920,000 IDNs in the first five months of operation. (Walid response to Question 1 of Survey B). JPNIC said that as of mid-May, it had received 50,000 Japanese domain name applications and 350,000 Latin domain name applications.

9. In what scripts do you accept registrations currently? What other scripts do you anticipate registering in the future?

Walid registers Arabic, Hindi, and simplified Chinese. VeriSign GRS accepts the 39 Unicode scripts. TWNIC accepts Latin, traditional Chinese, and simplified Chinese. JPNIC accepts Latin and Japanese scripts. Turkish characters are also available in the hep.tc domain.

10. Have you had more complications with certain scripts than with others? What sort of complications?

Several respondents said they have not experienced more complications with certain scripts. Neteka state there are such complications, and that it is important to involve the local community to establish an acceptable rule set for deploying native language domain names. CNNIC and TWNIC indicated that there are complications arising from the normalization between simplified and traditional Chinese. Additionally, the sequence of Chinese domain names is different from that of ASCII domain names. JPNIC noted that many Japanese words have multiple presentations, i.e., Katakana, Hiragana, and Kanji. Moreover, different Japanese words can have the same presentation in an ASCII string because they have the same pronunciation. Also, there are some Japanese characters that are obsolete. i-DNS.net pointed out that some scripts lack accepted encoding standards (e.g., Hindi and Tamil).

11. Of the registrants registering IDNs with you, what percentage already have domain names registered in Latin script?

Most respondents do not keep this data, but Walid estimated that 80% of IDN registrants already have a Latin registration. Another respondent indicated that the percentage is even higher - very close to 100%. i-DNS.net stated that many customers already have ASCII names, and use the IDN to point to their current site, "thus complementing their web offering and opening themselves up to a wider class of native speaking customers."

12. Before you began accepting IDN registrations, did you conduct market studies to determine the demand for IDN services? If so, what did the studies reveal?

Several respondents conducted market research, and discovered that there was interest in IDNs, particularly among existing customers. VeriSign GRS noted that by 2003, two-thirds of all Internet users will be non-English speakers.

13.To what extent are you offering IDN services as a defensive measure, i.e., because others are offering these services? To what extent are registrants registering IDNs as a defensive measure, i.e., to prevent cybersquatting?

Respondents indicated that they are offering IDN services because they perceive a significant demand for them. At the same time, VeriSign GRS acknowledged that it developed its testbed in part "as a defensive measure against alternative IDN approaches which might be contrary to the principle of a single DNS root and might not be in compliance with the evolving standards work by the IDN working group of the IETF."

With respect to their customers' motivations, respondents indicated that the registrants obtained IDN registrations because they were "interesting and valuable," however, several respondents acknowledged cybersquatting prevention.

14. What steps are you taking to prevent cybersquatting? Do you have a "sunrise" mechanism in place? If so, please describe how it works. Do you subscribe to the ICANN UDRP? If not, are you willing to consider agreeing to it, or some variant thereof?

VeriSign GRS employs the ICANN UDRP. Additionally, during the testbed period, the NSI Registrar has maintained the right to terminate a registration if it receives, within 45 days of the date of registration, a formal written objection to the registration. Walid requires registrants to agree to terms similar to the UDRP. CNNIC published Chinese Domain Name Resolution (Trial Version), and authorized the China International Economy and Trade Arbitration Committee to serve as the CDN dispute resolution service provider. TWNIC uses the ICANN UDRP, and for a sunrise period has reserved certain words to prevent abusive registration. Tonga operates its registry strictly on a first-come, first-serve basis. It is unlikely to subscribe to the ICANN UDRP because of its policy of respecting the confidentiality of the registrant. JPNIC employed a one month sunrise period when it began accepting IDN registrations, and now uses a localized version of the UDRP.

15. Do you offer a Whois database? If so, for what purposes? If not, do you intend to do so in the near future?

Walid, VeriSign GRS, NSI Registrar, i-DNS.net, CNNIC and TWNIC all offer IDN Whois databases of some sort. JPNIC offers a Whois database for solving technical problems; transparency of registration; providing information for dispute resolution purposes; and analysis in academic studies.

16. How are you marketing your IDN services? To what extent are customers informed about the tentative nature of current IDN standards and testbeds?

NSI Registrar engages in in-country marketing. Walid markets its services primarily by establishing relationships with ccTLD, gTLD registries, and regional partners. Respondents said they informed registrants that IDN standards have not yet been adopted.

TWNIC stressed that the development of an IDN system must consider the local user's culture and customs, not just solutions to technical problems. It urged the IETF to quickly adopt IDN standards, and supported the development of local testbeds by regional consortia. Neteka noted the concern in the technical community "that legacy servers would break or choke on multilingual requests being sent over the wire. The different implementations indicate that this concern is highly overrated."

Stefan Probst noted that there were discrepancies between the services VeriSign GRS and Register.com advertised on their websites, and the services actually available at that time.

18. (Follow-up question.) During the public forum discussion of IDNs at the Stockholm meeting, several members of the public suggested that there are providers of IDN services who may seek to develop an alternate root or who are misrepresenting the nature of their services. Who are these providers? What proof is there of their activities?

An anonymous respondent cited Japanese newspaper articles referring to a Tokyo based company, eJapan DNS Corporation, which has started registering [IDN].[IDN] names. They currently offer three TLDs -- .kaish (in Kanji), .net (in Katakana), and .game (in Katakana). TWNIC notes that there is no clear definition of an alternate root.

TWNIC believed that a trusted single root manager is needed, but it encouraged the development of [IDN].[IDN] testbeds before standards and managing rules are adopted. "ICANN should encourage the testbed if it is [kept] closed, stable, and does not interfere [with] the operation of [the] current single authoritative root DNS structure."

i-DNS.net stated that providers should accurately describe to the public their approach to IDN services, and should adhere to that approach. ICANN should be wary of placing itself in a position of overseeing the accuracy of these descriptions.

The Working Group is extremely grateful for the input it has received from the ICANN community. Based on this information, the Working Group would like to make the following observations and recommendations.

The RFCs setting forth the basic specifications for the DNS, as well as the U.S. Government's Green and White Papers which led to the formation of ICANN, do not specifically address the issue of IDNs. However, they do articulate a set of values, which should guide ICANN as it considers IDNs. These values, of course, are stability; competition; bottom-up coordination; and representation.

If not handled properly, IDNs can pose a serious threat to the stability of the Internet. If a functioning IDN system is not deployed rapidly enough, there is a real possibility of the Internet fracturing along character set and national lines. In the absence of central coordination, the likelihood of name collision, and resulting consumer confusion, could increase significantly.

Accordingly, given "ICANN's prime directive of preserving the stability of the Internet" (A Unique, Authoritative Root for the DNS at page 6), ICANN should do everything in its power to facilitate the adoption of an IDN standard by the IETF. It should urge members of the IETF IDN WG to find expeditiously the best solution, which can be adopted and implemented in a timely fashion.

Of course, ICANN's ability to hasten the adoption of a standard is limited; adoption of an IDN standard ultimately is in the hands of the IETF, not ICANN. However, there are several significant policy -- as opposed to technical -- decisions concerning IDNs which properly are within ICANN's jurisdiction. ICANN should begin considering these policy issues on the assumption that the IETF will adopt a standard in the near future.

For example, the UDRP may require adjustment to accommodate IDNs. Clearly, the existing dispute resolution service providers will need to find panelists who can read and understand the IDN scripts. Additionally, ICANN will need to decide whether to encourage the establishment of regional dispute resolution service providers, and determine whether its existing accreditation standards need to be revised for these regional providers. Other changes in the UDRP system may be needed as well.

Perhaps even more significantly, ICANN will have to determine its general approach to top level IDNs. Top-level IDNs are both culturally significant and commercially valuable, and the IDN community is eagerly awaiting their deployment. Even if the IETF agrees on a standard, ICANN's mishandling of the top level IDN issue could encourage the development of alternate roots, which would threaten the stability of the Internet.

There are at least two alternatives for top level IDNs. First, ICANN can decide to allocate to each ccTLD a single top level IDN, which identifies that ccTLD. For example, ICANN can allocate to JPNIC .[JP in Japanese script]. JPNIC then would be free to register second level domains in Japanese script as follows -- [Japanese script].[JP in Japanese script]. In this manner, the universe of IDN top-level domains would in essence be limited to a translation of the ccTLD identifiers.

Second, ICANN could select global top-level IDNs. Presumably ICANN would perform this selection in consultation with the relevant ccTLD managers and regional organizations.

Not surprisingly, each approach has strengths and weaknesses. The great virtue of the first approach is its simplicity. ICANN would have to work out with the ccTLD what its identifier would be in its local script -- e.g., JP in Japanese script -- and that would be the end of ICANN's involvement. The downside of this approach is that all the global TLDs would remain in ASCII; there would be no .[com or biz in Japanese script]. This could lead to pressure for alternate roots supporting such top level IDNs. Additionally, this approach could lead to questions whether the Internet was truly globalized and really represented the global community of Internet stakeholders.

The second approach would address these concerns, but would be extremely difficult for ICANN to administer. Last November, ICANN has approved seven new gTLDs. Could ICANN administer multiple gTLDs for each script? This could amount to literally thousands of gTLDs. Moreover, the process of selecting IDNgTLDs and their registries could be extremely volatile for the more desirable top level domains. The country code registries might feel that they deserved a right of first refusal for these domains.

Yet another approach would be for ICANN to start with the easier, first approach, and then pursue the second, more difficult one.

The GAC, in its Melbourne Communiqué (10 March 2001) identified with respect to IDNs "three key public policy areas [which] need to be kept at the forefront of the considerations of ICANN, its Supporting Organizations, and the broader Internet community:

We believe that the GAC has identified the correct policy areas which require further consideration by ICANN at this time so that it is prepared when the IETF approves an IDN standard. We recommend that the ICANN Board charter a steering committee to study these three policy areas and provide it with recommendations. The steering committee should consist of representatives of the supporting organizations, the GAC, and this Working Group.

Following the GAC Communiqué, the steering committee should consider these issues:

1) The prevention of cybersquatting and resolution of trademark disputes in IDN environments.

2) The application of principles of competition, market access, consumer protection, and intellectual property protection.

3) Interoperability of the present and future Internet, including the use of testbeds.

The steering committee should present its initial work plan and schedule at the ICANN annual meeting to be held in Marina Del Rey in November 2001.