Resumo

  • O relatório de 24 de agosto de 2026 registra que U+A9B4 deve ser permitido depois de U+A9BA ou U+A9BB, e não depois de U+A9BA ou U+A9BC como consta no rascunho.
  • A condição incorreta aparece no PDF de apoio, na visualização HTML e no XML de 23 de abril; nesse último, a regra aplicada a U+A9B4 se chama follows-A9BA-A9BC.
  • A ICANN diz que discutirá a atualização com a comunidade javanesa e a incorporará na versão final. Em 1º de setembro, sua página ainda não listava um LGR javanês definitivo.
  • O LGR de referência orienta o desenho e a análise de tabelas IDN, mas não é a tabela de um operador de registro e não comprova implantação.
  • Um recibo versionado deve ligar a contribuição, a decisão comunitária, o diff exato e os hashes dos arquivos finais, preservando a adoção a jusante como estado separado.

O erro atravessou o pacote inteiro

A consulta ficou aberta de 12 de maio a 23 de junho. Ela apresentou dois novos LGRs de referência — javanês e UCAS — e seis atualizações. A ICANN contabilizou 33 comentários relevantes: 32 apoiaram o conjunto e um pediu a correção e uma explicação adicional no material javanês.

Arif Budiarto, colaborador da proposta, apontou que U+A9B4, JAVANESE VOWEL SIGN TARUNG, pode seguir U+A9BA, JAVANESE VOWEL SIGN TALING, ou U+A9BB, JAVANESE VOWEL SIGN DIRGA MURE. O texto usava U+A9BC, JAVANESE VOWEL SIGN PEPET. Segundo a contribuição, a mudança melhora precisão e clareza sem alterar a intenção ortográfica subjacente.

Não é apenas um deslize editorial no relatório. A regra 4 da página 38 do documento de apoio contém A9BA/A9BC. O HTML repete a condição. O XML associa a U+A9B4 uma regra chamada follows-A9BA-A9BC e inclui os dois valores na classe de contexto. A correção, portanto, alcança a representação que ferramentas podem interpretar.

O comentário também separa duas funções. A regra 3 disciplina, em geral, onde uma vogal dependente pode aparecer: depois de consoante, consoante medial ou vogal independente. A regra 4 acrescenta a restrição própria de U+A9B4. O grupo de trabalho anunciou mudanças no texto, nas referências internas e no documento de apoio para deixar essa precedência inequívoca.

A9BC não se torna inválido no repertório. O ponto de código continua representando JAVANESE VOWEL SIGN PEPET. O que muda é somente sua presença entre os predecessores permitidos para U+A9B4 nessa regra específica.

O relatório encerra a resposta, não o arquivo

Na síntese, a ICANN afirma que a atualização será discutida com a comunidade javanesa e depois incorporada à versão final. A etapa seguinte é publicar os LGRs finais na página Second-Level Reference LGR após examinar os comentários e fazer os ajustes necessários.

Essa disposição pública é importante: não há base para dizer que a contribuição foi ignorada. Mas ela não substitui o XML corrigido. Na verificação de 1º de setembro, a página de referência ainda identificava 25 de outubro de 2024 como versão atual e não apresentava uma linha para o javanês. Os arquivos de abril continuavam sendo o pacote ligado à consulta.

O intervalo de oito dias não demonstra atraso. Consultar a comunidade, sincronizar XML, HTML e proposta e validar a regra demanda tempo. A distinção correta é de estado: “correção registrada, versão final pendente”. Assim não se transforma um resumo em norma nem um rascunho antigo em recusa.

As diretrizes da própria ICANN exigem XML conforme a RFC 7940 e perguntam, na revisão, se o arquivo caracteriza corretamente os pontos de código e regras desejados. A prosa prova o compromisso. O arquivo versionado prova a execução.

Referência comum e decisão local

Quando publicado, o LGR servirá de referência aos operadores que desenham tabelas de nomes de domínio internacionalizados e à ICANN ao analisar tabelas submetidas por registros gTLD. É um papel operacional relevante, mas não uma ordem que reescreve sistemas.

O LGR comum, a tabela apresentada, a decisão de análise e a tabela efetivamente adotada são registros distintos. Nenhuma fonte examinada identifica um operador que tenha copiado a condição de abril, uma solicitação recusada por ela, um domínio quebrado ou um incidente de segurança. Da mesma forma, a futura publicação do XML final não provará adoção universal.

Um recibo enxuto fecha a lacuna

O primeiro bloco identificaria o objeto observado: pacote de 23 de abril, URLs e hashes dos três formatos, U+A9B4, regra afetada, expressão A9BA/A9BC e contribuição que solicita A9BA/A9BB. A relação entre as regras 3 e 4 entraria como limite interpretativo.

O segundo bloco registraria autoridade: data da contribuição, estado da conversa com a comunidade, disposição da ICANN e função responsável pela validação final. Se a implementação mudar o nome ou a estrutura da regra, o recibo explicaria a equivalência em vez de exigir uma substituição textual literal.

O terceiro bloco vincularia a publicação: versão, data, links e hashes de XML, HTML e documento de apoio. Um diff processável mostraria A9BC saindo e A9BB entrando no contexto específico de U+A9B4; exemplos de conformidade mostrariam sequências aceitas e recusadas. O rascunho permaneceria acessível, porém marcado como substituído.

Só depois viriam os vínculos de registro: versão citada na tabela submetida, resultado da análise da ICANN e estado de adoção do operador. Falta de vínculo significa “sem comprovação pública”, não “não adotado”.

A disciplina de especificação mínima de Heng Lu evita inflar o recibo. A camada comum guarda ator, artefato, regra, estado, versão, data e revisão. A decisão localizada permanece com quem responde por ela.

O limite das evidências

O caso não é uma denúncia de falha no DNS em produção. A consulta pública existe justamente para encontrar problemas antes da finalização. Também não há base para acusar a ICANN de resistir à correção, pois o relatório promete incorporá-la.

O teste institucional agora é mais simples: tornar a conclusão tão verificável quanto a descoberta, publicando uma cadeia coerente entre a decisão e os arquivos finais.

Fontes

  1. ICANN — relatório de síntese, 24 de agosto de 2026
  2. ICANN — consulta sobre LGRs adicionais
  3. ICANN — contribuição de Arif Budiarto
  4. ICANN — índice do pacote de 12 de maio
  5. ICANN — rascunho javanês em XML
  6. ICANN — rascunho javanês em HTML
  7. Generation Panel javanês — proposta de apoio
  8. ICANN — LGRs de referência de segundo nível
  9. ICANN — diretrizes para LGRs de referência
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption