Resumo

  • A ICANN publicou em 9 de setembro de 2026 as diretrizes finais do grupo de especialistas em aceitação universal. Elas orientam trabalhos futuros e não anunciam um painel em operação nem uma obrigação regulatória.
  • O texto reúne indicadores medidos diretamente pela ICANN, informações obtidas com parceiros, autodeclarações e avaliações de jornadas reais de ponta a ponta.
  • Essas classes de evidência precisam continuar separadas. Autodeclaração útil não se transforma em resultado reproduzido por ter sido agregada a um painel.

Considere duas respostas sobre suporte a um endereço de e-mail internacionalizado. A primeira vem da equipe responsável pelo serviço e informa que o recurso foi implantado. A segunda vem de um teste que conseguiu criar a conta, mas falhou ao recuperar a senha. Não é necessário escolher qual delas é “verdadeira” em abstrato. É necessário preservar o predicado de cada uma.

As Guidelines for Advancing Universal Acceptance Adoption, agora publicadas em versão final, colocam essa tarefa no caminho de implementação da ICANN. O documento organiza indicadores em quatro frentes: conscientização, apoio de políticas, implementação e desenvolvimento de capacidade. Também sugere que a ICANN meça o que está sob sua alçada direta, coordene dados de vários atores e mantenha um painel consolidado.

Consolidar não deveria significar homogeneizar.

Os quatro eixos não formam uma nota única

Um evento de conscientização mostra alcance de comunicação. Uma regra de compras públicas mostra uma exigência institucional. Um número de profissionais treinados registra capacidade potencial. O sucesso de cadastro, autenticação, entrega de mensagem e recuperação de conta registra comportamento de uma configuração específica.

Cada linha pode informar a próxima, mas não pode substituí-la. A existência de material técnico não prova que foi usado. Uma cláusula contratual não prova que o fornecedor passou por testes. A presença de um servidor MX não demonstra que a aplicação completa aceita, valida, armazena e reutiliza o endereço de um usuário.

As diretrizes finais reconhecem a necessidade de clareza. Pedem indicadores que revelem o objeto medido, a relação com o apoio à UA e quem mede e relata. Na parte de implementação, incluem registros em idiomas locais, sinais de infraestrutura de correio, dados fornecidos por plataformas e o sucesso de ponta a ponta de uma pessoa usando identificadores multilíngues.

O risco aparece quando uma visualização soma esses objetos. Contagem de eventos, política publicada, ferramenta disponível e taxa de sucesso podem produzir uma curva única, embora tenham populações, períodos e responsáveis diferentes.

Autodeclaração alcança ambientes fechados

A ICANN não consegue inspecionar diretamente cada portal público, sistema de registro, software livre, serviço de e-mail e aplicação comercial. Muitos passos exigem login; versões internas e planos de correção não são visíveis. A organização responsável pode fornecer informações que um rastreador nunca obteria.

Por isso, a diretriz 47 recomenda colaboração com organizações intergovernamentais para obter relatos de Estados-membros, modelos de autoavaliação e incentivos à participação. O objetivo é aumentar a disponibilidade de dados comparáveis.

A utilidade não apaga a origem. Duas equipes podem chamar escopos diferentes de “UA-ready”. Uma pode cobrir apenas entrada e exibição; outra inclui login, recuperação e correio transacional. Um resultado válido hoje pode ficar obsoleto após a troca de biblioteca. Incentivar respostas também pode favorecer formulações otimistas, mesmo sem intenção de enganar.

O relatório oficial da consulta pública registra esse ponto. Participantes propuseram validação independente ao lado da autoavaliação voluntária e alertaram que incentivos podem gerar dados excessivamente otimistas. Também solicitaram metodologia pública, referência inicial e calendário regular. O PDF final examinado não torna esses itens requisitos explícitos. Essa constatação se limita ao texto; não autoriza afirmar que a ICANN os rejeitou ou que o plano futuro não os adotará.

O teste externo não é um oráculo

Um avaliador independente pode usar poucos exemplos, não alcançar funções autenticadas, omitir escritas complexas ou observar uma falha temporária. Pode ainda testar uma versão diferente daquela usada pelo público. A medição direta precisa de metadados tanto quanto o autorrelato.

A própria ICANN já hospeda práticas concretas. O roteiro para sistemas de registro e registradores mapeia portas de UA em interfaces, protocolos, processamento, armazenamento, relatórios, saída DNS e comportamento de e-mail. Ele combina testes unitários e de sistema, textos normalizados e não normalizados, diversas escritas, campos de protocolo e o envio EAI com tratamento de falhas.

O catálogo de avaliações aponta estudos de plataformas e ferramentas reutilizáveis. Esse acervo não é uma metodologia obrigatória para cada governo, empresa ou comunidade listada em 2026. Ele mostra, porém, que “testado” pode vir acompanhado de sistema, função, entrada, resultado e limitação verificáveis.

A publicação antecede as escolhas operacionais

A ICANN anunciou em 9 de setembro o documento datado de 20 de agosto, depois da consulta de fevereiro a abril e da análise das contribuições. A organização afirma que usará as diretrizes para orientar atividades futuras e divulgar seus planos.

O grupo tinha função consultiva. A versão final diz que a ICANN avaliará o que é adequado e viável segundo seus recursos. Não há anúncio de painel já implantado, referência calculada, certificação geral ou adoção compulsória de todas as recomendações.

É antes da construção que a procedência custa pouco. Depois de anos reduzidos a um índice, talvez não seja possível recuperar a versão testada, as rotas ausentes e o denominador original.

Fontes