Resumo

  • O RFC 3454 fixou a ordem mapear, normalizar, proibir e verificar bidi, mas cada protocolo usuário ainda precisava declarar um perfil completo.
  • Saídas iguais significavam igualdade naquele perfil e naquela versão Unicode, não mesma grafia, aparência, intenção, conta, autorização ou pessoa.

A comparação vinha antes da identidade

Unicode abriu os protocolos para muito além do ASCII, mas a mesma aparência podia vir de sequências, caixas, caracteres de compatibilidade e marcas invisíveis diferentes. Publicado em dezembro de 2002, o RFC 3454 definiu stringprep para preparar uma sequência antes do armazenamento ou da comparação.

A meta era modesta: aumentar a chance de duas pessoas que acreditavam digitar a mesma coisa obterem saída idêntica caractere a caractere. O texto reconhecia que não cobriria todas as grafias alternativas entre idiomas. O texto simples, o registro do RFC Editor, o Datatracker, o histórico, as referências, as citações e as erratas comprovam a norma, não a intenção do usuário nem o dono da conta.

O perfil carregava a política

Stringprep não era uma regra autônoma. O protocolo precisava declarar aplicação, repertório, tabelas de mapeamento, normalização, saídas proibidas, teste bidirecional e acréscimos. Dois perfis podiam tratar a mesma entrada de modos distintos.

O mapeamento podia apagar, substituir ou expandir caracteres, sem reexaminar o que acabara de produzir. Se houvesse normalização, NFKC era obrigatória, conforme o Anexo Unicode 15. Mais formas convergiam, mas isso não assegurava aparência igual em toda fonte nem significado igual em toda língua.

A ordem integrava o contrato

Mapear, normalizar, proibir e verificar bidi tinha de ocorrer nessa sequência. A etapa de proibição devolvia uma sequência ou um erro, nunca ambos. Controles, uso privado, não caracteres, substitutos e marcas de etiquetagem podiam ser excluídos. Bidi estabilizava limites de texto da direita para a esquerda; não autenticava quem digitou.

O Relatório Unicode 36 aprofundou os riscos visuais. Normalização correta não elimina todos os sósias, e igualdade de saída não prova dono comum.

A versão era parte do recibo

RFC 3454 congelou as tabelas em Unicode 3.2 e recusou aplicação automática ao futuro. O cálculo ficou reproduzível, mas “válido” sem perfil e versão virou afirmação incompleta.

Pontos não atribuídos expunham a tensão. Não eram aceitos em sequências armazenadas, pois uma atribuição futura podia mudar propriedades; consultas podiam tolerá-los para interoperar entre software novo e base antiga. A mesma entrada podia falhar na criação e passar na busca. O tipo de operação fazia parte do resultado.

Guardar só a saída elimina entrada, tabelas, transformações e a distinção entre armazenar e consultar. Depois de uma atualização, ninguém saberia se mudou o usuário ou o software.

Nameprep mostrou valor e dívida

O RFC 3491 definiu Nameprep para o IDNA original, e o RFC 3490 o incorporou. O RFC 4690 registrou problemas; o vocabulário IDNA2008 do RFC 5890 abandonou stringprep.

Comparar continuou necessário, mas o quadro preso a uma versão envelheceu. O RFC 6885 formulou PRECIS, o RFC 7564 substituiu RFC 3454 e o RFC 8264 substituiu o primeiro PRECIS. A sucessão prova revisão, não mudança súbita de todo identificador existente.

A disciplina de camadas da realidade de Heng Lu separa entrada, perfil, tabelas, etapas, saída ou erro, comparação, vínculo da conta e autorização. A primazia do código em operação permite ao programa provar o cálculo, não nomear o proprietário. A especificação inicial mínima explica por que identidade e poder ficaram no protocolo usuário. É uma leitura editorial posterior.

O RFC 3454 tornou a normalização forte dentro de um limite nomeado. Comparação determinística ainda não era identidade.

Fontes