Resumo
- A RFC 3490 manteve o DNS em ASCII e instalou a IDNA no aplicativo.
ToASCIIpodia rejeitar um rótulo;ToUnicodenunca retornava erro e devolvia a entrada original quando qualquer etapa falhava. - Portanto, uma cadeia exibida não comprovava validade, aceitação pelo registro, inserção na zona, resolução, autenticação DNSSEC ou controle do nome. Cada fato exigia evidência própria.
Uma função que nunca falha parece oferecer certeza. Na RFC 3490, o significado era outro: ToUnicode sempre fornecia uma sequência para o aplicativo mostrar. Quando a preparação, a decodificação ou a verificação de ida e volta falhava, a função retornava imediatamente a entrada original. Havia continuidade visual, não aprovação protocolar.
Essa escolha atendia à arquitetura de 2003. A IDNA não alterava servidores DNS, resolvedores ou elementos do protocolo. Funcionava como uma camada dentro do aplicativo. Do lado humano, recebia e apresentava Unicode. Do lado da infraestrutura antiga, entregava rótulos ASCII. Internacionalizar a borda evitava exigir uma atualização simultânea do sistema mundial de nomes.
O documento delimitou o uso com a expressão “espaço de nome de domínio”: QNAME, argumento de uma biblioteca de resolução, domínio depois de @ num cabeçalho ou host de um URI. Texto comum que apenas mencionasse um domínio não era automaticamente esse espaço. O contexto técnico atribuía regras à cadeia; a aparência, sozinha, não fazia isso.
No sentido do DNS, ToASCII tinha o dever de falhar. Processava um rótulo por vez. Para entrada não ASCII, aplicava Nameprep; opcionalmente exigia letras, dígitos e hífen; rejeitava uma sequência não ASCII que já começasse com o prefixo reservado; codificava com Punycode, acrescentava xn-- e verificava o limite de um a 63 pontos de código. A falha de qualquer etapa invalidava a operação. Um único rótulo recusado impedia o uso do nome inteiro como IDN.
No sentido do leitor, ToUnicode fazia outra coisa. Reconhecia e retirava o prefixo ACE, decodificava Punycode, guardava o resultado e aplicava ToASCII outra vez. A forma ASCII reconstruída precisava coincidir, sem diferença de caixa, com a entrada guardada. Só então a forma Unicode decodificada podia ser devolvida. A volta completa era a prova de equivalência entre representações.
Quando a volta não fechava, o intermediário não virava um nome válido por conveniência. A função devolvia o original. A RFC 3490 dizia que, se o rótulo ainda começasse pelo prefixo ACE depois de ToUnicode, ele não era um ACE válido nem equivalia às cadeias Unicode intermediárias. “Foi devolvido” pertencia ao contrato da tela; “foi aceito” pertencia a outro contrato.
Essa distinção produz uma escada de recibos. Ser exibível não significa passar por ToASCII. Passar por ToASCII não obriga um registro a aceitar o rótulo. A aceitação não prova inserção na zona. Uma resposta DNS pode resultar de wildcard. DNSSEC autentica os dados do nome ASCII assinado, não a forma Unicode nem a interpretação humana dessa forma. Resolução também não demonstra quem controla ou deveria controlar o nome.
A RFC foi cautelosa quanto à língua. O DNS continuava baseado em correspondência exata. Grafias visualmente parecidas, variantes linguísticas, caracteres tradicionais e simplificados ou sons semelhantes não se tornavam iguais. Administradores de zona podiam impor regras mais restritas. A codificação fornecia interoperabilidade; não criava uma teoria universal de nomes ou direitos.
A revisão da RFC 4690 registrou dificuldades de confusão visual, políticas locais, versões Unicode e transição. Depois, RFC 5890 e RFC 5891 adotaram A-label e U-label e separaram explicitamente os protocolos de registro e consulta. O registro podia exigir correspondência exata das duas formas e recusar divergência. A consulta era mais permissiva, mas continuava validando. Comparação bem-sucedida, advertiu a RFC 5891, não implicava validade.
A RFC 5895 colocou o mapeamento da interface antes do protocolo comum, como decisão local. A estrutura corresponde à especificação inicial mínima de Heng Lu: definir globalmente apenas o necessário para interoperar e manter decisões de idioma, apresentação e política junto de quem possui contexto. Coordenação não exige que a camada técnica absorva todas as escolhas sociais.
O mecanismo completo da RFC 3490 foi substituído, mas a lição permanece. Uma função total é adequada para não apagar a informação que precisa ser mostrada. Ela é inadequada como oráculo de validade. ToUnicode produzia uma apresentação; ToASCII podia produzir uma representação admissível. Registro, zona, resolução, autenticação e identidade continuavam sendo acontecimentos separados.
Fontes
- RFC 3490
- Texto da RFC 3490
- Registro no RFC Editor
- Registro no IETF Datatracker
- Histórico no IETF
- Erratas da RFC 3490
- RFC 3491
- RFC 3492
- RFC 3454
- RFC 1034
- RFC 1035
- RFC 4690
- RFC 5890
- RFC 5891
- RFC 5892
- RFC 5893
- RFC 5894
- RFC 5895
- Repositório IANA de práticas IDN
- Heng Lu sobre especificação inicial mínima
- Heng Lu sobre camadas da realidade
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
