Home»Documents»IAB Correspondence, Reports, and Selected Documents»2012»Response to ICANN questions concerning "The interpretation of rules in the ICANN gTLD Applicant Guidebook"
The IAB received this email in response to the IAB Statement: “The interpretation of rules in the ICANN gTLD Applicant Guidebook.”
From: Thomas Narten <firstname.lastname@example.org> Date: March 17, 2012 7:52:26 PM GMT+01:00 To: "IAB Chair" <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [IAB] The interpretation of rules in the ICANN gTLD Applicant Guidebook IAB, ICANN appreciates the attention of the IAB to the technical aspects of the introduction of Internationalized Domain Names (IDNs). This note seeks some additional clarification concerning the recent note "IAB Statement: "The interpretation of rules in the ICANN gTLD Applicant Guidebook." The IAB statement could be interpreted as a recommendation to ICANN to revise the Applicant Guidebook, or as a warning to be cautious when evaluating applied-for strings with certain properties. Every applied-for string in the new gTLD program is reviewed by the DNS Stability Evaluation Panel to determine whether whether the applied-for gTLD string might adversely affect DNS security or stability. Were the Panel to use criteria as follows, would that be consistent with the IAB recommendations: 1. The Internet Architecture Board has noted that labels that contain one or more characters with the Unicode general category property of Mc or Mn are much more likely to be the source of stability and representation problems than labels consisting entirely of characters with the general category properties of Ll, Lo, or Lm. An IDN label that contains one or more characters with the Mc or Mn property will therefore be evaluated carefully to ensure that it is appropriate with respect to the script and associated language(s). This evaluation will include a search for any language- or context-specific rendering issues that might create confusion or instability. 2. An IDN label that contains one or more characters with the IDNA derived property CONTEXTJ or CONTEXTO must be appropriate with respect to the script and associated language(s) according to unambiguous contextual rules provided by the applicant, which must be consistent with the intent of the contextual rule arrangements of IDNA. The IDNA specification warns registries to permit these characters to be used in domain name labels only after careful scrutiny, because they can easily be the cause of considerable confusion, false string matches and mismatches, and complications when the labels are embedded in identifiers. An IDN label that contains one or more CONTEXTJ or CONTEXTO characters will therefore be evaluated carefully to ensure that it is not a potential source of security or stability problems. Also, ICANN would like to inform the IAB that there are currently ten IDN TLDs in the root that have the Mc or Mn characteristics, which would not match the "most conservative" criteria under the IAB's statement. Those are: Country, String, Language, Script -------------------------------------- India, भारत, Hindi, Devanagari India, భారత్, Telugu, Telugu India, ભારત, Gujarati, Gujarati India, ਭਾਰਤ, Punjabi, Gurmukhi India, ভারত, Bengali, Bengali India, இந்தியா, Tamil, Tamil Singapore, சிங்கப்பூர், Tamil, Tamil Sri Lanka, ලංකා, Sinhalese, Sinhala Sri Lanka, இலங்கை, Tamil, Tamil Strings that have passed Fast Track string evaluation and are eligible for delegation: Bangladesh, বাংলা, Bangla, Bangla (Bengali script) The IAB's statement indicates in its third requirement that "existing TLD labels must be permitted." Is statement #3 intended to refer to the ten strings listed above, or is statement #3 intended to have a broader scope? Please note, ICANN is requesting a response from the IAB clarifying its intent as soon as possible, within one week if possible. The application window for new gTLDs has been open for many weeks and will close on April 12. The members of the Internet Community who are applying for a new IDN gTLD are at a disadvantage without some clarification of the impact of the IAB's statement on applied-for strings. We appreciate your attention to this issue. Thomas (as IETF Liason to the ICANN Board)
The following email was sent in response to the above:
From: IAB Chair <email@example.com> Date: March 26, 2012 12:41:11 PM GMT+02:00 To: "firstname.lastname@example.org" <email@example.com> Cc: firstname.lastname@example.org Subject: [IAB] Response to ICANN questions concerning "The interpretation of rules in the ICANN gTLD Applicant Guidebook" Dear Thomas, and colleagues in the ICANN Board. This note is a response to your questions of March 17, 2012 about the IAB statement of February 8, 2012, "The interpretation of rules in the ICANN gTLD Applicant Guidebook." You asked two questions: 1. Is the procedure followed by the DNS Stability Evaluation Panel consistent with the IAB recommendation? There are a great many unknowns when it comes to the use of certain classes and certain combinations of internationalized characters. It is likely that in a final specification, the use of some types and classes of characters in combination with other characters will not cause any problems in some cases, and will be problematic in other cases. In absence of a specification, our recommendation provides the 'always safe rules', for instance, excluding the general classes Mc and Mn. It is clear that ICANN might receive requests that are not inside of this rule-set and the ICANN process needs to deal with those pragmatically. The guidelines that the panel is proposing to follow seem to pragmatically align with what we consider a conservative approach, specifically since the panel not only looks at the general character clases Mc and Mn but also at characters with derived property CONTEXTJ or CONTEXTO. We assume that only if the panel assesses that there are no confusion or instability issues in either of the two types of evaluations, the ICANN board will approve said proposed TLD. 2. Is statement that "existing TLD labels must be permitted" intended to refer to the ten strings listed, or is it intended to have a broader scope? Existing TLDs that have already been allocated under the ccTLD Fast Track procedures should be retained. The IAB is currently not aware of any issues with said TLDs. However, even if they turn out to have properties that cause confusion, or problems with rendering or stability, the removal of a TLD is likely to cause stability issues even if those TLDs might be in conflict with any future specification. More generically, we see all of these IDN policy issues in terms of tradeoffs. In the case of names already approved and delegated or pending delegation under the ccTLD Fast Track, we see the stability disadvantages of removing names as exceeding the advantages of a more careful and conservative approach, especially in the context of delegations to existing ccTLD administrations and governments who have demonstrated that they can operate delegated TLDs in a responsible fashion. As such, requirement 3 says that because a new specification will be developed, existing TLDs should not be removed, even though their existence might require an exception in the specification. Finally, we realize there might be confusion about the position of the IAB on the use of A-labels in the context of the "Alphabetic Only" interpretation of RFC1123. The IAB considers the use of A-labels in TLDs a valid practice; the most conservative approach refers to the IDNA2008 specification and allows A-labels in general with the restrictions set by the other requirements. For the IAB, Bernard Aboba (IAB Chair)