Skip to main content

Two-Character Letter/Letter Comments Consideration Process

This is an archive of Version October 2015 of the Two-Character Letter/Letter Comments Consideration Process webpage. Click here for the current page. Click here to view the archive index of the Authorization Process webpage and see what was updated.

As of 6 October 2015, labels that have received comments regarding their release will be evaluated using the process described in ICANN's 11 August 2015 blog post.

To submit a comment regarding a specific letter/letter label request, please go to Comment Submission Form.

View all comments submitted on or after 6 October 2015
View all comments submitted before 6 October 2015

UPDATE (4 December 2015): The comments clarification submission (Phase 1) period was extended from 5 December 2015 23:59 UTC to 8 December 2015 23:59 UTC.

Coming in December 2015: Form for Registry Operators to Submit Mitigation Measures to Avoid Confusion

View existing Two-Character Letter/Letter Comments and Mitigation Measures

Click here for the Authorization Process for Release of Two-Character ASCII Labels.

Flowchat for the Two-Character Comments Consideration Process
  1. ICANN reaches out to all relevant governments to further clarify their comments.

    ICANN will reach out to all governments that have submitted comments to better understand their concerns, including why a relevant government may believe a specific label.TLD combination causes confusion with the corresponding country code. As ICANN evaluates the responses to our outreach, comments not pertaining to confusion might be directed to recourse mechanisms outside of the Authorization Process, such as the Abuse Point of Contact, which is used when abuse is suspected.

  2. ICANN reaches out to registries to respond with a mitigation plan.

    ICANN will ask registries to respond to relevant governments' comments with measures to be implemented to avoid confusion with corresponding country codes. As with the governments' comments clarification, the registries' mitigation plans will be published.

  3. ICANN aggregates governments' comments and registries' mitigation plans to draft the criteria for approval.

    Once ICANN has received feedback within the allotted timeframe from both governments and registries, ICANN will aggregate the comments that governments have raised, as well as the mitigation measures that registries have identified. From those inputs, ICANN will endeavor to find commonality to draft the criteria by which ICANN can evaluate whether the measures identified by a registry successfully mitigate the confusion raised by the government. These draft criteria will be posted for public comment before final adoption.

  4. ICANN takes into consideration the feedback provided by community and creates finalized criteria for approval.

    Taking into consideration the feedback provided by the community during the Public Comment period, ICANN will strive to produce a finalized set of criteria for approval, which will be used to evaluate mitigation plans provided by the registries for previously commented on labels. Moreover, these finalized criteria for approval may be used to evaluate all future two-character authorization requests that receive comments from relevant governments. Considering the breadth of TLDs involved, it is conceivable that multiple sets of criteria could be adopted to apply to different subsets of TLDs such as those with a Specification 13 provision for a brand TLD.

    The current framework of the Authorization Process, whereby a registry submits an authorization request and relevant governments may submit comments, is not expected to change. However, we believe the finalized criteria for approval will help everyone with a more clearly defined standard with which ICANN can evaluate future requests.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."