Resumo

  • A ICANN opera dois controles distintos: sequências ASCII de uma ou duas letras não são aceitas na submissão; já uma sequência solicitada de dois caracteres, ou uma de suas variantes, pode ser impedida de avançar mais tarde se o painel a considerar visualmente semelhante a uma sequência ASCII de dois caracteres ou a uma variante dela.
  • A ferramenta SSE faz a triagem, mas o painel toma a decisão final. Um resultado auditável deve mostrar o par decisivo, a escrita e a caixa analisadas, comparações omitidas, a justificativa do painel e o prazo de 21 dias para contestação.

O caso mais difícil não é o de quem tenta inserir diretamente duas letras ASCII. Essa situação pertence à porta de entrada: o sistema deve reconhecer a categoria não permitida e impedir a continuação. A dificuldade surge quando o requerente escolhe dois caracteres de outra escrita, satisfaz as regras técnicas aplicáveis e não apresenta literalmente um código de país em ASCII.

O Applicant Guidebook de 2026 cria uma segunda porta. Na String Similarity Evaluation, a sequência principal e suas variantes são comparadas com um universo que inclui todas as sequências ASCII de dois caracteres e suas variantes. Se a sequência solicitada de dois caracteres, ou uma de suas variantes, for considerada semelhante a um item dessa categoria, a candidatura não avança.

Os dois controles não devem ser tratados como se fossem um único “bloqueio de nome”. O primeiro verifica identidade e elegibilidade. O segundo exige um juízo de semelhança visual entre rótulos diferentes. Cada um produz provas diferentes e oferece pontos de erro diferentes.

A primeira porta é uma verificação direta

A seção 7.2.1 do Guidebook inclui todas as demais sequências ASCII de uma ou duas letras entre as que não podem ser solicitadas. A FAQ atual da ICANN repete a categoria. A seção 7.2.1.1 descreve uma verificação automática: se a sequência escolhida aparece na lista aplicável, o sistema impede o requerente de seguir com ela e exige outra escolha.

Esse controle pode ser explicado com um registro curto: valor recebido, forma normalizada, categoria correspondente, versão da lista e horário da verificação. Não há necessidade de justificar uma percepção tipográfica. A pergunta é se o valor exato pertence ao conjunto proibido.

Na segunda porta, a pergunta muda. Um rótulo não ASCII pode ser diferente de qualquer sequência ASCII de dois caracteres e ainda assim ser considerado visualmente semelhante a ela, ou a uma de suas variantes, na String Similarity Evaluation. Uma variante do requerente também pode criar a relação decisiva.

O resultado deveria começar dizendo qual porta atuou. Sem essa informação, o requerente não sabe se deve examinar a normalização, a classificação na lista, a relação de variante, a renderização ou o julgamento visual do painel.

A variante pode ser mais importante que o rótulo principal

O escopo da SSE vai além da sequência que aparece em primeiro plano na candidatura. A seção 7.10.1 inclui o rótulo principal, variantes alocáveis e, dentro das condições previstas, variantes bloqueadas. Para a relação examinada aqui, o pacote de fatos congelado estabelece a comparação com todas as sequências ASCII de dois caracteres e suas variantes.

O elo que decide o caso pode ser principal-principal, principal-variante, variante-principal ou variante-variante. Além disso, a seção 7.10.3 determina que todo o variant-string-set compartilha o resultado da avaliação. Uma única proximidade considerada relevante pode, portanto, transmitir a consequência para todos os rótulos associados à candidatura.

Uma comunicação que diga apenas “semelhante a uma sequência ASCII de dois caracteres” não permite reconstruir esse caminho. O registro deveria informar:

  1. os rótulos principais ou variantes que formaram o par;
  2. seus A-labels, U-labels e pontos de código;
  3. a escrita, a caixa e a relação de variante consideradas;
  4. a categoria de semelhança e a diretriz aplicada; e
  5. quais integrantes do conjunto de variantes recebem o mesmo resultado.

Essa lista é uma recomendação editorial para uma trilha reconstruível, não uma descrição dos campos que a ICANN publicará. O pacote não estabelece o formato de um resultado individual da rodada de 2026.

Os dados de julho de 2026 mostram por que contar caracteres é insuficiente

Em 23 de julho de 2026, a ICANN publicou a versão 1.0 dos dados e das diretrizes SSE. Especialistas compararam elementos dentro de cada escrita, entre escritas relacionadas e com caracteres ASCII em caixa alta e baixa. As relações de variante do RZ-LGR foram incorporadas para permitir a identificação de conjuntos potenciais.

Na parte sobre ASCII, o documento apresenta relações como i e l, m e rn, n e ri, além de vv e w. Elas não têm a mesma intensidade. Algumas decorrem da análise direta dos especialistas; outras chegam ao conjunto pela integração de variantes ou pela transitividade. Uma semelhança também pode aparecer quando as formas são convertidas para maiúsculas, mesmo que as minúsculas sejam mais fáceis de distinguir.

