Summary

  • ICANN uses two different controls: exact one- or two-letter ASCII strings are non-permitted at submission, while a two-character applied-for string or variant can later fail String Similarity Evaluation if it resembles a two-character ASCII string or one of its variants.
  • The panel, not the prescreening tool, owns the final determination. A useful public result should expose the decisive primary-or-variant comparison, the script and case presentation, any omitted comparison, the panel’s reasons and the 21-day challenge deadline.

Imagine an applicant that does not type a two-letter ASCII country-code label into the application system. Its proposed label uses another script and passes the basic submission checks. The applicant might reasonably conclude that the country-code boundary is no longer relevant.

That conclusion would be premature.

ICANN’s 2026 Applicant Guidebook creates a second gate. During String Similarity Evaluation, an applied-for two-character string and its variants are compared with two-character ASCII strings and their variants. If the panel finds the applied-for string or one of its variants similar to a member of that comparison category, the application does not proceed.

This is not the same control as the initial prohibition on one- or two-letter ASCII strings. It is a visual-similarity rule operating across labels, scripts and variant relationships. The distinction matters because the evidence needed to understand the first gate is not the evidence needed to understand the second.

The first gate is direct identification

Section 7.2.1 of the Guidebook lists all other one- or two-letter ASCII strings among the strings that are not permitted to be applied for. ICANN’s current public FAQ states the same rule. Section 7.2.1.1 describes an automated check in the application system: when a chosen string appears on the relevant blocked list, the system prevents the applicant from proceeding with it and requires another selection.

That is an identity-and-eligibility control. The essential record is compact: the submitted label, its normalized representation, the list category that matched, the version of the list and the time of the check. No visual judgment is required to explain why an exact non-permitted ASCII label was refused.

The second gate is different. A non-ASCII label can be compared with two-character ASCII strings even when it is not identical to one. A variant of the applicant’s primary label can also create the decisive relationship. The question is no longer only “Is this label on the list?” It is whether the primary string or one of its variants is found visually similar under the String Similarity Evaluation.

The comparison set extends beyond the label the applicant typed

The Guidebook’s scope is deliberately wider than a primary-label comparison. For each application, ICANN considers the primary string, allocatable variants and relevant blocked variants. For the edge examined here, the frozen source packet establishes that the comparison universe includes all two-character ASCII strings and their variants.

For this article, the important edge is the last one. A two-character applicant can be stopped not only by the appearance of its primary string, but also by an appearance produced through a variant relationship. The Guidebook further says that all strings in a variant-string-set share the same String Similarity Evaluation outcome. One decisive edge can therefore propagate beyond the particular pair that triggered it.

That makes a flat result such as “similar to a two-character ASCII string” inadequate as an editorial audit record. It does not tell the applicant whether the panel compared primary to primary, primary to variant, variant to primary or variant to variant. It does not identify whether letter case, a code-point sequence, script or a formal variant relationship drove the result. And it does not show which members of the applicant’s variant set inherit the consequence.

As a governance recommendation rather than a statement of current ICANN publication practice, a reconstructable result would identify the compared primary or variant labels, code points, script, case presentation, variant relation and the specific pair that carried the outcome. This packet does not establish which of those fields ICANN will publish in an application-level result.

The July 2026 data make the mechanism more concrete

ICANN’s String Similarity Evaluation Data, published on 23 July 2026, describe the material used for prescreening. Script experts compared elements within and across scripts and against ASCII characters in upper- and lower-case forms. RZ-LGR variant definitions are incorporated into the data so that potential relationships can be found across the full label set.

The document also shows why a two-character rule cannot be reduced to a simple list lookup. Its ASCII discussion identifies particular code-point or sequence relationships, including i and l, m and rn, n and ri, and vv and w, at different similarity levels. Some relationships arise directly from expert classification; others are carried through variant integration or transitivity. Uppercase presentation can expose a resemblance that is weak or absent in lowercase.

These are official methodology examples, not evidence that any named 2026 applicant used one of the strings or was rejected because of it. No application-level result is established by this source packet. The examples prove only that the comparison machinery is richer than character-counting and that the decisive presentation needs to be recorded.

Prescreening proposes; the panel decides

The July 2026 SSE Guidelines give the tool a bounded role. It produces potential similarity sets for the panel to review. The panel may adjust, add or remove those sets and must provide relevant rationale. A string absent from the tool report is not automatically cleared; the Guidelines require manual review of that string and its variants.

The Guidebook requires the panel to compile comparison lists, consider allocatable and blocked variants, document any permitted omission of a blocked-variant comparison, perform the comparison and document its analysis. Those are the frozen procedural facts; this packet does not add a claim about the panel’s membership or prescribe an application-level display-context test.

The verified division of labour is narrower: the tool supplies prescreening input, while the panel may adjust the sets with reasons and must still review strings absent from the report. As an editorial risk analysis, that structure makes it important to distinguish tool output from the panel’s documented analysis; it does not prove that either stage has failed in practice.

A public outcome should therefore say whether the pair appeared in prescreening, what the tool reported, what the panel decided and why the two differ if they do. A score without the underlying pair is not enough. A panel conclusion without the relevant guideline is not enough either.

The two-character category has two distinct consequences

The consequences in Table 7-5 are relation-specific. When an applied-for string is the same as or a variant of a two-character ASCII string, the application is not accepted. When it is visually similar but not a variant, the application cannot proceed.

The distinction matters because identity or formal variant status is not the same finding as visual similarity, even though both stop the application under this category. ICANN’s glossary frames the category as potential future ccTLD space. The frozen packet does not use that framing to infer any additional process.

That official description should not be inflated into a claim that ICANN, the ISO 3166 Maintenance Agency or a government owns a two-letter code as property. The Guidebook establishes a program rule for the gTLD application process. It does not settle every legal theory about labels, sovereignty or ownership.

The challenge clock is short and the record must be ready first

An applicant may challenge a String Similarity Evaluation within 21 days of receiving the determination on factual, procedural or system-error grounds. If error is confirmed, the evaluation is performed again with the challenge findings taken into account. If no error is confirmed, the original outcome remains in place.

Twenty-one days is workable only if the decision arrives with the material needed to test it. An applicant should not have to spend the challenge period discovering which variant was compared, which case form was rendered, whether a blocked variant was omitted, or whether the panel departed from the prescreening report.

The minimum result record should contain:

  1. the control that fired — direct non-permitted-string identification or String Similarity Evaluation;
  2. the normalized primary and variant labels on both sides of the decisive comparison;
  3. A-label, U-label, code points, scripts, case forms and representative rendering context;
  4. the similarity category and the guideline applied;
  5. the prescreening output and any panel addition, removal or override;
  6. any omitted blocked-variant comparison and the low-confusability rationale;
  7. the outcome inherited by the complete variant-string-set; and
  8. the transmission time, challenge deadline and stable result identifier.

This list is an editorial governance prescription, not an ICANN finding and not evidence of a defect in any result. It follows the Heng Lu doctrine that consequential coordination should leave a reconstructable control record. The doctrine helps ask what should be visible; it does not prove that ICANN made an error, that an applicant suffered harm, or that transparency would reverse a result.

The two-character ASCII gate protects a legible boundary in the DNS root. Its legitimacy, however, depends on keeping two propositions separate. First, exact one- or two-letter ASCII strings are not permitted at submission. Second, a different two-character label or one of its variants may be rejected after a reasoned visual-similarity evaluation. When the public record identifies which proposition decided the case, the rule can be audited without pretending that a machine made the judgment or that a country-code reservation is a rival application.

Sources