Resumo

  • A RFC 3987 deu um lugar definido aos Identificadores Internacionalizados de Recursos (IRI), capazes de conter Unicode, ao lado de softwares construídos em torno de URI. A conversão depende do trecho do endereço: um host que seja um nome de domínio pode exigir IDNA; caracteres Unicode no caminho ou na consulta são representados com UTF-8 e codificação percentual.
  • A RFC 3987 atribui autoria a Martin J. Dürst e Michel Suignard; o currículo universitário de Dürst o descreve como autor principal da especificação IRI. O padrão liga escritas familiares aos leitores a softwares mais antigos, mas não registra um nome, prova o controle de um domínio nem demonstra que duas sequências visualmente parecidas apontam para o mesmo recurso.

Por que criar um identificador ao lado do URI

Imagine um endereço web com caracteres japoneses no caminho e um host escrito em outro sistema de escrita. Para a pessoa, há um endereço só. O cliente, porém, precisa separar esquema, autoridade, caminho, consulta e talvez um fragmento. Depois disso, cada componente encontra regras próprias. A forma legível e aquela recebida por um componente que só aceita URI podem corresponder uma à outra sem coincidir caractere a caractere.

É para esse cenário que existem os Internationalized Resource Identifiers, ou IRI. A RFC 3986 define a sintaxe genérica dos Uniform Resource Identifiers (URI), cujo repertório é limitado a uma parte do US-ASCII. Publicada em janeiro de 2005, a RFC 3987 adicionou um elemento complementar capaz de usar Unicode em vez de alterar silenciosamente a definição anterior. Seus autores explicam que a nova peça de protocolo preservava uma distinção clara e evitava incompatibilidades com o software instalado. Um componente que aceita IRI pode mantê-lo; se a cadeia de recuperação só aceita URI, é preciso convertê-lo para a forma URI correspondente.

Isso não significava que todo componente de rede antigo passaria a entender qualquer escrita. Era um projeto de interoperabilidade: preservar uma sequência mais ampla onde o software dá conta dela e especificar a passagem para uma interface mais estreita quando necessário. Isso importa porque um identificador pode ser armazenado, exibido, copiado ou usado para recuperar um recurso. Essas operações não precisam acontecer no mesmo componente nem no mesmo momento.

O host segue um caminho próprio

A separação decisiva aparece depois de //, na parte de autoridade de um endereço web. Se o host for um nome de domínio no estilo DNS, o mapeamento descrito pela RFC 3987 em 2005 aplica a operação ToASCII de IDNA a cada rótulo separado por ponto. O resultado é uma forma compatível com ASCII que softwares da era URI conseguem processar. O exemplo da RFC transforma o host résumé.example.org em xn--rsum-bpad.example.org.

O exemplo mostra tanto o alcance do Punycode quanto o seu limite. Ele codifica um rótulo de domínio para uma forma compatível com ASCII; não converte a URL inteira nem deve ser aplicado a todo trecho não ASCII. O prefixo xn-- também não funciona como selo de validade: a RFC 5890 distingue um A-label válido segundo IDNA de uma sequência que apenas se parece com ele. A validade exige verificação do protocolo, não basta a aparência.

Há ainda uma fronteira entre gerações de normas. Para o host, a RFC 3987 cita a RFC 3490, o protocolo IDNA de 2003. O conjunto posterior IDNA2008, incluindo as RFCs 5890 e 5891, revisou os termos e as regras do protocolo. A RFC 5895, de caráter informativo, descreve mapeamentos que uma aplicação pode aplicar à entrada antes do processamento IDNA2008. Ela reconhece que uma conversão adequada pode variar conforme idioma, aplicativo e método de entrada. Por isso, o exemplo da RFC 3987 deve ser entendido no contexto de 2005 — não como garantia de que todo navegador atual usa uma transformação universal.

Caminho não é rótulo de domínio

