RFC 9839 y el Unicode problemático

• RFC 9839 define con claridad los caracteres Unicode problemáticos que pueden aparecer en campos de texto durante el desarrollo de software
• Este RFC aborda los problemas causados por la falta de consistencia al procesar esos caracteres entre distintos lenguajes y bibliotecas
• En 9839 se proponen tres subconjuntos menos problemáticos que pueden usarse de forma opcional
• En comparación con el framework PRECIS existente, su aplicación es más fácil y simple
• También se publicó una biblioteca para Go de RFC 9839 para facilitar su uso en la práctica

---

Antecedentes y panorama general de RFC 9839

• Unicode se usa como estándar en casi todo el procesamiento de datos de texto
• Sin embargo, al diseñar estructuras de datos o protocolos reales, permitir todos los caracteres Unicode puede causar problemas
• Paul Hoffman y el autor presentaron un borrador individual ante la IETF para establecer criterios claros sobre problemas de Unicode que se repetían constantemente
• Tras dos años de discusiones, fue adoptado como estándar oficial y publicado como RFC 9839
• Este documento explica en detalle los tipos de caracteres problemáticos, por qué lo son (por razones técnicas y normativas), y tres subconjuntos entre los que el usuario puede elegir

Contenido principal de RFC 9839

• Es un documento de referencia obligatoria al diseñar campos de texto en entornos de software y redes
• RFC 9839 tiene 10 páginas, por lo que es relativamente conciso para un documento estándar de la IETF
• Está explicado de forma accesible, principalmente para desarrolladores de software e ingenieros de redes

Casos de caracteres Unicode problemáticos

• Por ejemplo, en el campo username de JSON podría aparecer una cadena como la siguiente

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• Problemas de cada code point
  • U+0000 : un carácter NULL sin significado que interfiere con el funcionamiento de algunos lenguajes de programación
  • U+0089 : un código de control C1 (CHARACTER TABULATION WITH JUSTIFICATION) cuyo comportamiento es complejo e inconsistente
  • U+DEAD : un carácter sustituto no emparejado, un problema derivado de las limitaciones de UTF-16. Genera datos poco deseables
  • \uD9BF\uDFFF (U+7FFFF real) : un Noncharacter, cuyo intercambio está prohibido por la norma
• Code points como estos provocan procesamiento inconsistente y errores inesperados dentro de estructuras de datos y protocolos
• RFC 9839 define oficialmente este tipo de caracteres problemáticos y establece con claridad qué categorías deben excluirse

Diseño y limitaciones de JSON

• No es responsabilidad de Doug Crockford, creador de JSON
• Se diseñó en una época en la que Unicode no estaba lo suficientemente maduro, por lo que no fue posible restringir estrictamente el conjunto de caracteres
• Como ya no es posible cambiar el estándar, se necesita un enfoque de exclusión empírica de caracteres problemáticos

Diferencias con el framework PRECIS de la IETF

• Incluso antes de RFC 9839 en 2025, la IETF ya ofrecía varios estándares como RFC 8264 (PRECIS Framework)
  • Este framework trata en detalle cómo preparar, aplicar y comparar cadenas internacionalizadas
  • Tiene 43 páginas y ofrece una explicación de fondo y soluciones muy completas
• PRECIS depende fuertemente de la versión de Unicode, y tiene la desventaja de ser complejo y difícil de aplicar
• RFC 9839 es conciso y está centrado en la practicidad, lo que facilita una adopción rápida al definir nuevos protocolos

Subconjuntos de RFC 9839 y ejemplos de uso

• 9839 presenta tres subconjuntos prácticos (scalars, XML, assignables)
• Cada subconjunto varía ligeramente en el rango de caracteres problemáticos que excluye
• A continuación, un resumen de cómo los principales formatos de datos y los subconjuntos de RFC 9839 manejan los caracteres problemáticos
  • Algunos formatos como CBOR, TOML, XML, YAML excluyen parcialmente caracteres sustitutos o de control
  • I-JSON excluye sustitutos y noncharacters
  • JSON general y Protobufs no los excluyen
  • XML y YAML solo excluyen parcialmente noncharacters/códigos de control por las características de su charset
    • Nota: XML y YAML no excluyen noncharacters fuera del Basic Multilingual Pane

Biblioteca RFC 9839 para Go

• Se publicó una pequeña biblioteca de Go que permite validar caracteres según los tres subconjuntos de RFC 9839
• Ya fue suficientemente probada, aunque la optimización sigue en proceso
• Se agradecen pruebas y retroalimentación en entornos reales de trabajo

Importancia de RFC 9839 y proceso de elaboración

• RFC 9839 fue publicado oficialmente tras pasar por múltiples rondas de retroalimentación entre los coautores y más de 15 revisiones del borrador
• Gracias a la discusión y contribución de muchos expertos de la comunidad, evolucionó hasta convertirse en un documento mucho más sólido que la propuesta inicial
• Los colaboradores aparecen mencionados en la sección “Acknowledgements”

La experiencia de una presentación individual de RFC

• RFC 9839 se desarrolló como una presentación individual (individual submission)
• Implica más carga de trabajo y de procedimiento que el método tradicional a través de un Working Group
• Comparado con la experiencia de participar en un Working Group, el método tradicional resulta más eficiente y recomendable