Draft IDN Issue List - GNSO IDN WG

Draft 2006-12-22, Olof Nordling

Below are some questions brought up in Sao Paulo, with comments grouped per question. This does not pretend to judge whether any question/comment qualifies as a (IDN) policy issue for the GNSO. Moreover, the numbering is purely sequential without implying any priority order.

1. Should transliterations of existing gTLD strings be addressed?

Translations of gTLDs have been covered in the new gTLD discussions, concluding that no prior rights exist on that basis, but in the first IDN WG meeting in Sao Paulo it was stated that also transliterations should be addressed. This relates to the issue in the new gTLD discussions on whether confusability should cover phonetic simil arity. It involves complexities, as, for example, Chinese characters offer no clear cut solutions for transliterations or translations - they depend on context as well as on community expectations.

2. Should the next round for new gTLDs wait for the inclusion of IDN gTLDs?

In Sao Paulo, there was a desire expressed that the introduction of new gTLDs should not be delayed by waiting for a decision to introduce IDN TLDs. Whether there will be a timing issue or not is dependent both on the advancement of the New gTLD policy, including IDN policy aspects, and on the advancement of the protocol revisions and technical tests regarding IDN at the top-level. They all need to be sufficiently covered before a decision can be made, presumably by the ICANN Board, to go ahead with IDN TLD deployment. It was mentioned that community expectations are high and that it is highly desirable to have some deployment in about a year’s time.

In the Amsterdam meeting of the New gTLD Committee, there was strong support for including the possibility to reserve IDN strings in the next round, even if the IDN framework for the top-level was not yet ready. The arguments for such an approach involve recognition of the pent-up demand for IDN gTLDs as well as defusing the risk of “ASCII cybersquatting”, i.e. that someone would get for example a string .espana, foreclosing a future possible IDN string .españa (since they would be considered visually confusingly similar). The arguments against involve the risk of raising expectations with ensuing possible disappointment if an IDN TLD launch is considerably delayed, as well as lack of cl arity on how complete an application should be filed for a reservation, what application fee should apply etc.

3. Would aliasing be a preferred option, an open option or an option to discourage?

It was made clear during the Sao Paulo meetings that aliasing should be discussed without specific reference to any technical solution used to achieve this functionality. It was likewise highlighted that the aliasing issue was not an IDN issue per se, even if aliasing has raised much interest in the IDN context. It should be noted that, according to the New gTLD recommendations, each application for a new gTLD string would be regarded as applying for a separate TLD. Aliasing would map the whole sub-domain tree to an additional TLD string, which the current operator would have to apply for and gain in possible competition with others. Once that achieved, and provided aliasing is found viable and acceptable, the same domain name record could be reached via the original TLD string as well as via the alias string. This could have advantages in that there would be no need for any additional defensive registrations in the new (alias) string. The user experience could improve in the IDN case if the sub-domain tree is predominantly in an IDN script already, with an ASCII TLD string used as that has been the only option so far. Drawbacks are that the user experience could be adversely affected, or at least include negative surprises, if the new TLD string is in another script than the sub-domains that the user tries to look up, believing that the script would be consistent across the domain. There are also contentions that aliasing of existing TLDs would extend the current operators dominance on the market.

4. Should an existing domain name holder have a priority right for a corresponding domain in another script?

This question was put forward in Sao Paulo but not discussed at any depth. A few remarks could be made. First, in general, such a priority would be inconsistent with the current rules where no similar priority is given to a domain name holder wishing to register an identical domain name in another gTLD. In fact, no intellectual property rights at all are bestowed upon a domain name holder merely based on the registered domain name. The case for this could possibly be reviewed in a potential aliasing situation, which would make this a corollary topic to 3 above.

5. Given a particular script on the top-level, should that script be compulsory on lower levels also?

The ICANN IDN Guidelines state that characters within a string should be from a single script. The question was brought up in Sao Paulo whether that restriction should extend across levels for an IDN gTLD. It was noted that this is not a requirement in existing gTLDs, quite the contrary as second-level IDNs have been introduced in those gTLDs with Guidelines supporting that. This was a particular solution in response to market demand, and new IDN gTLDs would imply a fresh start with the option to apply stricter rules on consistency in scripts across levels. It was also noted, though, that levels beyond the second level may fall outside consensus policy remit and could be a matter of registrant internal freedom of decision. From that perspective, the view was put forward that rules on script consistency across levels could be limited to the first and second levels only, in order to have an enforceable policy.

6. How should countries’ claims to “rights” to scripts be regarded?

There are potential political issues in the use of scripts, as some countries/regions claim “rights” to the standards for their scripts. This was expressed in the ccTLD IDN debate in SP by the Korean ccTLD representative although not as “rights” but rather as “a need to prove the support of the respective community for accepting a TLD in its particular script”.

