Resumen

  • RFC 5385 describió una plantilla de Word capaz de ofrecer una vista e impresión muy próximas al ASCII conforme, aunque la producción real seguía pasando por estilos controlados, un controlador de texto y un posprocesador Perl.
  • La igualdad visible no identifica el registro autorizado ni garantiza que se conservara el significado. La política moderna de la serie RFC separa una versión definitiva en RFCXML de sus versiones publicadas en HTML, texto y PDF.

El traspaso de responsabilidad que nadie veía

El autor terminaba de editar en Word. La aplicación enviaba el documento a una impresora genérica de solo texto. El sistema generaba un .prn. Después, un programa Perl limpiaba finales de línea, sustituía comillas y guiones, reconstruía saltos de página y buscaba caracteres ilegales. Solo al final aparecía el texto destinado al formato RFC.

Ese recorrido, documentado por RFC 5385 en 2010, contiene varios cambios de responsabilidad. El autor controlaba el argumento. La plantilla imponía estructura. Word interpretaba estilos y campos. El controlador elegía una representación textual. El posprocesador decidía qué normalizar y qué rechazar. El revisor comprobaba la salida. La autoridad editorial publicaba el resultado.

Sin embargo, una vista previa podía ocultar todos esos relevos. El propio RFC destacaba que el documento se podía ver e imprimir línea por línea y página por página como el ASCII conforme, salvo pequeñas diferencias de puntuación. Era una ventaja de uso, no una afirmación de que ambos objetos fueran idénticos.

El error institucional comienza cuando el parecido absorbe las responsabilidades. Si “se ve bien” equivale a “es el archivo correcto”, ya no queda claro quién responde por una transformación, qué versión fue aprobada o cómo reconstruirla. Una página termina convertida en sustituto de la evidencia que la produjo.

Los estilos eran instrucciones, no adornos

La segunda versión de la plantilla sustituyó parte del esquema anterior. Redefinió estilos habituales de Word —Normal, Heading1 a Heading9, cabecera, pie y leyenda— y añadió otros para figuras, listas, referencias y apéndices. El texto advertía que era crítico no utilizar estilos ajenos al conjunto previsto.

La razón estaba en el modo de esquema. Los encabezados internos permitían subir o bajar secciones y renumerarlas. Una línea grande y en negrita podía parecer un título sin comportarse como tal. El aspecto no revelaba si el párrafo participaba en la estructura.

Esta separación sigue presente en cualquier editor rico. Una tabla puede dibujarse con espacios. Un enlace puede ser solo color. Una lista puede ser una sucesión de guiones. Para el lector visual, el resultado funciona; para un conversor, una tecnología asistiva o un archivo, falta la semántica.

La recepción debe revisar las dos capas. En la visual, se comprueban legibilidad, cortes, figuras y alineación. En la estructural, se inspeccionan niveles de título, referencias, orden de lectura, destinos, descripciones y campos. Ninguna de las dos autoriza por sí sola a la otra.

Normalizar también es decidir

El posprocesador de RFC 5385 convertía signos tipográficos a equivalentes ASCII. Eliminaba retornos de carro y espacio repetido entre páginas. Insertaba un form feed. Marcaba bytes no permitidos.

Son acciones pequeñas hasta que el texto contiene un nombre, un símbolo o una distinción que el alfabeto de destino no representa. Entonces, “limpiar” puede significar conservar, aproximar, borrar o detenerse. La herramienta adopta una política editorial técnica aunque nadie le atribuya una firma.

Por eso no basta con guardar el archivo inicial y el final. Hay que conservar la herramienta exacta, su configuración, el entorno, la salida diagnóstica y el resultado de la validación. La inclusión del script en el apéndice del RFC ayudaba a hacer visibles sus reglas, pero no demostraba qué copia se ejecutó en una ocasión concreta.

Una práctica contemporánea debe producir recibos verificables: huella de la fuente aprobada, versión y huella del generador, opciones, momento de ejecución y huella de cada artefacto. Después debe comparar significado, no solo bytes o píxeles. Los títulos, requisitos, identificadores, enlaces, figuras y referencias han de sobrevivir con intención reconocible.

Una etiqueta estable podía esconder una plantilla móvil

La sección de seguridad de RFC 5385 afirmaba que la plantilla no contenía macros tal como se desarrolló y distribuyó. También explicaba por qué no fijó dentro del RFC la suma MD5 de la plantilla: el archivo se actualizaba para seguir cambios en el texto obligatorio. La suma vigente se publicaba junto al recurso externo.

No se debe interpretar aquello como una recomendación criptográfica actual. Sí ofrece una lección de configuración. El nombre del documento explicativo era estable; el objeto operativo podía cambiar. “Usamos la plantilla de RFC 5385” no identificaba una versión concreta.

