Resumen

  • RFC 3722 prescribe un proceso de mapeo Unicode, normalización NFKC y rechazo de caracteres prohibidos para que las implementaciones iSCSI comparen los bytes UTF-8 ya preparados.
  • La regla resuelve la tensión entre transcripción humana y dispositivos sencillos; no elimina la suplantación visual: los caracteres parecidos siguen siendo distintos y el perfil se limita a Unicode 3.2.

En una consola de almacenamiento, dos nombres pueden parecer intercambiables y, sin embargo, representar cadenas distintas para el destino. La diferencia importa cuando una persona copia un nombre de una etiqueta o un procedimiento y un iniciador compacto debe decidir si los bytes recibidos coinciden con el destino configurado. Publicado en abril de 2004, RFC 3722 aborda esa frontera concreta para los nombres de Internet Small Computer Systems Interface (iSCSI).

El problema enfrentaba dos necesidades. A quien transcribe un nombre internacionalizado le ayuda que el tratamiento de variantes y mayúsculas sea previsible. Un dispositivo pequeño o integrado, en cambio, necesita una regla exacta: preparar la cadena, codificarla en UTF-8 y comparar sus octetos. Si cada implementación decide por su cuenta qué cadenas son equivalentes, una misma forma aparente puede producir valores distintos. Si se pide a los dispositivos una comparación flexible y sensible al idioma, el protocolo se vuelve más difícil y menos determinista.

RFC 3722 eligió un perfil definido, no una limpieza abierta. Fijó el repertorio Unicode 3.2; aplica los mapeos Stringprep de las tablas B.1 y B.2, normaliza mediante NFKC, comprueba las salidas prohibidas de C.1.1 a C.9 y realiza verificaciones bidireccionales. La secuencia evita que una implementación invente equivalencias después de recibir el nombre.

Algunas diferencias se eliminan y otras se conservan. Las letras ASCII mayúsculas introducidas por una interfaz DEBEN convertirse a minúsculas. El conjunto ASCII permitido incluye letras minúsculas, cifras, guion, punto y dos puntos; no admite espacios en blanco. El punto ideográfico U+3002 está prohibido aunque ciertos sistemas de entrada de dominios lo equiparen al punto ASCII U+002E. Por tanto, el perfil no hereda automáticamente las sustituciones de otra aplicación.

Esto no significa que «Unicode quede saneado». El resultado es una representación preparada con un repertorio y unas tablas expresamente fijados. UTF-8 tiene su propia especificación; la gramática completa de los nombres iSCSI y las reglas de autoridad de nombres también se validan aparte. RFC 3721 proporciona el contexto de nombres y descubrimiento; RFC 3722 define el procesamiento de cadenas. Preparar un nombre no demuestra que esté autorizado, que una organización aún lo controle ni que el destino esté disponible en una dirección concreta.

La limitación más fácil de olvidar es que RFC 3722 no unifica caracteres visualmente similares. Una letra latina y su homóloga griega o cirílica, o dos glifos que una fuente dibuja de forma parecida, no se vuelven iguales porque una persona los confunda. La sección de seguridad advierte que interpretaciones divergentes pueden llevar al iniciador a un destino distinto del previsto o impedirle llegar al legítimo. Es un análisis de riesgo posible, no el registro de un ataque demostrado.

El perfil puede hacer converger variantes especificadas, rechazar caracteres prohibidos y aplicar controles al texto bidireccional. No determina quién controla la autoridad de nombres, si una etiqueta visible es confiable o si una cadena engañosa debe convencer a una persona. Para eso hacen falta controles externos al procesamiento de cadenas.

Nameprep, definido en RFC 3491, es un perfil Stringprep relacionado para nombres de dominio internacionalizados, no el perfil iSCSI. RFC 3454 aporta el marco; RFC 3722 selecciona reglas para su propio propósito. La consolidación posterior del protocolo en RFC 7143 no convierte la base Unicode 3.2 en una recomendación actual para cualquier sistema de identificadores.

El intercambio histórico fue reproducibilidad a cambio de libertad interpretativa. Los implementadores obtuvieron una receta exacta y los operadores una explicación de por qué dos entradas coinciden o una se rechaza. Pero una comparación reproducible solo vale para la cadena que recibe y no resuelve el engaño visual. La lección duradera no es que Unicode se volviera seguro para los nombres de almacenamiento, sino que un protocolo debe declarar qué diferencias borra, cuáles rechaza y cuáles deja a las personas y a los controles del entorno.

Fuentes