Resumo

  • A RFC 3743 tratou certas variantes de caracteres chineses, japoneses e coreanos como um pacote administrativo vinculado a um único titular.
  • Variantes preferidas normalmente eram ativadas na zona; outras ficavam reservadas, mas sem necessariamente se tornarem nomes ativos no DNS. O documento não prova adoção por um registro específico nem resolução de um nome.

Um rótulo visível, um objeto de registro maior

Registrar um domínio costuma parecer uma transação sobre uma única cadeia: se está disponível, alguém a registra e o operador pode publicá-la. Os nomes internacionalizados tornam essa leitura incompleta. Em chinês, japonês e coreano, pontos de código diferentes podem parecer iguais, ter interpretações próximas ou ser tratados como variantes conforme a língua e a região. O DNS compara rótulos codificados, mas não decide sozinho quando duas formas Unicode devem pertencer ao mesmo titular.

Essa lacuna administrativa é o assunto da RFC 3743, um documento Informational publicado em abril de 2004 pela Joint Engineering Team (JET). Entre seus participantes estavam comunidades de informação de rede da China, Taiwan, Coreia e Japão. A nota do IESG elogiou a ligação entre política e mecanismo de aplicação, mas deixou claro que a IETF não determina a política de cada zona. O mesmo formato de tabela pode sustentar escolhas locais diferentes.

Isso não é a conversão de uma etiqueta Unicode para a forma ASCII compatível usada no DNS. Os documentos IDNA anteriores padronizaram preparação e codificação. A RFC 3743 trata da administração das formas que uma zona pode considerar relacionadas: certas variantes não deveriam acabar sob titulares distintos. Um perfil técnico consegue validar uma cadeia; não consegue decidir por todas as comunidades linguísticas quais formas são equivalentes.

Uma tabela transforma política linguística em procedimento

Para cada língua aceita pela zona, uma Language Variant Table (LVT) lista pontos de código válidos, variantes preferidas e variantes de caracteres. Esses nomes descrevem tratamentos administrativos, não uma hierarquia universal de escritas nem a promessa de que toda combinação gerada será uma palavra comum.

No registro, a etiqueta solicitada primeiro passa por Nameprep, conforme o IDNA da época. A organização então valida os caracteres em cada tabela correspondente às línguas associadas ao pedido. Em seguida, gera combinações de variantes, elimina duplicatas e compara os rótulos candidatos com registros e reservas existentes. A zona ainda pode filtrar formas segundo suas próprias regras. O Unicode não escolhe esses resultados: eles dependem da tabela e do procedimento local.

A diferença essencial é entre ativação e reserva. O rótulo original e, em geral, as variantes preferidas elegíveis são ativados e entram no arquivo da zona. Variantes de caracteres normalmente ficam reservadas: outro solicitante não pode registrá-las, mas elas não são necessariamente publicadas como rótulos ativos. A RFC 3743 chama o conjunto do rótulo inicial, línguas associadas, variantes ativadas e variantes reservadas de IDL Package.

O pacote muda a unidade administrativa. No modelo tradicional, cada rótulo pode ser registrado, transferido ou excluído individualmente. Aqui o pacote é atômico: a transferência ou exclusão do IDL afeta o conjunto de variantes associado. Isso evita que titulares diferentes obtenham formas que a zona decidiu agrupar, mas significa que a transação pode incluir cadeias que nunca aparecem no DNS ativo.

Os exemplos do RFC mostram por que a língua associada importa. Um rótulo pode passar por diversas tabelas e produzir variantes preferidas diferentes; também pode ser inválido se um ponto de código não for permitido em uma das línguas escolhidas. São exemplos do algoritmo, não prova de que um registro identificado adotou a tabela ou de que um domínio comercial foi realmente registrado sob esse modelo.

O pacote não comprova mais do que promete

A RFC 3743 deixa decisões importantes para cada zona: tabelas, línguas, política de conflitos, quantidade aceitável de variantes e divisão de responsabilidades entre registrador e registro. Alguns exemplos usam a ordem de chegada como prioridade, mas o texto permite substituí-la por regras locais de direitos ou disputa. O RFC não prova titularidade legal, ativação do pacote, inserção de um rótulo ASCII na zona ou sucesso de uma consulta DNS.

Os documentos posteriores do IDNA2008 ajudam a separar as camadas: especificam validade e procedimentos de registro e consulta, reconhecendo que registros podem impor restrições adicionais. Essa continuidade não transforma os algoritmos da época IDNA2003 da RFC 3743 em regras atuais do protocolo, nem torna a tabela linguística da JET universal. Validação, política do registro, registro efetivo, publicação na zona e resolução são evidências diferentes.

A contribuição histórica da JET foi uma arquitetura administrativa. Em vez de codificar toda equivalência CJK no protocolo DNS, ela ofereceu às zonas uma forma de expressar escolhas locais e vincular variantes ao mesmo titular. Isso reduz um tipo de fragmentação entre titulares, mas cria outra dependência: as tabelas linguísticas e as regras de ciclo de vida passam a compor o objeto adquirido. O domínio visível pode ter um rótulo; o conjunto reservado é maior.

Fontes