7. How should initial limitations in available IDN scripts for DNS be made?

It appears obvious that only a subset of the whole Unicode repertoire of scripts will be available for IDN TLDs, especially in the first round. However, technical or practical reasons for excluding some scripts/languages may also raise political issues and lead to objections from countries/communities for being unfairly treated or left behind.

8. Should a country opting for a gTLD be free to set policies for the second level?

It was put forward in Sao Paulo that a recent ITU document states that policy for a country’s ccTLD cannot be decided by another country. The current situation for ccTLDs is indeed that they have no obligations to follow any external policy-setting mechanisms (except, quite possibly, national such mechanisms, as the case may be). In analogy with this, should a country opting for a gTLD be free to set policies for the gTLD, e.g. for the second level? This would go contrary to the New gTLD recommendation that all new gTLDs should abide by ICANN consensus policies.

9. How could “grandfathering” of existing SLDs be achieved when the IDN protocols change?

The advent of an IDN protocol revision, with an inclusion-based approach that is more restrictive regarding allowed code points, prompted some comments in Sao Paulo. There are around 2 million IDN second level domains today, for which such an IDN protocol change may cause problems, calling for “grandfathering” options. Likewise, the effects of protocol changes on application software may raise issues for “grandfathering”. In the Sao Paulo discussions, it was mentioned that design criteria in the protocol revision foresee grandfathering and another comment was that the handling of technical problems due to protocol changes also invokes proportionality aspects. Also, it was mentioned regarding the protocol revision as such, that it now seems clear that the revision requires substantial individual efforts to define the limitations as there are no arithmetical ways to achieving this.

10. What requirements for change of Whois should be considered?

It was noted in Sao Paulo that there are multiple solutions already in use today for Whois regarding IDNs. It was also noted that there hasn’t been many complaints on Whois for IDNs yet, but that that may change with increased IDN use and improved IDN support in browsers and other software.

11. How to handle IDN cases of v ariants?

This question was only mentioned, not discussed, but it may certainly be complex, very dependent on script/language and also directly related to the notion of “confusingly similar”.

12. Is there a need to modify the UDRP in view of increased use of IDNs?

In Sao Paulo, staff was tasked to investigate current experience of using the UDRP for IDNs. The UDRP has been applied to IDN second-level domain disputes ever since the year 2000 by WIPO. Although the number of such cases is relatively limited so far (around 60), the experience is that the UDRP works well also for IDNs, without any obvious need for modification. The WIPO view is that any potential revision of the UDRP in the light of IDNs should be guided by actual experience of new aspects that may be gained from future cases. A more elaborate account of this has been sent separately to the IDN WG mailing list.

13. How to handle geopolitical names?

Will the community expect particular rules for gTLD strings featuring geopolitical names, like .berlin and .nyc? How to handle situations where the same geopolitical name exists in more than one location? These questions were raised in Sao Paulo. A possible additional gTLD string test was mentioned, regarding whether the string has a geopolitical significance or not. The related issues should be addressed by the GAC as well as by the ccNSO and GNSO. These are not IDN-specific issues, however, and the New gTLD recommendation foresees an objection process to proposed strings and a dispute resolution process to handle such objections. Simil arities were noted, both with the IDN-ccTLD issues (see below) and with generic names (“Orange” can be mentioned as a case in point, being a county in California as well as a trade mark for France Telecom and, of course, a fruit…), and also some agreement that strings with similar semantic meaning but in different languages or scripts should be regarded as separate.

14. How could an IDN - ccTLD be defined and deployed?

This question was a main topic during the ccTLD IDN discussion in Sao Paulo, with several interventions on the notion of community support as well as on the identification of relevant language communities. Many invoked the desirability of GAC input on these matters, including decision-making regarding registry operators and TLD strings. It was noted that a parallel list to ISO-3166 would be needed, but also that the ISO has expressed reluctance to this idea. The theme recurred during the GNSO - ccNSO IDN joint meeting. A proposal put forward was to start with one IDN-ccTLD per country, dedicated to (one of) its official language(s), with the possibility of adding others later on as need be. It was noted, however, that the notion of official languages v aries which calls for flexibility in the approach. Similarly, an idea brought forward was to use the official name(s) of each country as TLD strings, which may work well for some, but calls for flexibility as official names may be very long and clearly impractical as strings. A remark highlighted that strings should be seen as codes rather than names/words. A couple of comments addressed the potential need for IDN versions of a ccTLD for a country’s minorities, even if their languages have no official status in the country, as illustrated by the Greek-speaking population in Australia and the Maori population of New Zealand. A participant expressed concern that the potential numbers of such cases would be huge and that it would be better to start soon with a limited approach to IDN TLDs, while leaving potential extensions for future discussion. UNESCO’s assistance in relation to language communities (and possible vetting of language tables) was brought up - there are contacts established since long and discussions under way.