Resumo

  • Um número de prioridade mais distante não tira uma string solicitada do universo de comparação. Na rodada de 2026, a análise de similaridade precisa abranger todas as strings antes da criação de eventuais lotes de avaliação.
  • Imagine duas candidaturas para domínios de topo com strings visualmente parecidas. Uma recebe um número de prioridade baixo e entra cedo na fila; a outra fica muito mais atrás. Se o primeiro grupo fosse analisado isoladamente, a relação entre elas poderia surgir somente depois que o lote inicial já estivesse definido.

Imagine duas candidaturas para domínios de topo com strings visualmente parecidas. Uma recebe um número de prioridade baixo e entra cedo na fila; a outra fica muito mais atrás. Se o primeiro grupo fosse analisado isoladamente, a relação entre elas poderia surgir somente depois que o lote inicial já estivesse definido.

O Applicant Guidebook da rodada de 2026 elimina essa falha de sequência. A seção 7.10.2.2 estabelece que, se for necessário dividir o trabalho em lotes, a String Similarity Evaluation deve ser concluída para todas as strings solicitadas antes da definição dos lotes de prioridade de avaliação. Se candidaturas fizerem parte do mesmo conjunto de contenção, todas as strings desse conjunto entram no mesmo lote, seguindo a string de maior prioridade dentro do grupo.

À primeira vista, é uma regra de cronograma. Na prática, ela desempenha uma função de governança: a prioridade organiza o processamento, mas não limita o campo que o painel precisa enxergar.

Um universo de comparação antes da fila

A versão inglesa V2-2026.04.24 é a versão atualmente autorizada do Guidebook. O Módulo 1 situa a avaliação de similaridade dentro da String Evaluation, voltada às strings solicitadas e às suas variantes alocáveis. O texto também separa claramente os ritmos: os cinco componentes da String Evaluation são avaliados de forma simultânea e, ao contrário da avaliação da candidatura e do candidato, não seguem a ordem de prioridade.

O Módulo 7 delimita as comparações. Para cada candidatura, a string principal e as variantes relevantes são confrontadas com diversas categorias. Entre elas estão gTLDs já delegados, strings de rodadas anteriores ainda em processamento, determinados ccTLDs e pedidos de ccTLD IDN, outras strings solicitadas na rodada atual, um subconjunto de Blocked Names e as demais strings ASCII de dois caracteres. Variantes alocáveis e bloqueadas entram na análise conforme as regras específicas do Guidebook.

A exigência de avaliar todas as strings antes de formar os lotes é decisiva porque uma dessas categorias é relacional: as outras candidaturas da mesma rodada. O resultado de uma string pode depender de outra com um número de prioridade muito diferente. Concluir a comparação primeiro impede que a fila operacional fragmente o conjunto que precisa ser observado.

Chamar esse conjunto de “universo de comparação completo” é uma interpretação editorial sobre o desenho da regra, não uma justificativa apresentada pela ICANN com essas palavras. O objetivo expresso pela organização é evitar confusão entre usuários e perda de confiança no DNS que poderiam resultar da delegação de strings visualmente similares.