Summary

  • La RFC 769 describió cómo convertir los bloques del fax Rapicom 450 en registros de archivo para que instituciones con equipos compatibles intercambiaran páginas almacenadas mediante protocolos de transferencia.
  • Los registros marcaban preparación, datos y final, pero el contenido permanecía codificado a la manera de la máquina. Para obtener una imagen había que conocer y aplicar ese procedimiento de decodificación.

Mucho antes de que «adjuntar un documento» pareciera un gesto trivial, varias organizaciones de la comunidad ARPA Internet tenían equipos de fax Rapicom 450 conectados a ordenadores. Podían guardar la representación de una página y recuperarla con el aparato. Jon Postel documentó en septiembre de 1980 la forma del archivo para que otras instituciones con máquinas compatibles participaran en el intercambio. El papel empezaba a viajar sin subirse al correo.

Había una condición con dientes. El Rapicom 450 producía bloques de 585 bits con un código incorporado a la máquina. Meter esos bloques en un archivo facilitaba copiarlos por la red; no los transformaba en una imagen de píxeles comprensible para cualquier programa. La RFC lo decía directamente: para usar el bloque como mapa de bits había que conocer y emplear el método de codificación y decodificación. El sobre era transportable. El idioma de la carta seguía siendo asunto del aparato.

La utilidad del documento estaba en hacer preciso ese sobre. Cada registro comenzaba con un byte de longitud y otro de orden; luego venían los datos. La longitud incluía también los dos bytes iniciales. Las órdenes 56, 57 y 58 correspondían a SET-UP, DATA y END. El último registro podía tener solo dos bytes. Gracias a esas marcas, otro ordenador sabía dónde empezaba la preparación, qué parte contenía bloques de página y cuándo terminaba el archivo.

El bloque SET-UP muestra una decisión editorial del formato, por decirlo así. La máquina enviaba o recibía varias copias idénticas durante su funcionamiento. En el archivo se guardaba una sola. Postel no estaba congelando cada repetición del aparato: conservaba la información que otro equipo compatible necesitaba para continuar. El rastro operativo y la representación duradera no coincidían exactamente.

También había una pelea aritmética. Setenta y tres bytes suman 584 bits, justo uno menos que un bloque Rapicom. Por eso se reservaban 74 bytes para datos. Con el byte de longitud y el de orden, un registro habitual medía 76 bytes. La RFC describía los archivos intercambiados hasta entonces con un bloque por registro: primero SET-UP, después DATA y al final END. Es un detalle pequeño hasta que alguien se equivoca de frontera y desplaza todo lo que sigue. Las páginas no perdonan a un contable distraído.

El texto anotaba una marca de sincronización de 24 bits al comienzo de cada bloque y dos bits de secuencia que recorrían cuatro valores en los bloques DATA. Servían para reconocer la estructura que salía del equipo. Su presencia no entregaba la imagen por sí sola. Un lector de archivos podía separar registros; el mecanismo específico de Rapicom debía reconstruir las señales que acabarían formando la página. Recibir, interpretar y mostrar eran etapas distintas.

El objetivo de 1980 era sumar participantes que ya dispusieran de facsímiles compatibles. Doce años después, la RFC 1314 propuso un formato TIFF-B autónomo para intercambiar imágenes parecidas a un fax por Internet. Esa ambición posterior ofrece una comparación útil: el archivo de Postel ponía de acuerdo a una familia de dispositivos; el formato de 1992 buscaba una representación de imagen más general. No hacía falta fingir que ambos proyectos resolvían el mismo problema de la misma manera.

El recorrido completo revela la historia: hoja, equipo, bloque codificado, registro de archivo, transferencia y equipo compatible al otro lado. Internet había ganado la capacidad de transportar la página como datos. El derecho a entenderla seguía guardado en la máquina. Para una institución nueva, comprar el billete de red era apenas la primera mitad del viaje.