Resumo

  • O relatório final sobre diacríticos latinos propõe manter conjuntos elegíveis de gTLDs sob um operador, inclusive nas transições.
  • Trocar um prestador, retirar um sufixo da raiz e liberá-lo para outra entidade são operações diferentes.
  • A proposta foi submetida ao GNSO Council. O exame previsto no workshop do Board não significa que as regras já tenham sido adotadas.

A conta não termina no lançamento

Na contratação de um novo serviço, é comum perguntar quanto custa entrar. Para um registro que venha a operar um conjunto de sufixos ASCII e com diacríticos, a pergunta complementar será decisiva: quanto trabalho haverá para trocar o prestador?

Considere uma situação hipotética. O operador quer mudar o fornecedor de DNS de um dos sufixos, mantendo os outros onde estão. A recomendação 22 do relatório final de 31 de agosto não trataria essa troca como uma escolha isolada. Os membros correspondentes, já alocados e delegados, teriam de migrar simultaneamente para o mesmo fornecedor daquela função.

O benefício oferecido é específico. Um gTLD ASCII e sua forma com diacríticos latinos podem ser visualmente confundíveis sem serem variantes nas regras da zona raiz. O grupo de trabalho propõe uma exceção para permitir que formas elegíveis coexistam como conjunto, sob o mesmo operador de registro.

Não se trata de liberar qualquer palavra acentuada. Continuariam valendo os critérios de caracteres e as regras de geração de rótulos da raiz. O conjunto precisaria de um membro ASCII e não poderia se misturar a um conjunto de TLDs variantes. A exceção é delimitada, não uma autorização geral.

O texto está no índice atual de documentos do GNSO. Seus 57 resultados obtiveram consenso pleno no grupo, mas foram encaminhados ao Council para consideração. Consenso de elaboração não é política em vigor.

Mesma função, mesmos prestadores

A ligação proposta atravessa a vida do conjunto. Haveria um único contrato de registro, com níveis de serviço e outras exigências operacionais iguais. Uma transição de registro ou mudança de controle abrangeria os membros pertinentes. Numa transferência de emergência, eles seguiriam juntos para o mesmo Emergency Back-End Registry Operator.

Isso não obrigaria o operador a comprar todas as funções de uma única empresa. O requisito é manter o prestador de cada função crítica consistente entre os sufixos. O relatório admite, inclusive, vários fornecedores DNS, desde que sejam os mesmos em todo o conjunto.

A distinção preserva espaço para diversidade técnica, mas restringe a migração parcial. Seria possível distribuir funções entre empresas; não seria possível separar livremente os membros do conjunto ao substituir o fornecedor de uma dessas funções.

Há uma razão de proteção para isso. Se nomes facilmente confundidos passarem a controles incompatíveis, a segurança da coexistência pode ser enfraquecida. Levar os membros juntos ajuda a preservar a relação que justificou a exceção.

O outro lado é a coordenação. A extensão que estiver pronta primeiro pode depender da preparação das demais para mudar. Essa é uma consequência possível do desenho, não um atraso observado ou um custo já calculado. Quem compara propostas comerciais deveria considerar o conjunto que precisará deslocar, e não apenas o preço de lançar mais uma grafia.

Dez anos para quê?

O prazo de pelo menos dez anos previsto nas recomendações 37 e 38 não proíbe trocar fornecedores. Ele se refere à reatribuição de cadeias removidas da zona raiz a uma entidade diferente do detentor remanescente indicado nas disposições.

Se o membro ASCII for removido, o conjunto deixará de existir, embora o operador possa manter um único gTLD internacionalizado. A retirada voluntária de um membro com diacríticos não exigiria a retirada dos demais. Já uma transição de emergência que preserva o conjunto intacto não é remoção e não inicia esse prazo por si só.

Para o titular de um domínio, manter o serviço em outra operação é diferente de perder o sufixo. A orientação 39 pede um plano de transição quando a extensão cuja remoção é solicitada contém registros de segundo nível. A recomendação 40 trata do caso em que um descumprimento contratual efetivamente provoca a remoção da raiz; ela não transforma qualquer descumprimento em exclusão automática.

Também seria incorreto supor que todos os arranjos antigos serão reunidos à força. Há uma exceção para gTLDs preexistentes operados separadamente por entidades diferentes, com limites para novos pedidos. Nomes de segundo nível existentes que não satisfazem a regra de mesmo titular e mesmo registrador têm sua situação contratual e de alocação protegida contra mudança retroativa. Nos conjuntos não isentos, porém, uma transferência entre registradores abrangeria os membros alocados juntos — não todos os domínios do cliente.

Ainda não é uma oferta pronta

No anúncio de 2 de setembro, a presidente do Board informa que o workshop de 4 a 6 de setembro examinará as recomendações e suas implicações antes da consideração formal pelo Board. Não há, nessa agenda, um resultado aprovado.

A explicação de implementação da ICANN distingue desenvolvimento da política, adoção e execução. O relatório não coloca suas regras no guia atual da rodada de 2026 nem determina precisamente uma rodada futura.

A Nota 64 de Lu Heng oferece uma pergunta útil: qual propriedade de segurança exige a obrigação comum, e que escolhas podem continuar com os operadores? Sua defesa de saída e portabilidade viáveis é uma lente analítica, não uma regra que substitua os contratos da ICANN.

A resposta precisa proteger a relação entre os nomes sem tornar indispensável o fornecedor que hoje os atende. Essa é a diferença entre coordenar uma mudança e tornar a mudança impraticável.

Fontes

  1. Relatório final sobre diacríticos latinos
  2. Documentos do GNSO
  3. Prévia do workshop de setembro do Board
  4. Implementação de políticas na ICANN
  5. Lu Heng: especificação mínima e adoção voluntária