Este texto es una traducción del artículo RFC 8153: Digital Preservation Considerations for the RFC Series publicado el 25 de abril de 2017 en el blog del especialista en DNS Stéphane Bortzmeyer, quien estuvo en La Paz en el mes de abril de 2017 para un seminario sobre seguridad informática. Trata del difícil problema del archivo y de la preservación de la documentación digital, en el caso del artículo se refiere a los RFC, los estándares de Internet, pero los conceptos se pueden aplicar cabalmente a los documentos administrativos y legales, en particular a los documentos firmados digitalmente, que tienen valor legal en Bolivia desde la Ley 164 de 2011, y por lo tanto requieren un cuidado especial en cuánto a su resguardo.
Como lo acostumbra hacer Stéphane en su blog, el artículo traducido es una ficha de lectura de un RFC, en este caso el RFC 8153, en la cual repasa todo el contenido y aporta con comentarios sobre el contexto.
Traducción el 03 de mayo de 2017 por Sylvain Lesage y Natalia Antezana. Publicado bajo la licencia GFDL.
Tenemos que preservar los bits (pero no solo eso…) – licencia CC BY-NC-SA 2.0
RFC 8153 – Digital Preservation Considerations for the RFC Series
Fecha de publicación: Abril de 2017
Autor del RFC : H. Flanagan (RFC Editor)
La preservación a largo plazo de documentos que nunca se materializaron en forma papel, es un desafío importante de nuestra época. Hoy en día podemos volver a leer toda la correspondencia del canciller de Louis XV (NdT: rey de Francia entre 1715 y 1774), pero ¿podremos, en uno o dos siglos, volver a leer los documentos digitales del siglo XX? ¿Podremos leer los RFC? Es el objetivo de este documento: explorar las pistas para dar a los RFC mayores chances de conservación.
El RFC Editor (RFC 6635) es a la vez el editor y el archivista de los RFC. Las dos funciones son generalmente contradictorias: el editor quisiera usar los últimos gadgets para publicar cosas lindas (multimedia, por ejemplo, o contenidos ejecutables), mientras que el archivista es prudente y conservador y quisiera tecnologías simples. El editor tiene que producir documentos claros y legibles. El archivista tiene que conservarlos para un periodo potencialmente mucho más largo que las modas tecnológicas, un periodo que puede alcanzar siglos (estamos encantados, hoy en día, cuando encontramos textos de leyes de un reino olvidado desde tiempo, en el fondo de la Mesopotamia, aún cuando estas leyes cesaron desde tiempo de ser aplicables).
Tomen nota que las organizaciones como la IETF producen muchos documentos (las discusiones sobre las listas de difusión, por ejemplo), pero que este RFC se focaliza sobre la preservación de los RFC.
Históricamente los RFC eran solo de texto. Este formato tenía muchas ventajas [fr]. Simple y auto-documentado (la única especificación necesaria para entenderlo era ASCII). Era conveniente para el archivo. Regularmente los novatos pedían que el RFC Editor pase a un formato « más moderno », aunque solo fuera una moda pasajera, olvidada después de algunos años. Entonces el formato de solo texto se ha mantenido mucho tiempo y con razón.
Pero la rueda de la historia giró y a partir del RFC 6949 se definió que no nos íbamos a quedar con solo texto eternamente. El formato oficial de los RFC, descrito en el RFC 7990, es ahora basado en XML, con varios enriquecimientos como el juego de caracteres Unicode (RFC 7997) o las imágenes en SVG (RFC 7996). Lo que genera una presión mucho más fuerte sobre los responsables del archivo: si no tenemos la certeza de que podamos leer un texto plano en ASCII en cien años ¿qué pasará con las imágenes SVG? A priori, el anterior sistema de archivo de los RFC no bastará. El XML en sí es relativamente auto-documentado. Si ponemos documentos XML frente a un programador que no conoce este formato, probablemente podrá realizar ingeniería inversa para recuperar lo esencial. Pero no es necesariamente el caso para vocabularios que usan XML, en particular el complicado SVG.
El nuevo sistema de archivo seguirá el marco conceptual de OAIS (norma ISO 14721, disponible en línea). Sobre OAIS, se recomienda leer la buena introducción de Emmanuelle Bermes [fr]. En particular, hay que distinguir dos tareas (sección 1.1 de nuestro RFC):
– Preservación de los bits: archivar un fichero informático y poder sacarlo decenas de años más tarde, sin cambio de un solo bit. Se hace, por ejemplo, copiando regularmente el fichero sobre nuevos soportes físicos, y verificando mediante una suma de control o una firma que nada cambió. Entonces unas copias de seguridad clásicas, verificadas regularmente, son suficientes.
– Preservación del contenido: no basta con almacenar y restituir los bits, se tiene que presentar también el contenido al usuario. Tener una copia perfecta de los bits de un fichero WordPerfect de 1990 no sirve mucho si ya no existe ningún software capaz de leer el WordPerfect en las máquinas y sistemas operativos modernos. Asegurar la preservación del contenido es más complejo pero existen varias soluciones: por ejemplo guardar una descripción del formato (para que siempre podamos desarrollar una herramienta de lectura) y/o guardar también las herramientas de lectura -no solamente los ficheros- y todo el entorno que permite hacerlo funcionar.
Sin embargo, este problema de archivo de ficheros digitales en un largo plazo no es nuevo ni específico a los RFC. Ha sido estudiado por numerosos organizaciones. Se puede citar la BNF [fr], el proyecto LIFE en Gran Bretaña [en], o el estudio del ciclo de vida hecho en la Biblioteca del Congreso [en]. Existen procesos para mantener en el largo plazo los ficheros, con copias regulares y numerosas verificaciones.
Los RFC se benefician desde hace cierto tiempo de un mecanismo similar de preservación de los bits: los metadatos (indispensables para encontrar un documento) son creados y registrados, los ficheros son copiados de una computadora a otra a medida que las antiguas tecnologías de almacenamiento se vuelven obsoletas. Además, desde 2012, todos los RFC son impresos sobre papel, para doble seguridad. Los RFC anteriores a 2010 también se someten a veces al mismo procesamiento, pero existen huecos (RFC perdidos, o simplemente, problemas con el derecho de autor, antes que este tema sea tratado específicamente, ver el RFC 3979)
Esta copia papel demostró su utilidad por lo menos una vez, cuando 800 RFC tuvieron que ser transcritos de nuevo a mano, luego de una falla informática (y una deficiencia en las copias de seguridad). Un pequeño detalle: el RFC Editor en una época aceptaba documentos que no eran RFC y que se tenían también que resguardar (ver la antigua historia de los RFC).
Actualmente no se archiva el entorno software usado para leer los RFC, ya que no es necesario: podremos leer texto plano en ASCII en cien años (la prueba es que no tenemos dificultad en leer el RFC 1, viejo de cuarenta y ocho años). El proceso de resguardo preserva los bits, y consideramos que la preservación del contenido no es un problema, con un formato tan simple. Por ejemplo, la impresión sobre el papel no conserva los vínculos, pero no es un problema porque no hay en el formato texto plano.
Pero, ya que los RFC pronto van a dejar este formato tradicional y migrar hacia un formato más rico, hay que reconsiderar el tema. La sección 2 de nuestro RFC explora en detalle las consecuencias de esta migración en cada etapa del ciclo de vida. Ahora hay que preocuparse de la preservación de los contenidos, no solamente de los bits.
Ciertas características del ciclo de vida de los RFC facilitan el archivo. Así, los RFC no se modifican. Aun en caso de error en un RFC, nunca se cambia (eventualmente, se publica un nuevo RFC, como se hizo para el RFC 7396). No se requiere entonces resguardar versiones sucesivas. Otras características del ciclo de vida de los RFC complican el archivo. Así, el RFC Editor no es quien decide si aprobar o no un RFC (ver el RFC 5741). Entonces, no tienen el poder de rechazar un documento según sus criterios propios.
El RFC Editor mantiene una base de datos (no accesible desde el exterior) de los RFC, obviamente con los metadatos asociados (estado, autores, fecha, DOI, vínculos hacia los eventuales errata porque nunca se corrige un RFC, etc.) Las páginas de información sobre los RFC son generadas automáticamente desde esta base (por ejemplo https://www.rfc-editor.org/info/rfc8153, para este RFC).
Los RFC citan, en la parte final de la bibliografía, unas referencias de las cuales algunas son normativas (necesarias para entender el RFC), las otras son solo para « saber más del tema ». Idealmente, los documentos puestos como referencia deberían también ser archivados (aunque no sean RFC) pero no es el caso. Nuestro RFC sugiere que la utilización de Perma.cc podría ser una buena solución. Es un mecanismo de archivo de datos exteriores mantenido por un grupo de bibliotecólogos jurídicos de diversas universidades. Por ejemplo, esa es la copia de seguridad Perma.cc (https://perma.cc/E7QG-TG98) de mi artículo en el hackathon del IETF.
En un proceso de archivo, una etapa importante es la normalización, que va a borrar los detalles considerados como no pertinentes. Va a permitir la preservación del contenido, al evitar conservar variantes que solo complicarán el trabajo del software. Por ejemplo, aunque XML permite utilizar el juego de caracteres que uno quiere (indicándolo en la declaración, al inicio), una buena normalización pasará todo en UTF-8, simplificando la tarea del programador que tendrá algún día que escribir o mantener un software de lectura del XML, cuando este formato haya sido medio olvidado.
Sin embargo, en el transcurso de la historia de los RFC, el RFC Editor a recibido muchos formatos diferentes, incluso RFC únicamente en papel. Hoy en día, por lo menos hay el formato texto plano, y a veces otros.
Ahora que existe un formato canónico oficial (definido por el RFC 7991), ¿cuáles son las soluciones para asegurar la preservación del contenido?
– Best effort, preservar los bits y esperar (o contar sobre los emuladores, lo que se hace mucho en el mundo del juego vídeo vintage),
– Preservar un formato concebido para el archivo (PDF/A-3 siendo un candidato evidente – ver el RFC 7995, además porque permite incorporar XML en el documento PDF),
– Preservar el XML y todas las herramientas, producción, test, validación, etc. (lo que los matemáticos o programadores en lenguajes funcionales llamarían una clausura).
La primera solución, utilizada actualmente, no es realista desde la adopción del nuevo formato; tiene que ser abandonada. La segunda solución conserva la información en el documento, pero no el documento mismo (es preocupante que el formato archivado no sea el formato canónico, sino solamente una de sus representaciones). Y el futuro de PDF/A-3 es incierto, todavía no hemos probado leerlo treinta años después, y las promesas del marketing deben ser consideradas con prudencia (más sabiendo que todavía existen pocas herramientas PDF/A, por ejemplo no hay ningún software para verificar que un documento PDF sea conforme a ese perfil restrictivo). La tercera solución permitiría generar documentos a partir de los RFC de vez en cuando, adaptando a las herramientas que serán modernas en aquel tiempo. Pero también es la solución más cara. Si piensan en un futuro en el cual XML, HTML y PDF son lejanos recuerdos del pasado, ¡imagínense lo difícil que implicaría preservar un entorno de ejecución completo, los navegadores, las bibliotecas de las cuales dependen, el sistema operativo y hasta el material sobre el cual corre!
Una solución más liviana de hacer, por ejemplo cada año, es una revisión de las técnicas existentes y ver si todavía es posible, y fácil, visualizar los RFC archivados. Si no es el caso, será el momento de lanzarse en el desarrollo para generar versiones legibles.
De hecho, ya existen softwares para ayudar en estas tareas (el RFC menciona el software libre de gestión de archivos ArchiveMatica).
Después de este análisis, la sección 3 de nuestro RFC presenta recomendaciones: la idea es resguardar el formato canónico (XML), un archivo PDF/A-3, la futura herramienta xml2rfc y por lo menos dos lectores PDF (que deben ser capaces de extraer el XML embebido). Entonces las tareas inmediatas son:
– Producir PDF/A-3 (al momento de la publicación de este RFC, la herramienta no ha sido desarrollada todavía) con el XML adentro, y archivarlo,
– Archivar el formato canónico (texto plano para los viejos RFC, XML para los nuevos),
– Archivar las versiones mayores de las herramientas, en particular xml2rfc,
– Archivar dos lectores PDF,
– Establecer acuerdos con diferentes instituciones competentes para asegurar el resguardo de los bits (ya es el caso de la biblioteca nacional de Suecia). Una guía de evaluación de estos archivos es ISO 16363.
La versión papel, sin embargo, ya no será archivada.
Conclusión (sección 4): los RFC son documentos importantes, que representan un interés para las futuras generaciones, y que valen la pena que nos esforcemos para preservarlos en el largo plazo.
[…] a la norma OAIS que rige la preservación de la documentación digital. Complementa el artículo RFC 8153 – Consideraciones sobre la preservación digital de las series de RFC para quién se interesa en el resguardo de la documentación digital, que sea administrativa o […]