Resumen

  • RFC 9896 admite dibujos SVG en los RFC definitivos, pero exige que el concepto también esté representado en texto y que la imagen no lo contradiga.
  • La aceptación del RPC demuestra admisibilidad editorial acotada; no demuestra píxeles idénticos, acceso equivalente, comprensión del lector ni una decisión posterior correcta.

Una relación técnica entra en el RFCXML definitivo como prosa y como dibujo. HTML la muestra en una pantalla ancha; PDF la ajusta a una página; un dispositivo pequeño la reduce; una vía asistida ofrece otra forma. Las salidas pueden cambiar de escala y contraste. Lo que no debe cambiar es la relación explicada.

RFC 9896, publicado en enero de 2026 en el Editorial Stream, reemplaza el perfil fijo de RFC 7996. Conserva la política, pero entrega al RFC Production Center la elección de herramientas y su evolución. Así evita que una implementación temporal se convierta en una restricción permanente.

La flexibilidad no convierte al renderizador en dueño del sentido. El dibujo puede aclarar un concepto, pero no debería ser su única representación. Los autores deben procurar que protocolos, formatos y arquitecturas queden plenamente expresados en el texto; como mínimo, la imagen debe coincidir con él. Que un control de publicación sea verde sólo prueba que la obra fue admitida bajo unas reglas. No prueba que una rama opcional no parezca obligatoria o que una condición no haya desaparecido visualmente.

RFC 9720 define RFCXML como formato definitivo y al XML publicado como versión definitiva. HTML, texto plano y PDF son versiones de publicación derivadas. RFC 7991 proporciona el vocabulario fuente. El archivo definitivo es autónomo y conserva la información prevista; la imagen de una pantalla concreta es una proyección de ese registro.

RFC 9896 limita la proyección: prohíbe scripts, recursos externos, animación e interacción. Permite reacciones acotadas —escala, modo oscuro o claro, ajustes menores— con la intención de no cambiar el significado. Esas reglas reducen dependencias ocultas, pero no prueban que el orden visual sea correcto, que el color no transporte información exclusiva o que un lector de pantalla reciba una explicación equivalente.

La accesibilidad tiene su propio expediente. El RPC puede impedir funciones que fallen en dispositivos comunes, pantallas pequeñas o baja resolución, y debe procurar el acceso de personas con discapacidad visual. Las normas de accesibilidad del W3C orientan la decisión; SVG 2 define un lenguaje más amplio que el subconjunto admisible en un RFC. Validez W3C, aceptación RPC y accesibilidad observada son hechos distintos.

Los autores pueden ofrecer varias versiones de una imagen y cada formato escoger la más adecuada. Por eso el control debe unir el mapa de afirmaciones textuales, los hashes de la fuente y alternativas, la versión de política y herramienta, los renderizados, pruebas de zoom y contraste, la descripción accesible y el archivo. Cuando cambia la herramienta, importa más comparar proposiciones que comparar píxeles.

La política permite evolucionar sin prometer compatibilidad total. El RPC documenta el uso aceptable, comunica cambios, consulta a la comunidad y explica su razonamiento. RFC 9280 sitúa esa delegación en el gobierno de la Serie; el registro del RFC Editor fija la identidad de publicación. Ninguno demuestra cómo se comportó hoy un producto concreto.

La especificación inicial mínima de Heng Lu preserva una obligación semántica común y deja decisiones futuras bajo responsabilidad local. La primacía del código en ejecución exige probar los renderizados reales. Las capas de realidad impiden elevar un símbolo aceptado a prueba de comprensión.

El diagrama puede entrar en el registro definitivo. No puede sustituir la proposición que permite juzgarlo.

Sources