Esses pares são exemplos metodológicos oficiais, não candidaturas reais da rodada de 2026. O pacote de fatos deste artigo não contém um resultado individual, uma taxa de falso positivo ou um histórico de reversões. Seria incorreto transformar exemplos do conjunto de dados em alegações de que determinado requerente já foi rejeitado.

O que os documentos demonstram é a necessidade de preservar a representação usada na avaliação. A palavra “semelhante” ou uma pontuação isolada não diz se a proximidade veio da forma direta, da caixa, de uma variante formal ou de uma relação transitiva inserida no conjunto de triagem.

A ferramenta encontra candidatos; o painel responde pela decisão

As Diretrizes SSE de julho de 2026 definem a ferramenta como apoio de pré-seleção. Ela gera conjuntos potenciais e um relatório. O painel pode adicionar, ajustar ou remover conjuntos, desde que apresente a justificativa. Se uma sequência não aparecer no relatório, ainda deve passar por revisão manual junto com suas variantes.

A divisão confirmada é mais restrita: a ferramenta fornece a pré-seleção, enquanto o painel pode alterar os conjuntos com justificativa e deve revisar manualmente as sequências ausentes do relatório. O pacote não acrescenta afirmações sobre a composição profissional do painel nem prescreve um teste de contexto de exibição para resultados individuais.

O registro público deve ligar as duas etapas. Ele precisa informar se o par apareceu na triagem, qual categoria a ferramenta indicou, o que o painel concluiu e por que houve diferença, se houver. Uma nota numérica sem o par subjacente não é uma justificativa; uma conclusão humana sem referência à diretriz usada também não é verificável.

As Diretrizes permitem que certas comparações de variantes bloqueadas sejam omitidas quando a confusabilidade entre as escritas é manifestamente baixa. Essa possibilidade reduz trabalho sem utilidade, mas a omissão continua sendo uma decisão. O resultado deveria identificar o que foi omitido, o critério aplicado e o responsável pela aprovação.

Duas relações produzem dois efeitos na mesma categoria

A Tabela 7-5 distingue os efeitos. Se a sequência solicitada for igual a uma sequência ASCII de dois caracteres, ou uma variante dela, a candidatura não será aceita. Se for visualmente semelhante, mas não uma variante, não poderá prosseguir.

A diferença deve ser registrada porque identidade ou condição formal de variante não é o mesmo achado que semelhança visual, embora ambos interrompam a candidatura nessa categoria. O glossário da ICANN descreve a categoria como espaço de possíveis futuros ccTLDs; o pacote congelado não infere daí nenhum processo adicional.

Essa formulação oficial não estabelece propriedade. As fontes não provam que a ICANN, a Agência de Manutenção da ISO 3166 ou um governo seja dono de um código de duas letras. O Guidebook estabelece uma regra do programa de novos gTLDs; ele não resolve, sozinho, teorias mais amplas sobre soberania ou direitos patrimoniais sobre identificadores.

Vinte e um dias exigem uma decisão utilizável desde o primeiro dia

O requerente pode contestar a String Similarity Evaluation em até 21 dias após receber o resultado, alegando erro factual, procedimental ou de sistema. Se o erro for confirmado, a avaliação é refeita com as conclusões da contestação. Caso contrário, o resultado original permanece.

Um prazo curto só é significativo quando a justificativa acompanha a notificação. O requerente não deveria gastar parte dos 21 dias tentando descobrir qual variante gerou a comparação, qual forma de caixa foi exibida ou se o painel acrescentou um par ausente da triagem.

O registro mínimo deveria conter:

  1. o controle acionado — proibição direta ou avaliação de semelhança;
  2. o par exato de rótulos principais ou variantes;
  3. formas normalizadas, A-labels, U-labels, pontos de código, escritas e caixas;
  4. categoria de semelhança e diretriz aplicada;
  5. saída da triagem e qualquer inclusão, exclusão ou substituição pelo painel;
  6. comparações omitidas e a justificativa de baixa confusabilidade;
  7. o efeito sobre todo o conjunto de variantes; e
  8. momento da notificação, prazo de contestação e identificador estável do resultado.

Essa lista é uma recomendação editorial de governança, não uma constatação da ICANN. Ela aplica a doutrina de Heng Lu: um controle capaz de encerrar uma candidatura deveria deixar um registro reconstruível da regra, das provas, do elo de comparação, da justificativa, do decisor e da via de revisão. A doutrina não prova que a ICANN errou, que houve um falso positivo ou que mais transparência mudaria o resultado.

O filtro de dois caracteres pode proteger uma fronteira compreensível na raiz do DNS sem se transformar em caixa-preta. Para isso, o registro precisa preservar uma distinção básica. Uma sequência ASCII curta pode ser impedida na submissão. Um rótulo diferente de dois caracteres, ou sua variante, pode ser excluído depois por um julgamento visual fundamentado. Quando a ICANN mostra qual porta atuou e qual par decidiu o caso, a regra pode ser auditada sem tratar a ferramenta como juiz.

Fontes