Resumen

  • RFC 5198 obliga a mirar más allá de “UTF-8 válido”: Net-Unicode combina codificación, NFC, estado asignado de cada punto, CRLF y límites sobre caracteres de control.
  • Como el sistema operativo o el lenguaje pueden actualizar sus tablas sin tocar el código, reproducir una decisión exige conservar la versión Unicode/NFC y las huellas de entrada y salida.

El estado que no estaba en el inventario

Un rollback suele partir de una idea razonable: si regresan el ejecutable y la configuración, regresa el comportamiento. RFC 5198 muestra una excepción concreta. Muchas aplicaciones delegan conversión y normalización Unicode a bibliotecas del sistema operativo o del runtime. Esas funciones pueden cambiar sin que cambie una línea del programa. Incluso puede que la aplicación no sepa qué versión Unicode usa ni si coincide con la versión de las tablas NFC.

No se trata de afirmar que cada actualización altera toda cadena. La garantía de estabilidad de NFC protege las cadenas ya normalizadas que no contienen puntos sin asignar. El borde móvil está en el repertorio. Un punto que una versión considera libre se normaliza a sí mismo; una versión futura puede asignarlo y hacerlo participar en una relación de normalización. El emisor conforme no debe transmitirlo mientras sea “sin asignar” en la versión de la que depende. Una biblioteca nueva puede cambiar ese veredicto de admisión sin cambiar el paquete de la aplicación.

Por eso un rollback parcial no es una reproducción. La evidencia necesita dos coordenadas: qué programa llamó a la función y qué datos Unicode respondió la función.

Seis decisiones, no una casilla Unicode

La definición de RFC 5198 empieza con UTF-8 de RFC 3629, pero no termina ahí. Para protocolos con líneas, exige CRLF. Desaconseja CR salvo que lo siga LF y tolera por herencia CR NUL, aunque NUL es peligroso en lenguajes que lo interpretan como terminador. Prohíbe controles C1. También deja fuera IND, NEL, U+2028 y U+2029 como finales de línea alternativos. El BOM no puede encabezar la cadena.

Antes de transmitir, la secuencia debería estar en NFC. Además, ningún punto sin asignar en la versión dependiente puede salir, y las versiones de Unicode y de NFC deben ser coherentes.

Cada paso produce evidencia distinta: validación de octetos, clasificación del repertorio, normalización, reglas de línea, filtro de controles y decisión de la aplicación. Una API que devuelve un único ok no permite saber si rechazó UTF-8 mal formado, una C1, un BOM, un punto todavía vacío o una política local posterior.

El registro de erratas también obliga a no simplificar. Una errata técnica aún reportada corrige la descripción equivocada de U+0080–U+009F como parte de una “zona ASCII”; la prohibición separada de C1 sigue estando en el RFC. La errata verificada 1402 solo corrige una referencia espacial. “Errata existe” no equivale a “texto normativo sustituido” sin atender a su estado.

La normalización también tiene lugar y tiempo

RFC 5198 pide a los receptores prudencia: no deben suponer que la entrada ya está normalizada. Un atacante puede utilizar formas descompuestas para escapar de coincidencias ingenuas en un firewall. La dificultad aumenta cuando el firewall y la aplicación emplean runtimes diferentes.

Si la puerta de enlace transforma con una tabla y el servicio compara con otra, permitido no identifica la cadena sobre la que actuó cada uno. También importa el orden. Verificar una firma sobre los octetos recibidos y normalizar después no es lo mismo que normalizar primero. Convertir finales de línea puede cambiar posiciones. Tratar un BOM como firma, dato o error produce tres historias operativas.

RFC 5198 no pretende reemplazar las reglas de protocolos que ya definen con precisión su uso de UTF-8. Su aporte es ofrecer una forma común para los que no lo hicieron. El operador debe, por tanto, registrar el perfil realmente invocado y no aplicar Net-Unicode como una reescritura universal.

Qué debe sobrevivir al incidente

El recibo mínimo une la versión y huella del programa con la imagen del host o contenedor, el runtime de lenguaje, la versión de la base de caracteres y la implementación NFC. Si alguna coordenada es inaccesible, el campo correcto es “desconocido”, no la versión comercial del producto.

Después conserva una huella de los octetos de entrada, el resultado UTF-8, la secuencia de puntos y el veredicto asignado/sin asignar bajo esa base. BOM, uso privado, C0, C1, CR, LF, CR NUL, U+2028 y U+2029 merecen resultados independientes. La huella previa, la huella NFC y el indicador “ya estaba normalizada” permiten distinguir comprobación de mutación.

El último tramo nombra la operación —filtrar, comparar, firmar, almacenar—, su autoridad y el efecto observado. Ser Net-Unicode no demuestra que un identificador represente a la persona correcta ni que una autorización sea legítima. Esta pieza no vuelve a convertir normalización en identidad. Conserva algo más básico: qué contrato textual se ejecutó cuando el código aparente no cambió.

Fuentes

  1. RFC 5198 en HTML
  2. RFC 5198 en texto
  3. Ficha de RFC 5198
  4. Datatracker IETF: RFC 5198
  5. Historia de RFC 5198
  6. Referencias de RFC 5198
  7. Erratas de RFC 5198
  8. RFC 3629 — UTF-8
  9. RFC 2277 — juegos de caracteres e idiomas
  10. RFC 4690 — revisión de nombres internacionalizados
  11. RFC 3454 — Stringprep
  12. RFC 8264 — marco PRECIS
  13. RFC 6365 — terminología de internacionalización
  14. RFC 854 — Telnet
  15. RFC 698 — ASCII extendido para Telnet
  16. Anexo Unicode #15 — formas de normalización
  17. Política de estabilidad de Unicode
  18. Heng Lu — capas de realidad y poder simbólico
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código en ejecución