Resumen

  • La RFC 1432 obtuvo numerosos datos bibliográficos de un catálogo de la Library of Congress consultado por Gopher y Telnet, una prueba de descubrimiento en red, no de existencias ni de entrega.
  • La lista mezclaba obras impresas, ediciones solo en línea, publicaciones parciales y títulos futuros, y advertía que precios, teléfonos, direcciones y correos podían cambiar.
  • La evidencia debe avanzar por etapas: registro localizado, ruta intentada, respuesta recibida, objeto identificado, oferta confirmada y copia entregada.

Tres verbos para no fabricar una certeza

Encontrar responde a una consulta. Conseguir exige que alguna institución suministre un objeto. Recibir añade el desenlace de una transferencia o una entrega. En una interfaz moderna, los tres actos pueden caber detrás de un solo botón. En la RFC 1432 todavía se veían las costuras.

John S. Quarterman reunió una lista de libros relacionados con el uso de Internet. La aparición de nueve o diez títulos en aproximadamente un año —algunos aún sin publicar— justificaba el repaso. Una tabla comparaba autor, páginas, precio, público, tipo y cobertura de otras redes. No fingía uniformidad: había interrogantes, categorías superpuestas y obras que el compilador declaraba no haber visto.

El texto había aparecido primero en Matrix News en diciembre de 1992 y pasó a ser una RFC informativa en marzo de 1993. Ese tránsito importa. Un artículo periódico podía solicitar cambios; una RFC conservaba de forma duradera la observación. Su permanencia no volvía permanentes los datos comerciales que contenía.

La red conocía el catálogo, no el almacén

Gran parte de los detalles procedía del servidor de catálogo de la Library of Congress, accedido mediante Gopher y Telnet. La procedencia reforzaba la descripción bibliográfica. También delimitaba lo que podía afirmarse.

El catálogo sabía que representaba una obra o edición. El servidor sabía responder a una sesión. Gopher o Telnet transportaban el acceso. El editor sabía qué había publicado. Un distribuidor conocía sus existencias. Un servidor FTP controlaba un archivo y una ruta. El lector reunía esas piezas, pero ninguna institución veía necesariamente la cadena completa.

Por eso un resultado de catálogo no era una copia digital. Tampoco certificaba que la Library of Congress fuese el punto de venta ni que el editor conservara ejemplares. La red reducía el coste de enterarse de que un libro existía; no trasladaba el control del inventario al índice.

La columna “otras redes” añadía otra precaución de alcance. Quarterman empleaba “Matrix” para el conjunto histórico de redes mundiales que intercambiaban correo, con FidoNet, UUCP, BITNET, USENET e Internet entre ellas. El artículo estaba orientado a Internet, pero algunos libros describían un espacio mayor. Un nombre de colección no convertía todos esos sistemas en una sola red operativa.

Una ruta escrita no era una copia entregada

Cuando una referencia terminaba en domain.name:path/name, la RFC explicaba el procedimiento: conectar por FTP, iniciar sesión como usuario anónimo, usar el correo como contraseña y probar la parte restante como directorio o archivo. Si terminaba en local@domain, se trataba de un contacto para pedir información.

La precisión de las instrucciones puede dar una ilusión de garantía. Sin embargo, una ruta solo especifica un intento. El host puede dejar de existir, el directorio cambiar, el archivo ser un anuncio o una tabla de contenido, y la edición disponible no coincidir con la descrita. Una dirección puede aceptar correo sin que nadie responda. Un pedido puede ser aceptado y no terminar en entrega.

La RFC 1175 ya había reunido, en 1990, materiales en línea y en papel para usuarios principiantes e intermedios. Daba datos bibliográficos, resúmenes y maneras de obtenerlos. Incluso señalaba que los comandos FTP podían variar entre sistemas. Saber qué buscar, saber cómo intentarlo y obtener el material eran capas diferentes del servicio.

Una obra podía cambiar de medio en la misma lista