En las empresas, el mismo problema aparece cuando “el contrato estándar” o “el informe oficial” cambia sin que cada copia producida guarde la versión. Un nombre común concede una continuidad imaginaria. La auditoría descubre demasiado tarde que dos archivos con la misma etiqueta incorporaron condiciones diferentes.

Una plantilla mutable necesita identidad propia: versión, fecha efectiva, huella, responsable y registro de cambios. El documento generado debe conservar esa relación. Si el modelo inserta contenido legal o normativo, el aprobador debe revisar el texto expandido. Confiar solo en el nombre es delegar autoridad a un puntero móvil.

El caso de las referencias demostraba el riesgo dinámico

La plantilla anterior utilizaba notas finales para referencias. Según RFC 5385, la primera cita definía la nota, y eliminarla podía borrar la referencia aunque quedaran otras llamadas. La revisión llevó las referencias numeradas a párrafos normales y ofreció marcadores para rótulos de autor y año.

Antes de editar, dos páginas podían verse iguales. Después de borrar una cita, una conservaba la referencia y otra no. El fallo estaba en el comportamiento, no en la fotografía inicial.

Por eso una prueba documental debe cambiar el contenido deliberadamente. Mover un encabezado. Borrar la primera cita. Añadir un apéndice. Cambiar una figura. Regenerar todos los formatos. La pregunta no es si una muestra quedó bonita, sino si las propiedades importantes resisten operaciones normales.

Ese enfoque también sirve para informes automáticos. Una plantilla que funciona con diez filas puede romper la lectura con cien. Un generador que maneja ASCII puede perder nombres en otra escritura. La conformidad se demuestra con invariantes y casos límite, no con un ejemplar privilegiado.

De una salida principal a una fuente semántica definitiva

La serie RFC evolucionó después de 2010. RFC 6949 recogió necesidades de accesibilidad, metadatos, gráficos, caracteres internacionales y dispositivos variados. RFC 7990 propuso un nuevo marco. RFC 9720, que lo sustituyó en 2025, define con precisión cuatro conceptos.

RFCXML es el formato definitivo. Un RFC publicado en él es una versión definitiva. HTML, texto sin formato y PDF son formatos de publicación. Los archivos concretos en esos formatos son versiones de publicación. La versión definitiva contiene toda la información prevista y resuelve las dudas sobre la intención publicada.

No es correcto aplicar esas palabras como si gobernaran el Word de RFC 5385. El valor comparativo es otro: en 2010 ya era visible que el taller de autor, la transformación y la copia distribuida no eran un solo objeto. La política actual convirtió esa diferencia en un reparto explícito de autoridad.

Una empresa debería poder responder igual de rápido: ¿manda la base de datos, el documento estructurado, el PDF firmado o la copia del portal? Si la respuesta depende de quién pregunta, existe un conflicto no resuelto. Las representaciones pueden ser oficiales sin ser definitivas; la organización debe decir cuál prueba qué.

Regenerar no debe borrar el pasado

RFC 9720 permite reediciones limitadas cuando cambian esquemas o herramientas, siempre con preservación del significado, registro público y acceso a versiones anteriores. También reconoce el riesgo de introducir cambios involuntarios durante la regeneración.

La política es relevante para cualquier archivo vivo. Congelar para siempre puede volver inaccesible un documento. Regenerar sin control puede reescribirlo. La solución es conservar la historia y limitar el cambio.

Cada reedición necesita motivo, fuente anterior y nueva, salidas anteriores y nuevas, huellas, herramientas, comparación semántica, revisión y fecha. Una mejora tipográfica no debe alterar una obligación. Una corrección de estructura no debe desaparecer del historial.

RFC 9920 completa el reparto: la política y su aprobación no son lo mismo que su implementación por el RFC Production Center. Además, el diseño y mantenimiento de las herramientas tiene un responsable explícito. Quien opera el sistema responde por la fidelidad de la producción, pero no adquiere poder editorial por manejar el botón.

La prueba completa tiene cuatro piezas

Primero, un recibo de intención: fuente semántica exacta, autor, alcance y aprobación. Segundo, un recibo de transformación: entradas, herramientas, parámetros, advertencias y salidas. Tercero, un recibo de publicación: autoridad, identificador, estado, fecha y ubicación. Cuarto, un recibo de archivo: versiones, motivo de reedición y recuperación ensayada.

La vista previa pertenece al segundo recibo. Es imprescindible para comprobar la experiencia de lectura, pero no puede reemplazar la identidad de fuente ni el acto institucional de publicación. Una huella tampoco los reemplaza: demuestra igualdad de bytes, no legitimidad.

La prueba de aceptación final debe pedir a otra persona que reconstruya una salida en un entorno limpio, explique cada diferencia y recupere la versión previa. Si el sistema solo puede mostrar una captura convincente, ha demostrado una apariencia y ha perdido la historia.

Fuentes