Quando os mesmos caracteres aparecem no caminho, o tratamento muda. Um segmento como /研究 pode ser representado na URI como /%E7%A0%94%E7%A9%B6, com os octetos UTF-8 codificados em porcentagem. Punycode não é o mecanismo do caminho. Ele pode ser interpretado por um servidor web, framework de aplicação, sistema de arquivos ou roteador específico; o DNS não resolve cada segmento.

Consulta e fragmento também têm semânticas próprias. Porcentagem, barra, interrogação e cerquilha podem ser delimitadores estruturais em vez de dados comuns, então a ordem de análise e escape importa. A RFC 3987 mantém a sintaxe dos componentes URI e amplia os caracteres que podem aparecer diretamente em um IRI. A regra não é “trocar cada caractere Unicode por uma grafia ASCII”. O esquema e o componente determinam a operação adequada.

Por isso, a norma recomenda deixar a conversão para o mais tarde possível: o momento em que o identificador chega a um componente incapaz de lidar com IRI. Converter cedo demais pode eliminar uma forma legível antes que outro aplicativo compatível a receba. Se o servidor normalizar ou decodificar em uma ordem diferente, dois sistemas podem discordar sobre qual caminho foi solicitado. O projeto de Dürst e Suignard trata dessa emenda entre sistemas, não apenas da exibição de caracteres não latinos na barra de endereços.

Uma codificação válida não registra um nome

IDNA responde a uma pergunta restrita: um rótulo pode ser representado e validado pelas regras aplicáveis? A RFC 5891 separa os processos de registro e consulta DNS. O tratamento feito por registradores antes de o pedido chegar ao administrador da zona fica fora da definição do protocolo IDNA; o registro ou administrador da zona valida a sequência específica enviada para registro. Um A-label sintaticamente válido não prova que o nome foi registrado, delegado no DNS ou colocado sob o controle do serviço que o leitor espera.

Essa separação se perde facilmente quando alguém cola em um documento um nome Unicode familiar. Há registros distintos: os caracteres digitados pela pessoa, o mapeamento aplicado pela interface, o rótulo de host apresentado ao DNS e a resposta de um serviço web. Os dados de registro e a prova de controle do serviço são evidências adicionais, não outras grafias da mesma sequência. Uma conversão bem-sucedida não comprova nenhum desses pontos.

Também há uma questão de segurança. A RFC 3987 alerta para falsificação visual tanto no host quanto no caminho: caracteres parecidos, expectativas diferentes de normalização ou comportamentos divergentes entre cliente e servidor podem fazer endereços visualmente semelhantes selecionarem recursos distintos. A norma não diz que Unicode é inseguro. Ela exige que o sistema saiba em qual componente e transformação está confiando. A sequência mostrada informa sobre a apresentação; não certifica uma identidade.

Um trabalho colaborativo sobre uma fronteira prática

A autoria da RFC é de M. Dürst e M. Suignard. O currículo oficial de Dürst na Universidade Aoyama Gakuin o chama de autor principal da especificação IRI e registra seu trabalho anterior em internacionalização da Web, uso de Unicode e normalização de caracteres compostos. Também o situa na liderança da atividade de internacionalização do W3C durante boa parte do período em que a RFC 3987 tomou forma. A universidade o identifica como professor do College of Science and Engineering.

Esse histórico sustenta uma contribuição relevante, não autoria exclusiva. O peso do trabalho está na decisão de arquitetura: em vez de deixar softwares de URI adivinharem o sentido de novos caracteres, o IRI dá a sistemas compatíveis uma representação própria em nível de caracteres e define quando a conversão é necessária. A contribuição de Dürst integra um esforço maior de padronização, e a RFC reconhece Suignard como coautor.

A ligação com o “direito a registros exatos” de Heng Lu é deliberadamente estreita. A Nota 72 trata de Registros Regionais da Internet e recursos de numeração IP; não é política de DNS nem governa domínios. A pergunta útil aqui é apenas se um registro descreve com precisão o estado que diz representar. Uma grafia Unicode, um A-label, uma delegação DNS e a chave de recurso de um serviço web são registros ligados, mas pertencem a camadas distintas. Nenhum substitui os demais.

Fontes