Can anyone open it and post it [Archive] - IDN Forums

bumblebee man

26th July 2010, 11:17 PM

Here you go:

--------------------------------------------------------------------------

JIG Initial Report on Single Character IDN TLDs
Date: 7 23 July 2010
Version: FINALDRAFT2.0

This report is intended to be a document to solicit input from the community. The document is a preliminary stocktaking of policy considerations as well as possible approaches to address such considerations for the implementation of Single Character IDN TLDs for IDN gTLDs and IDN ccTLDs.

The JIG (Joint ccNSO-GNSO IDN Working Group) was created to discuss issues of common interest between the ccNSO and the GNSO on IDNs (Internationalized Domain Names), especially IDN TLDs. The JIG has identified 3 issues of common interest to date:
1. Single Character IDN TLDs
2. IDN TLD Variants
3. Universal Acceptance of IDN TLDs

This report is specific to issue 1. Single Character IDN TLDs.

Background of Related Works

The work on Single Character IDN TLDs at the JIG builds on the findings described in the IDN-Implementation Working Team – Final Report (http://www.icann.org/en/topics/new-gtlds/idn-implementation-working-team-report-final-03dec09-en.pdf).

Recommendation 3 of the Final Report specifies that:
3.1 The team does not recommend the banning of one-character gTLDs.
3.2 The team recommends that further ramifications of this issue be addressed by policy bodies such as the ccNSO and GNSO.

In terms of defining String Length, the report also specified that: The team suggests using the term “grapheme cluster” where a combining sequence of a base character and combining mark(s) appears to be a single character, using the definition of an “extended grapheme cluster” from section 3 of Unicode Standard Annex #29.

The report also established that: There seem to be no technical reasons for restricting one-character IDN TLD labels.

During the deliberations of the New gTLD PDP, a GNSO IDN WG was formed in November 2006 (http://gnso.icann.org/issues/idn-tlds/idn_working_group-18nov06.htm) to address policy issues that may arise from the introduction of Internationalized Domain Names at the top level (IDN TLDs). The IDN WG produced a final Outcomes Report (http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm) in March 2007. Recommendations from the Outcomes Report were eventually incorporated into the GNSO Final Report on the Introduction of New gTLDs (http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm). The Reserved Names working group (formed as part of the New gTLD PDP) also deliberated on issues relevant to the introduction of IDN gTLDs. The Reserved Names WG Final Report (http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm) was also incorporated into the GNSO Final Report on the Introduction of New gTLDs. On the issue of Single Character IDN TLDs, the relevant recommendations include:

5. Single and Two Character IDNs: Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case-by-case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS with particular caution applied to U-labels in Latin script (see Recommendation 10 below).

6. Single Letters: We recommend reservation of single letters at the top level based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered.

8. Single and Two Digits: A top-level label must not be a plausible component of an IPv4 or IPv6 address. (e.g., .3, .99, .123, .1035, .0xAF, .1578234)

10. Two Letters: We recommend that the current practice of allowing two letter names at the top level, only for ccTLDs, remains at this time. Examples include .AU, .DE, .UK.

In considering an IDN ccTLD Fast Track, the ccNSO council put forward a charter (http://ccnso.icann.org/workinggroups/idnc-charter.htm), which was approved by the ICANN board at the Los Angeles meeting in October 2007, for the establishment of the IDNC Working Group, comprised of members of the GNSO, ccNSO, GAC, ALAC, SSAC, representative of the technical community, and ICANN staff. The IDNC produced a Final Report (and Board Proposal) on the Fast Track Process for IDN ccTLDs in June 2008 (http://ccnso.icann.org/workinggroups/idnc-wg-board-proposal-25jun08.pdf). On the issue of Single Character IDN TLDs, the relevant recommendations from the Final Report include:

D: Fast Track only for non-Latin scripts: The possibility of IDN ccTLDs being delegated in Latin script is a matter that will be considered as part of the ccPDP. Accordingly, in the Fast Track, the script has to be a non-Latin script to avoid pre-empting the outcome of the ccPDP.

Meaningfulness Requirement: For purposes of the Fast Track the string used must be meaningful in the Official Language.

Technical Requirements [#8]: No names that are shorter than two characters in non-ASCII are used.

The JIG accepts the results of the above prior works as a basis for its work on Single Character IDN TLDs.

Besides the IDN-Implementation Working Team Final Report, the GNSO Final Report on the Introduction of New gTLDs, and the Final Report of IDNC Working Group, in conducting its work, the JIG is also guided by the following:
• The overarching requirement to preserve the security and stability of the DNS;
• Compliance with the IDNA protocols and ICANN IDN Guidelines;
• Input and advice from the technical community in respect to the implementation of IDNs;
• Draft New gTLD Applicant Guidebook (DAG – http://www.icann.org/en/topics/new-gtlds/draft-rfp-clean-28may10-en.pdf) and subsequent versions as they become available, along with corresponding comments received; and,
• IDN ccTLD Fast Track Final Implementation Plan (http://www.icann.org/en/topics/idn/fast-track/idn-cctld-implementation-plan-16nov09-en.pdf) and relevant subsequent updates.

Furthermore, the JIG refers to the ongoing IDNccPDP, the Policy Development Process (ccPDP) for the long term implementation of IDN ccTLDs, and the two working groups formed: ccNSO IDN PDP Working Group 1 (http://ccnso.icann.org/workinggroups/idn-pdp-wg1-charter.pdf), to report on and identify a feasible policy for the selection and delegation of IDN ccTLDs associated with the territories listed in the ISO 3166-1; and, ccNSO IDN PDP Working Group 2 (http://ccnso.icann.org/workinggroups/idn-pdp-wg2-charter-23mar10-en.pdf), to report on changes to Article IX and relevant Annexes in the ICANN Bylaws to include IDN ccTLD's as full members in the ccNSO on equal footing as the current members.

Issues of Policy Aspect for Single Character IDN TLDs

The JIG has identified the following policy considerations to be addressed for the implementation of Single Character IDN TLDs:
1. Possible confusion with reserved single character ASCII TLD strings
2. Whether special financial considerations should be considered
3. Whether due to the relatively smaller pool of possible names that special allocation methods should be considered
4. Whether due to the relatively shorter string, it may be easier for users to make mistakes, and that special policies should be considered
5. What Whethershould additional criteria should be introduced to qualify be the policy for distinguishing between a Single Character as an IDN ccTLD orand a Single Character IDN gTLD
6. Wheather special policies are required to address usability of Single Character IDN TLDs given existing application environments

Preliminary Viewpoints on the Identified Issues:

The JIG is of the viewhas also identified that, while the above are in principle issues of common interest between IDN ccTLDs and IDN gTLDs, qualification of a Single Character IDN TLD as IDN gTLD or IDN ccTLD imply different (policy) implementation, while others can be certain issues may lend itself to policy implementations that could be applied toacross both IDN ccTLDs and IDN gTLDs. The JIG is of the opinion that issue 5 should be addressed first.
, while others may require different implementations.

Among the other five6 issues identified, issuess 1, 5 and 6 are assumedseems to belend itself to (policy) implementation issues that could be applicable toied across both IDN ccTLDs and IDN gTLDs, while issues 2 and 3 seems to require differentiated approaches implementation application. Issue 4 seems to be a topic areaone whereich a similar approach can be taken, however thewhile specific implementations will may be different.

Each issue will be further described below, along with some preliminary viewpoints on possible ways to address the issues and further comments on the issue itself. For “possible ways to address the issue”, commonality as well as where different policy implementation may be useful are further explained.

Issue 1. Possible confusion with reserved single character ASCII TLD strings
Description of Issue: Based on the GNSO new gTLD policy recommendations as well as the general ASCII ccTLD framework of following the 2 character code of the ISO3166-1 list, single character ASCII TLDs are reserved. While it is understood that there clear differences between ASCII TLDs and IDN TLDs, the introduction of Single Character IDN TLDs which may conflict with the set of ASCII reserved names may potentially introduce TLDs contrary to the recommended policies.
Possible Ways to Address Issue: Common Approach:
• A policy may be developed that is similar to the handling of two character IDN TLDs as specified in version 4 of the Draft Applicant Guidebook (http://www.icann.org/en/topics/new-gtlds/draft-rfp-clean-28may10-en.pdf) in Section 2.2.1.3.1 DNS Stability: String Review Procedure, under Part III - Policy Requirements for Generic Top-Level Domains. More specifically, that a Single Character IDN TLD string will not be approved if it is visually similar to any possible one character ASCII string.
• A policy may be developed that is similar to that for the IDN ccTLD Fast Track where only certain scripts are allowed (or not allowed) for applying for Single Character IDN TLDs. For example, it may be possible to specify that only ideographical scripts are acceptable for Single Character IDN TLDs.
• A combination of the above may also be possible. For example, a policy may specify that Single Character IDN TLDs based on characters from the Latin, Greek, and Cyrillic script blocks are intrinsically confusable with possible single character ASCII TLDs which are reserved. Therefore, applied-for strings that consist of single Greek, Cyrillic, or Latin characters are by default presumed to be confusable unless exceptions are made in specific cases. Furthermore that a set of ranking criteria to be setup to guide experts on the string evaluation panel, such as: [3] the character is visually identical to an ASCII character, [2] the character is visually confusable to an ASCII character, [1] the character is visually distinct from an ASCII character.
Other Comments: Based on the GNSO new gTLD policy recommendations, single letter (i.e. A-z) ASCII TLDs are recommended to be reserved, while single digit ASCII TLDs (i.e. 0-9) are reserved based on the recommendation which specifies that a top-level label must not be a plausible component of an IPv4 or IPv6 address. A single hyphen (“-“) is also not allowed based on the general rule that a domain label not begin or end with a hyphen.

Based on the IDN ccTLD Fast Track (IDNC Final Report), a selected IDN ccTLD string must not be shorter than 2 non-ASCII characters. There may be interest to consider revising the IDN ccTLD Fast Track policies. The IDN ccPDP is ongoing and has not yet discussed any restrictions on the length of the TLD string.

GNSO Reserved Names working group report, ratified into the GNSO New gTLD Recommendations specified allowing single character IDN TLDs: Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case-by-case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS with particular caution applied to U-labels in Latin script. The final report from the JIG should address how such “case-by-case” consideration could be implemented.

Considering that two letter ASCII TLDs are recommended to be reserved for potential ccTLDs, the possible confusion of a single character IDN to a possible two letter ASCII TLD should also be considered.

The IDN Implementation Work Team Final Report also explained (in Section 4.1.2) that:

Rule 1: One-character IDN TLD labels should be restricted pending further analysis.
1a. Analysis is required of the potential impact of relaxing the restriction on the allocation of one-character IDN TLD labels.
1b. Until such analysis is conducted, the impact understood, and appropriate reviews completed, one-character IDN TLD labels should be restricted.

Rule 2: The preceding rule should apply to labels containing two or more characters that are visually confusable with a single-character (for example: a label composed of one character + one or more combining marks).

Version 4 of the Draft Applicant Guidebook for new gTLDs already takes into consideration Rule 2. The final report from the JIG should address the issue. This document is a preliminary collection of issues of potential impact and a solicitation from the community on impact for such analysis.

Issue 2. Whether special financial considerations should be considered
Description of Issue: Single Character IDN gTLDs may be considered “premium real estate” due to the general desirability of shorter domain names. The question is whether special financial considerations, such as additional application fee, special ICANN fees or special contention resolution mechanisms should be used for such applications.
Possible Ways to Address Issue: IDN gTLD Considerations: IDN ccTLD Considerations:
• For IDN gTLDs, since it should follow the new gTLD process, there is already substantial consideration for application fees (Module 1 of the Draft Applicant Guidebook) as well as for contention resolution (Module 4 of the Draft Applicant Guidebook) through an auction mechanism. Therefore, the same process can be used for Single Character IDN gTLDs.
• Section 2.2.1.4.1 of version 4 of the Draft Applicant Guidebook for new gTLDs introduces the prohibition of names considered to be a representation of a country or territory name: “Applications for strings that are country or territory names will not be approved, as they are not available under the New gTLD Program in this application round.” Single Character IDN ccTLDs that meet the particular criteria will therefore not be available based on the new gTLD process. • For the IDN ccTLD Fast Track, the selected IDN ccTLD string must meet the meaningfulness requirement, which means that the TLD string must be a meaningful representation of a country/territory name in an official language of the particular country/territory. The GAC Interim Principles on IDN ccTLDs (http://gac.icann.org/system/files/Nairobi_Communique_0.pdf – Annex I) specifies that: 19. Competing or confusingly similar requests should be dealt with on a case by case basis and resolved in consultation with all concerned stakeholders; 20. Policies for dealing with multiple applications, objections to applications or disputes that are currently applied for ASCII ccTLDs should be equally applied to IDN ccTLDs. Furthermore, Section 5.4 (http://gac.icann.org/web/home/ccTLD_Principles.rtf) under the section for “ROLE OF GOVERNMENT OR PUBLIC AUTHORITY” of the GAC ccTLD principles states that: The relevant government or public authority should ensure that DNS registration in the ccTLD benefits from effective and fair condition of competition, at appropriate levels and scale of activity. As such, the issue of financial consideration would perhaps best be considered by consultation with governments concerned on a case-by-case basis.
Other Comments: The IDN Implementation Working Team – Final Report posits that “there are significant economic considerations associated with the introduction of one-character TLDs.”

The IDN ccPDP WG 1 may need to further consider the matter of financial and economic impact for Single Character IDN ccTLDs.

Principle C of the IDNC WG Final Report specifies that the purpose of the Fast Track be to meet pressing demand, therefore it could be understood that there could be significant economic impact against not allowing such IDN TLDs. Principle E of the Final Report meanwhile specifies that the proposed string and delegation request should be non-contentious. It can therefore be alleged that should there be contention, including matter of financial or economic impact, they would have to be addressed by the applicant.

Principles C and E of the IDNC WG Final Report for reference:

C: The purpose of the Fast Track is to meet pressing demand
The Fast Track should only be available where there is a pressing demand in the territory. This is evidenced by the readiness of the selected delegate and relevant stakeholders in the territory to meet the requirements to introduce an IDN ccTLD under the Fast Track.

E: The proposed string and delegation request should be non-contentious within the territory
Delegation of an IDN ccTLD should only be possible in the Fast Track where the IDN ccTLD string is non-contentious within the territory and the designation of the selected delegate is non-contentious within the territory. This is evidenced by the support/endorsement of the relevant stakeholders in the territory for the selected string as a meaningful representation of the name of the territory and for the selected delegate.

Issue 3. Whether due to the relatively smaller pool of possible names that special allocation methods should be considered
Description of Issue: Because there are a relatively fewer total number of possible Single Character IDN TLDs, as compared with two or more character IDN TLDs, the question is whether such a scarcity merits special consideration for a different allocation mechanism than for two or more character IDN TLDs.
Possible Ways to Address Issue: IDN gTLD Considerations: IDN ccTLD Considerations:
• Besides the utilization of an auction mechanism for contention resolution, under Module 4: String Contention Procedures of the Draft Applicant Guidebook, an extensive mechanism for Community Priority Evaluation is also incorporated in Section 4.2 to give priority to Community-based new gTLDs. While the auction mechanism addresses the financial consideration and economic impact of Single Character IDN gTLDs, the Community Priority Evaluation process addresses the social considerations for the allocation of TLDs as a scarce resource. • For IDN ccTLD Fast Track, the same conditions as described in Issue 2 applies. More specifically: the meaningfulness requirement; the pressing demand test (Principle C), the non-contention condition (Principle E); the GAC ccTLD Principles on competition; and, the GAC Interim IDN ccTLD Principles addressing contention; together provides a framework for address the issue of social and economic impact of allocating Single Character IDN ccTLDs.
Other Comments: While the absolute number of possible Single Character IDN TLDs is clearly smaller than the absolute number of possible two or more character IDN TLDs, the question of scarcity, and its corresponding value, of TLD strings may better be described based on the uniqueness requirement. As an example, the scarcity of the possibility of having a “.com” TLD and the scarcity of a “.中国” TLD and the scarcity of a “.名” TLD are essentially the same (i.e. they are equally scarce because there can exist only one “.com” and there can exist only one “.中国”, etc. respectively).

The IDN Implementation Working Team Final Report also makes the observation that “limiting IDN TLD labels to a minimum of two-characters eliminates a large number of meaningful words in some languages such as Chinese in which almost every single character is a meaningful word.”

Furthermore, the argument that smaller pool of possible names require different policies appear to be flawed in that, should the reasoning hold, then it would require that policies for 3 character TLDs differ from those for 4 characters, which in turn needs to be different for 5 characters, and so on, because each “pool” (3 character / 4 character / 5 character…) would be different in size.

Issue 4. Whether due to the relatively shorter string, it may be easier for users to make mistakes, and that special policies should be considered
Description of Issue: A concern was raised for Single Character IDN TLDs in that because there is a smaller number of possible single character IDN TLDs (as compared to two or more character IDN TLDs), there is a higher chance for a user to mistype the Single Character IDN TLD which coincides with another Single Character IDN TLD. The question is whether due to such additional potential user confusion that special policies need to be in place for Single Character IDN TLDs.

NOTE that there is a subtle but critical difference between the probability of mistyping a TLD string versus the probability of mistyping a TLD string but ending up accessing another existing domain under a different TLD.
Possible Ways to Address Issue: Common Approach:
• The issue pertains to causing user confusion, and therefore should be addressed based on policies established to avoid such confusion. Both the policies for new gTLDs as well as IDN ccTLDs already includes extensive considerations for avoiding detrimentally confusingly similar strings to be introduced.
IDN gTLD Considerations: IDN ccTLD Considerations:
• The GNSO new gTLD policy recommendations specified in Recommendation 2 that: Strings must not be confusingly similar to an existing top-level domain or a Reserved Name. The IRT (Implementation Recommendation Team) Final Report (http://www.icann.org/en/topics/new-gtlds/irt-final-report-trademark-protection-29may09-en.pdf) and the STI (Special Trademark Issues) Review Team Recommendations (http://gnso.icann.org/issues/sti/sti-wt-recommendations-11dec09-en.pdf) also contained significant recommendations to guard against user confusion caused by the introduction of new gTLDs. Such considerations are equally applicable to Single Character IDN gTLDs, and many of which have been incorporated into the Draft Applicant Guidebook to appropriately address user confusion issues that applies equally to Single Character IDN gTLDs. Furthermore, Module 3 of the Draft Applicant Guidebook allows for raising an objection based on String Confusion – that the applied-for gTLD string is confusingly similar to an existing TLD or to another applied for gTLD string in the same round of applications. Such would safeguard against also any abusive application of a gTLD for the purposes of “catching” traffic intended for another TLD based on a technique commonly known as “typo-squatting”. This safeguard against typo-squatting would apply to Single Character IDN gTLDs as well. The Trademark Post Delegation Dispute Resolution Procedure (Trademark PDDRP) further extends this safeguard for trademark holders to be able to initiate a dispute against a TLD registry that is: (a) taking unfair advantage of the distinctive character or the reputation of the complainant's mark; or (b) unjustifiably impairing the distinctive character or the reputation of the complainant's mark; or (c) creating an impermissible likelihood of confusion with the complainant's mark. • Section 5.5: String Confusion and Contention under Module 5 of the Final Implementation Plan for IDN ccTLD Fast Track Process (http://www.icann.org/en/topics/idn/fast-track/idn-cctld-implementation-plan-16nov09-en.pdf) safeguards against String confusion issues involving two or more strings that are identical or are so confusingly similar that they cannot coexist in the DNS, such as: Requested IDN ccTLD strings against existing TLDs and reserved names; Requested IDN ccTLD strings against other requested IDN ccTLD strings; and, Requested IDN ccTLD strings against applied-for gTLD strings. Furthermore, as described in Issue 2. above, The GAC Interim Principles on IDN ccTLDs (http://gac.icann.org/system/files/Nairobi_Communique_0.pdf – Annex I) specifies that: 19. Competing or confusingly similar requests should be dealt with on a case by case basis and resolved in consultation with all concerned stakeholders; 20. Policies for dealing with multiple applications, objections to applications or disputes that are currently applied for ASCII ccTLDs should be equally applied to IDN ccTLDs.
Other Comments: The argument that a shorter IDN TLD string would result in higher probability of a user mistyping the IDN TLD and ending up accessing another IDN TLD is flawed. First of all, it could equally be argued that the possibility of making an error would be greater for multiple-character IDN TLDs than single character IDN TLDs, and therefore open up to more possibilities for "typo attacks” (i.e. if an IDN TLD is 2 characters wrong there is a higher number of total possible mistypes of that IDN TLD than a Single Character IDN TLD would have). Secondly, the presupposition that since there is a smaller number of possible Single Character IDN TLDs the probability of a mistype coinciding with one is higher is purely speculative, as such coinciding Single Character IDN TLD must already be delegated and thus must have to pass through the confusable tests. Possibility for abusive operation of a Single Character IDN TLD for such purpose is therefore no greater than multi-character IDN TLDs.

There is a view that for the languages for which Single Character IDN TLDs would be most useful are languages for which the input of a Single Character is likely to involve multiple keystrokes. For example Chinese and Korean.

Issue 5. What should be the policy for distinguishing between a Single Character IDN ccTLD and a Single Character IDN gTLD
Description of Issue: Before the introduction of IDN ccTLDs, there existed a distinguishing feature between ccTLDs and gTLDs wasin that ccTLDs awere 2 ASCII characters in length and listed on the ISO 3166-1 standard, while gTLDs consisted of 3 or more ASCII characters. According to theThe IDN ccTLD Fast Track rules anintroduced the possibility for IDN ccTLDs string must be a at least wo characters (U-label) and needs to represent a meaningful representation of the name of the territory in an offical language of that territoryto be more than 2 characters. According to the, while the new gTLD process process will allow IDN gTLDs shorter than 3 characters will be allowed and in the first round of applications territory names can not be applied for.. The issuequestion is whether additionalit is distingsuishing factors needappropriate to proposedadopt tothe emerging qualifydistinguishing a factors for Single Character IDN TLDs as IDN ccTLD or IDN gTLDIDN ccTLD and IDN gTLD for the introduction of Single Character IDN TLDs for both IDN ccTLDs and IDN gTLDs may obsolete that distinction. The question is whether a different distinguishing factor may be required and how it could be devised.
Possible Ways to Address Issue: Common Approach:
• The IDN ccTLD Fast Track requires that a selected string be a meaningful representation of the country or territory name in an official language of the country or territory corresponding to an ISO3166-1 code used for a ccTLD. The requirement that an IDN ccTLD be a meaningful representation of the country or territory name corresponding to an ISO3166-1 code used for a ccTLD would provide an appropriate distinction for an IDN ccTLD in general, including Single Character IDN ccTLDs should they be introduced.
• If a Single character IDN TLD is considered an IDN ccTLD it will be delegated in accordance with the practice for delegation of (ASCII) ccTLD’s. If identified as gTLD the rules of the new gTLD will apply, including the delegation rules contained therin. Another distinguishing factor would be the process through which an IDN TLD is allocated.
• An IDN TLD allocated based on the IDN ccTLD Fast Track process, or an IDN ccTLD process once the IDN ccPDP is complete and implemented, would be considered an IDN ccTLD. An IDN TLD allocated based on the new gTLD process would be considered an IDN gTLD.
• The IANA Root Zone database should correctly identify Single Character IDN ccTLDs as IDN ccTLDs and Single Character IDN gTLDs as IDN gTLDs.
Other Comments: During the discussion of the IDN ccTLD Fast Track, it was quickly understood that for IDN ccTLDs, the 2 character limitation may no longer be appropriate. IDN ccTLDs could possibly be more than 2 characters long, which means that using TLD string length as a condition for consideration the distinction between IDN ccTLDs and IDN gTLDs would not be appropriate for IDN TLDs.

The inclusion of accepting 2 Character IDN gTLDs into the new gTLD process (based on version 4 of the Draft Applicant Guidebook) also further explains that the TLD string length based approach to distinguishing between IDN ccTLDs and IDN gTLDs would become inappropriate for IDN TLDs.

Issue 6. Wheather special policies are required to address usability of Single Character IDN TLDs given existing application environments
Description of Issue: Certain applications and databases may be designed to recognize domain names with TLD length of 2 or more characters. For example registration systems, spam filters, auto-complete features and other services may inadvertently disallow or not recognize domain names with Single Character IDN TLDs. The question is how if any special policies can be considered to address such an issue.
Possible Ways to Address Issue: Common Approach:
• This is an issue related to the “Universal Acceptance of All Top-Level Domains” (http://www.icann.org/en/topics/TLD-acceptance/). Since the introduction of new gTLDs that is longer than 3 characters, the issue has been identified as one which would require community-wide efforts to address. The same would apply for Single Character IDN TLDs (and equally for IDN ccTLDs and IDN gTLDs). Policies to promote the universal acceptance of all TLDs based on the authoritative root zone should be encouraged, but such undertakings should not impede the introduction of Single Character IDN TLDs.
Other Comments: In a statement issued on 18 October 2004, ICANN had understood that “Some TLD names (strings) are rejected by some service providers or applications because the strings exceed three characters in length (e.g. .museum or .aero) or do not meet some other formatting criteria. To facilitate and foster corporation among registry operators, ISPs, and other who deal with domain names on a regular basis, a discussion forum has been opened on this topic <http://forum.icann.org/lists/tld-acceptance/>.”

Further as expressed at the description of the forum (http://www.icann.org/en/topics/TLD-acceptance/), it is also understood that: “In order for the full resources of the Internet to be globally available for all users, service and application providers must make use of the complete range of top-level domains (TLDs)… Rejection of some TLD strings due to outdated length parameters or other erroneous formatting criteria can be avoided by reliance on authoritative information. As described in Support of New Top-Level Domains by Internet Infrastructure Operators and Application Providers (2003), and Evaluation of New gTLDs (2004), several technical acceptance issues were associated with the gTLDs introduced in 2000-2001. This was particularly true for TLDs of more than 3 characters.”

As described in Support of New Top-Level Domains by Internet Infrastructure Operators and Application Providers (http://forum.icann.org/mtg-cmts/stld-rfp-comments/general/doc00004.doc):

Although the implementation of the new TLDs began in 2001, compatibility problems were found with the installed base of software used by Internet infrastructure operators (including Internet Service Providers (ISPs) and corporate network operators) and application providers (such as web hosting companies, ecommerce websites, and email services).

The underlying DNS protocols can easily support the introduction of new TLDs into the top-level zone files. However, some of the software written to use domain names was written without taking into account the addition of new TLDs. This includes DNS resolvers, provisioning software (e.g., to facilitate the creation of web sites or email services), and end-user application software (e.g., email programs and web forms).

Sometimes, as in the case of many DNS resolvers, a configuration change is all that is needed to support the new TLDs. Other times, as in the case of checking user input against expected behavior, there are problems because a fixed list of TLDs is used or TLDs are presumed to be at most three characters in length.

Some web applications use algorithms that guess or attempt to automatically complete domain name entries (e.g., search engines, directories, browsers) when a fully qualified domain name is not supplied. Problems arise when these applications use an outdated list of TLDs, or attempt to redirect users to a different TLD when the user’s intent was to lookup one of the new TLDs.

There are many pieces of software used in the Internet that make use of domain names. The problem of checking all existing software for support of new TLDs is a similar problem to that of checking software for the ability to handle dates beyond 2000.

The issue for Single Character IDN TLDs would be two-fold:
1. As a U-Label (in its native / Unicode form), a Single Character IDN TLD would be shorter than 2 characters which would be an issue similar but in reverse to those described above for TLDs which are longer than anticipated by problematic applications.
2. As an A-Label (in its ASCII Compatible Encoding form), a Single Character IDN TLD has to be longer than 3 characters by definition of the IDNA protocol, which specifies a 4-character long prefix of “xn--” for IDN labels (i.e. an IDN TLD string must be more than 4 characters long). This would mean that Single Character IDN TLDs (or for that matter, all IDN TLDs) would fall into the issues identified above when the issue of Universal Acceptance of TLDs is discussed.

This is also one of the items identified by the JIG to be an issue of common interest between the ccNSO and the GNSO, as both IDN ccTLDs and IDN gTLDs are affected equally.