Resumen

  • RFC 9720 distingue el formato XML definitivo de las versiones publicadas en HTML, texto y PDF, y permite corregirlos o regenerarlos sólo bajo una obligación de preservar el contenido semántico en la mayor medida posible.
  • La garantía no reside en llamar «canónico» al archivo actual, sino en poder ver la versión anterior, la fecha, la razón de la reedición y la diferencia relevante para quien depende del RFC.

Cuando “publicado” dejó de significar un solo fichero

La vieja promesa de estabilidad era fácil de entender cuando un RFC era, en la práctica, un documento ASCII. Hoy una misma publicación tiene un XML que contiene la información destinada al RFC y varios productos de lectura: HTML, texto plano y PDF. Esa pluralidad mejora accesibilidad y legibilidad, pero abre una pregunta de control. Si el XML contiene una errata, o el generador ha de modernizarse, ¿debe el archivo conservar el defecto? Si puede cambiar, ¿qué impide que una mejora editorial altere lo que un implementador creyó obligatorio?

RFC 9720 no resuelve la pregunta con fe en la institución. Publicada en enero de 2025 en la corriente Editorial, sustituye RFC 7990 y modifica la política de estabilidad de RFC 9280. Es un RFC informativo: ofrece una política de publicación de la Serie RFC, no una orden de despliegue ni una certificación de que toda reedición sea inocua.

Su primer control es separar conceptos. El formato definitivo es RFCXML. La versión definitiva es el RFC publicado en ese formato. HTML, texto y PDF son formatos de publicación, y cada salida concreta es una versión de publicación. Antes, “canonical format” mezclaba la fuente que permite renderizar y el documento autorizado y archivado. La distinción importa porque un PDF distinto no demuestra por sí mismo un estándar distinto, y un XML mantenible no se convierte por ello en una facultad ilimitada de edición.

La autoridad de mantenimiento tiene causas concretas

El RFC Production Center puede reeditar una versión definitiva por cambios del esquema RFCXML, errores descubiertos en el XML o modificaciones de las herramientas que producen las versiones de publicación. La regla no dice que sea imposible introducir un cambio semántico por accidente. Reconoce el riesgo y exige preservarlo en la mayor medida posible, comprenderlo y reducirlo.

Las versiones de publicación también pueden reeditarse, pero el verbo es “puede”, no “debe”. El centro ha de considerar tanto la coherencia de la Serie como el riesgo semántico. Esta combinación evita dos abusos. El inmovilismo no puede mantener un fallo conocido sólo para repetir que nada cambia; la estética tampoco puede invocarse para reemplazar sin examen un artefacto histórico.

Aquí hay una especificación inicial pequeña y una decisión localizada. La regla compartida fija el límite que todos necesitan: el significado no se mueve libremente. Las decisiones sobre almacenamiento, localizadores o herramientas futuras quedan donde existe el conocimiento operativo. RFC 9720 ni siquiera prescribe cómo se encontrarán los documentos históricos. No es una laguna que una política de formatos no posea todas las decisiones de archivo.

El historial convierte la afirmación en evidencia

La parte más importante de la política no es la excepción de reedición; es su recibo. El RPC debe conservar conjuntos archivados de las versiones definitivas y de publicación anteriores, mediante los mismos métodos de acceso que las actuales. Cada conjunto lleva fecha de creación o reedición. Además, cada reedición de una versión definitiva ha de tener registro público y una breve explicación.

Por eso una página HTML actual no basta para una investigación. Para saber si un diagrama, una referencia, una palabra normativa, un carácter no ASCII o un ejemplo ejecutado por una herramienta cambió, hace falta mirar el antecesor y el sucesor. Una ruptura de línea quizá sea sólo visual. Un cambio de MUST, de un URI o de una estructura de datos puede afectar código, compras o auditorías. La conclusión no la proporciona el diseño de la página ni una nota tranquilizadora: la proporciona el diff y la dependencia concreta.

El archivo distribuye, además, las responsabilidades. El proceso autoral y de aprobación define el sentido previsto. Producción mantiene la representación dentro del límite. El operador, el proveedor y el implementador deciden qué versión fijan y cómo prueban el cambio. Que el servidor entregue una copia nueva no autoriza a producción a decidir por el sistema que asume el riesgo.

El perfil público de IETF sitúa a Heather Flanagan como antigua RFC Series Editor entre 2012 y 2019, principal de Spherical Cow Consulting y actual copresidenta de SPICE y HotRFC. Esa trayectoria explica el ángulo personal. No permite atribuirle autoría única, un cargo operativo actual en el RPC ni responsabilidad sobre toda decisión posterior.

Ni el mismo número ni el archivo nuevo cierran la cuestión

RFC 9920, publicada en febrero de 2026, dejó obsoleta RFC 9280 y actualiza RFC 9720 junto con otros textos de la Serie. La política también cambia mediante procedimiento; ese hecho no prueba que cualquier cambio en una copia publicada sea seguro. Para cada dependencia la pregunta sigue siendo específica: ¿qué versión se utilizó, qué cambió, qué componente interpreta esa parte y puede revertirse la decisión?

El expediente de un operador debería conservar el número RFC, los identificadores y fechas de las versiones definitiva y de publicación, URL y hash de recuperación, la explicación de la reedición, una comparación semántica y otra de renderizado, el componente dependiente, el revisor y un límite de despliegue reversible. La copia previa debe seguir siendo obtenible.

Las notas de Heng Lu ayudan a no invertir la cadena de autoridad. Una justificación publicada es evidencia sobre una acción del editor; no es mandato para que un tercero actualice automáticamente su implementación. Quien responderá por la interrupción, el fallo de conformidad o la obligación contractual conserva el derecho y el deber de verificar.

Fuentes