La RFC 1432 no hablaba de una oferta puramente impresa. The Internet Companion se estaba publicando por FTP anónimo a razón de dos capítulos mensuales. La primera edición de Zen and the Art of the Internet estaba disponible únicamente en línea desde varios servidores FTP; la segunda era más extensa, estaba actualizada y se vendía como libro impreso. Otras entradas remitían a ficheros de anuncio o contenidos.

Así, “disponible” necesitaba sujeto y objeto. ¿Disponible como obra o como edición? ¿Como fichero completo, entrega parcial, anuncio, ejemplar físico u oportunidad de encargarlo? ¿Para una persona con acceso directo a Internet o para alguien limitado al correo? ¿En qué país y con qué coste de envío?

Un ISBN puede apoyar la identidad de una edición. No prueba que el fichero descargado sea esa edición. Una huella criptográfica puede fijar unos bytes. No demuestra que esos bytes sean la manifestación autorizada. Una cotización prueba lo que alguien ofreció en un momento, no el precio final ni la recepción.

El precio llevaba un reloj incorporado

Quarterman advertía que los precios, correos electrónicos, teléfonos, faxes y direcciones postales podían cambiar. Un descuento podía abaratar la compra; el envío o una operación fuera de Estados Unidos podía encarecerla. El texto pedía notificar errores, cambios y adiciones.

La advertencia no rebajaba la calidad de la lista. Definía la vigencia de sus campos. Autor, título e ISBN podían ser relativamente estables para una edición concreta. Precio, contacto, ruta de servidor y condición de “próxima publicación” podían caducar deprisa. Ponerlos en una fila no igualaba sus relojes.

La RFC 1402 había descrito ese mundo como información que se movía, crecía, cambiaba y moría. Antes de recuperar algo había que conocer su existencia, decidir su relevancia e indexarlo. La mayoría de sus entradas, decía, eran punteros hacia la información final.

Un puntero es una afirmación acerca de una dirección. El objeto requiere otra observación. Confundirlos permite que una lista congelada aparente ser un almacén vivo y convierte la autoridad documental en una promesa comercial que nunca asumió.

Más herramientas, más traspasos de responsabilidad

La RFC 1580 mostró un año después cuánto se había ampliado el repertorio: Gopher, World-Wide Web, WAIS, Archie, WHOIS, X.500, Netfind y varios servicios de correo y archivos. Los recursos crecían a un ritmo difícil de seguir.

Cada herramienta resolvía una parte. Archie abordaba dónde localizar ficheros y programas; WAIS buscaba en bases; Gopher y la Web permitían recorrer fuentes; otros sistemas encontraban personas o direcciones. Un cliente local, uno remoto y una consulta por correo podían llegar a respuestas diferentes o conservar evidencias distintas.

La superficie se hacía más uniforme, pero la custodia seguía repartida. Esa separación permitió que el Internet creciera sin un catálogo central dueño de cada objeto. También multiplicó los puntos donde un dato podía envejecer.

La escalera probatoria

Un registro localizado demuestra que un catálogo representó algo en un momento. Una ruta anotada demuestra que alguien propuso un acceso. Una respuesta demuestra que un servicio contestó. Una transferencia demuestra que llegaron bytes. La portada, la mención de edición, el ISBN y una huella preservada pueden apoyar la identidad. Una respuesta actual del vendedor apoya una oferta. La recepción demuestra que la copia llegó.

No es una distinción académica. Si se conserva solamente el último estado, se pierde la posibilidad de saber qué pudo intentar un lector de 1993. Si se conserva únicamente el enlace, se desconoce qué devolvía. Si se actualiza el precio sin guardar la fecha, el registro parece haber sabido siempre lo que se averiguó después.

La RFC 1432 hizo algo más honesto que prometer sincronía: dejó visibles las interrogaciones, los estados futuros, los medios distintos, la procedencia del catálogo y la volatilidad de los contactos. Su lista no poseía la estantería. Precisamente por eso sigue siendo una buena fuente para entender quién sí poseía cada fragmento de verdad.

Fuentes