ICANN Stockholm Meeting Topic: Status Report of the Internationalized Domain Names Internal Working Group of the ICANN Board of Directors
Posted: 1 June 2001
Status Report of the Internationalized Domain Names Internal Working Group of the ICANN Board of Directors
TABLE OF CONTENTS
I. ACTIVITIES OF THE IDN WORKING GROUP TO DATE
A. Formation
C. Surveys
II. SUMMARY OF SURVEY RESPONSES
III. NEXT STEPS
A. Fact Finding
APPENDICES
|
|
I. Activities of the IDN Working Group to Date
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:
1. What are the perceived technical problems raised by IDNs, what are the possible solutions, and what are the pros and cons relating to these possible solutions?
2. What are the perceived legal and other policy questions raised by IDNs, and what are the possible solutions?
3. What IDN activities are actually underway, how extensive are they, and what bearing do they have on the technical and legal issues referenced above?
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 (http://www.icann.org/committees/idn/survey-30apr01.htm), with a return date of 10 May 2001. Additionally, the surveys were emailed to numerous entities and individuals involved with IDNs. As of 20 May 2001, the Working Group received 14 responses.
Members of the Working Group have 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. MINC is conducting its own survey on IDN activities, and the Working Group looks forward to receiving those results. M. Katoh attended the Founders Meeting of the Arabic Internet Names Consortium (AINC) in Amman, Jordan, on 1 April 2001.
II. Summary of Survey Responses
Attached are the consolidated survey responses received as of 20 May 2001. As discussed below in Section III, the Working Group welcomes additional survey responses, as well as reactions to the attached responses.
The following is a brief summary of the survey responses.
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.
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. Disadvantages include the significant time which may be required to implement fixes on Internet servers throughout the world; 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).
3. Are there more problems relating to particular scripts? Why?
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.
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, 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.
Neteka is promoting a hybrid client side/server side approach.
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."
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. 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. 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 notes 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 states 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.
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.
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. Technical experts are considering various compression algorithms to increase the number of non-Latin characters which can be included in a domain name.
10. Do IDNs pose special problems for the technical operation of WHOIS databases? If so, what problems? What are the possible solutions?
Verisign GRS observes 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 claims that its technology is freely available as open source.
Stefan Probst supports 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?
Many of the respondents are active participants in the IETF IDN working group.
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 believes that if the IETF adopts a client side approach, major application suites could be upgraded "within a few months." On the other hand, Walid claims 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.
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 concur that given the wide range of IDN approaches, it is unlikely that the IETF standard will be interoperable with all IETF deployments. Neteka claims that its hybrid solution will reduce interoperability problems. Walid notes that adoption of technical standards is voluntary, but market forces will promote standardization and uniformity. Verisign, however, believes "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; 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.
16. Are there any other technical issues we should know about?
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."
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 were not able to identify empirical evidence of these positions, other than the large number of IDN registrations to date.
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."
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 observes that the translation or transliteration of foreign trademarks
into Japanese may result in a character string which infringes a Japanese
mark.
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.
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.
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.
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.
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.
3. Do you register domain names in Latin script as well, or only IDN?
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.
5. If you are not yet live, when do you anticipate going live?
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. Walid employs its WorldConnect, WorldTools, and WorldApp technology for ACE transformations. Neteka offers NeDNS and NeR2R in a hybrid approach.
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.
8. How many registrations have you accepted in each script you register?
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.
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 says 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. TWNIC indicates that there are complications arising from the normalization between simplified and traditional Chinese. JPNIC notes 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.
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 estimates that 80% of IDN registrants already have a Latin registration. Another respondent indicates that the percentage is even higher - very close to 100%.
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 notes 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. 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, 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.
17. Is there anything else we should know?
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 notes that there were discrepancies between the services Verisign GRS and Register.com advertised on their websites, and the services actually available at that time.
The IDN WG has benefited greatly from the input received from the survey respondents. Each respondent has helped further define the scope of the work that remains to be done. In light of the need for more information, the working group proposes the following steps for further fact-finding.
(1) Because of the limited amount of time given to respond to the surveys and the Working Group's desire to hear all voices of the Internet community, the Working Group welcomes additional responses to the surveys of April 30. In particular, the Working Group is eager to hear from engineers and general users. Please provide your survey responses by July 31, 2001.
(2) The Working Group would like to receive comments on this Status Report. Please submit your comments on this Status Report by July 31, 2001.
(3) The Working Group plans on issuing follow-up questions by the end of June. If you have suggestions for questions, please forward them to the Working Group as soon as possible. Please provide your answers to the follow-up questions by July 31, 2001.
The Working Group apologizes for these short deadlines, but it needs this information promptly in order to complete its next report for the Board by the September ICANN Meeting in Uruguay.
Several survey respondents indicated that ICANN should maintain IDN working groups on a long-term basis. ICANN, of course, defers to the IETF IDN WG for the setting of technical IDN standards. At the same time, parallel to the IETF IDN WG, working groups within the support organizations may focus on other IDN policy issues. The Board Internal Working Group welcomes recommendations from the ICANN and Internet communities on the structure and mission of these working groups.
In addition, the members of the Board Internal Working Group believe that the Board Internal Working Group should continue monitoring IDN developments and act as a liaison between the Board and the other IDN working groups and the IDN community at large.
Members of the WG,
Masanobu Katoh
Karl Aurbach
Ivan Moura Campos
Vinton Cerf
|
|
Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
25-Apr-2003
©2001 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.