Resumo

  • A RFC 3722 prescreve mapeamento Unicode, normalização NFKC e verificações de caracteres proibidos para que implementações iSCSI comparem os bytes UTF-8 preparados.
  • A regra concilia a transcrição humana com dispositivos simples, mas não elimina a falsificação visual: caracteres parecidos continuam distintos, e o perfil se baseia no Unicode 3.2.

Em uma console de armazenamento, dois nomes podem parecer equivalentes e ainda assim representar cadeias diferentes para o destino. Isso importa quando alguém copia um nome de uma etiqueta ou instrução, enquanto um iniciador compacto precisa decidir se os bytes recebidos correspondem ao destino configurado. Publicada em abril de 2004, a RFC 3722 trata dessa fronteira específica nos nomes do Internet Small Computer Systems Interface (iSCSI).

O problema reunia expectativas distintas. Para quem transcreve um nome internacionalizado, é útil que caixa e variantes tenham tratamento previsível. Já um dispositivo simples ou embarcado precisa de uma regra exata: preparar a cadeia, codificá-la em UTF-8 e comparar os octetos. Se cada implementação inventar suas próprias equivalências, uma grafia aparentemente igual pode gerar valores diferentes. Se o protocolo exigir correspondência flexível e dependente de idioma, a implementação fica mais complexa e menos previsível.

A RFC 3722 escolheu um perfil fechado, não uma limpeza livre de texto. Ela fixa o repertório Unicode 3.2 e aplica os mapeamentos Stringprep das tabelas B.1 e B.2, seguidos de normalização NFKC. Depois verifica saídas proibidas nas tabelas C.1.1 a C.9 e aplica controles bidirecionais. A ordem impede que cada implementação crie, após receber a entrada, uma noção própria de equivalência.

Algumas diferenças desaparecem; outras são mantidas. Letras ASCII maiúsculas digitadas em uma interface DEVEM ser convertidas para minúsculas. O conjunto ASCII permitido inclui letras minúsculas, dígitos, hífen, ponto e dois-pontos; espaços não são aceitos. Um caso sutil é U+3002, o ponto final ideográfico: a RFC o proíbe, embora alguns sistemas de entrada de domínios o tratem como equivalente ao ponto ASCII U+002E. O perfil não herda automaticamente as substituições feitas por outros aplicativos.

Isso não significa que «todo o Unicode foi saneado». O resultado é uma representação preparada segundo um repertório e tabelas explicitamente definidos. A codificação UTF-8 tem especificação própria; a gramática completa dos nomes iSCSI e as regras de autoridade de nomes continuam sendo verificações separadas. A RFC 3721 dá contexto ao modelo de nomes e descoberta; a RFC 3722 cuida do preparo da cadeia. Passar pelo perfil não comprova autorização, controle atual do nome por uma organização nem localização de um destino.

A limitação mais fácil de esquecer é que a RFC 3722 não reúne caracteres visualmente semelhantes. Uma letra latina e uma parecida do grego ou cirílico, ou dois glifos próximos em determinada fonte, não se tornam iguais porque alguém os confundiu. A seção de segurança explica que interpretações inconsistentes podem levar o iniciador a um destino diferente do esperado ou impedir o acesso ao destino legítimo. É uma análise de risco possível, não o relato de um ataque comprovado.

O Stringprep consegue fazer variantes definidas convergirem, rejeitar saídas proibidas e aplicar verificações ao texto bidirecional. Mas não determina quem controla a autoridade de nomes, se um rótulo exibido é confiável ou se uma cadeia enganosa deve convencer uma pessoa. Essas perguntas exigem controles além do perfil.

Nameprep, da RFC 3491, é relacionado por também ser um perfil Stringprep, mas serve aos nomes de domínio internacionalizados; não é o perfil iSCSI. A RFC 3454 fornece a estrutura geral e a RFC 3722 seleciona regras para sua finalidade. A consolidação posterior do iSCSI na RFC 7143 não transforma a base Unicode 3.2 em recomendação atual para todo novo sistema de identificadores.

A escolha histórica favoreceu repetibilidade em vez de liberdade interpretativa. Implementadores ganharam uma receita precisa e operadores puderam explicar por que duas entradas coincidem ou uma é rejeitada. Ainda assim, uma comparação reproduzível depende da cadeia recebida e não resolve enganos visuais. A lição não é que Unicode tornou nomes de armazenamento seguros; é que o protocolo precisa declarar quais diferenças apaga, quais rejeita e quais deixa para as pessoas e os controles ao redor.

Fontes