Resumen

  • Mary Ann Horton ayudó a articular el UUCP Mapping Project, que distribuía descripciones mantenidas por voluntarios para que cada sitio calculase rutas de correo desde su propia posición.
  • El resultado dependía menos de dibujar todas las máquinas que de asignar responsables, proteger secretos, expresar costes y retirar la base cuando ya no podía mantenerse vigente.

En una dirección como duke!research!ucbvax!user, los signos de exclamación eran instrucciones. El usuario no solo nombraba a quien recibiría el mensaje: proponía una cadena de ordenadores capaz de transportarlo. Esa cadena podía cambiar según el lugar de origen, la hora de la llamada y la disposición de otra institución a asumir el coste.

Mary Ann Horton vio cómo esa memoria humana dejaba de escalar. Su historia no trata de una persona que dibujó Internet, sino de una comunidad que convirtió conocimiento disperso en un mecanismo operativo.

Dos redes superpuestas que no coincidían

Horton contó a USENIX que repartió mapas lógicos de Usenet en 1982 y 1983. Los asistentes los utilizaron para encaminar correo. Sin embargo, Usenet inundaba noticias entre vecinos, mientras que la malla de correo UUCP era más amplia y tenía otros acuerdos. Tomar una por la otra ocultaba enlaces y descargaba tráfico sobre sitios cooperativos.

En 1984, el dibujo lógico ya tenía demasiadas ramas. Horton llevó un mapa geográfico y Bill y Karen Shannon prepararon otro de ocho páginas. El aumento de papel demostraba el límite: una topología que cambiaba no podía sostenerse como una lámina ocasional.

Además, cada línea tenía una economía. Algunas universidades prohibían llamadas de larga distancia. Determinados centros corporativos aceptaban facturas altas. Un enlace podía existir pero no llamar nunca desde un extremo; podía ser lento pero frecuente, o rápido y poco fiable. La pregunta real era quién actualizaba ese conjunto de condiciones.

Un registro construido por regiones

En enero de 1984, una sesión informal de USENIX en Washington organizó el UUCP Mapping Project. Voluntarios regionales reunían declaraciones de conectividad, conciliaban errores y publicaban los archivos en comp.mail.maps.

Las fuentes no ofrecen una cifra única porque describen fases distintas. El museo Stargate habla de más de treinta voluntarios en la reunión inicial. La página de logros de Horton menciona un equipo de alrededor de cincuenta. Una retrospectiva más amplia incluye a cientos de colaboradores regionales. Ningún número autoriza a borrar la naturaleza distribuida del trabajo.

Tampoco conviene condensar el liderazgo. Horton recuerda haber convocado la sesión y dirigido la creación. Un borrador de cierre de 2000 atribuye la jefatura inicial financiada por USENIX a Karen Summers-Horton y sitúa a Horton al frente desde 1985. La discrepancia se resuelve atribuyendo cada versión, no fabricando una fundadora única.

RFC 850 expone otra decisión institucional. El control senduuname permitía solicitar vecinos para los mapas y autorizaba al administrador a editar la respuesta. Los números telefónicos y las contraseñas del archivo privado no debían publicarse. El registro necesitaba compartir conectividad sin convertir el inventario en una colección de credenciales.

pathalias calculaba una preferencia, no una verdad

Steve Bellovin y Peter Honeyman crearon pathalias. Su modelo trataba hosts y redes como un grafo dirigido. Cada arco tenía un coste no negativo y un operador de dirección; una variante del algoritmo de Dijkstra precalculaba caminos desde el sitio local.

Pero el coste no era una unidad física. Podía incorporar tarifa telefónica, frecuencia de llamada, velocidad, fiabilidad y la experiencia de los operadores. La escala se ajustó para producir rutas que usuarios expertos consideraban razonables. Una corporación y una universidad podían valorar el mismo salto de manera muy diferente.

Los autores describen entradas contradictorias, incompletas y erróneas. Los mapas deducidos del tráfico de noticias tendían a omitir conexiones. El programa podía inferir enlaces de vuelta para alcanzar hosts aislados y usaba reglas especiales para dominios. Incluso una optimización podía eliminar el desvío intencional de alguien que intentaba evitar un enlace muerto.

Por eso cada tabla era local. La publicación compartida ofrecía evidencia; pathalias aplicaba un juicio de costes desde un origen; el software de entrega asumía esa elección. Horton y Adam Buchsbaum trabajaron en smail, que consumía las tablas y liberaba al usuario de memorizar el recorrido completo.

Dar un nombre estable a una ruta cambiante

El texto “What Is a Domain?” de Horton separa dos conceptos: los puntos de un dominio forman una jerarquía de nombres, no una ruta. Un nombre absoluto sigue necesitando una tabla o pasarela que determine el siguiente salto.

RFC 819 define los dominios como ámbitos de autoridad y responsabilidad para traducir nombres. RFC 920 recalca que son entidades administrativas: no requieren la misma geografía, tecnología, protocolo ni topología. La permanencia provenía de una obligación organizativa.

Según el relato de Horton, el proyecto UUCP participó con BITNET, CSNET y ARPANET en el espacio común acordado en 1986. Su página de logros cifra en más de 150 las organizaciones UNIX sin conexión directa que recibieron correo .com o .edu entre 1986 y 1988. Es un dato retrospectivo de la protagonista, no un conteo auditado aquí.

RFC 976 muestra cómo funcionó la transición. Adoptó las normas de dominios y mensajes existentes, separó hosts antiguos y avanzados por capacidades, y exigió que las pasarelas entendieran la forma más completa. El usuario veía user@domain; detrás, una tabla seguía convirtiendo ese nombre en saltos UUCP.

RFC 974 añadió los registros MX: un dominio podía indicar intercambiadores preferidos y cambiar esos datos para evitar un host defectuoso. La complejidad no desapareció. Pasó del remitente a una infraestructura compartida y administrada.

La autoridad también necesita fecha de caducidad

El borrador de conclusión del proyecto afirma que la base se congeló en agosto de 2000, cuando los mapas dejaron de usarse ampliamente. Advierte que una ruta antigua podía perder o entregar mal el correo. El texto quedó como Internet-Draft, de modo que documenta una decisión operativa y no una norma adoptada.

Ahí está la última función de una cartografía fiable: declarar su propia muerte. Un fichero conservado no es un registro vivo si nadie acepta cambios, resuelve disputas o garantiza una fecha de frescura.

La tecnología contemporánea automatiza muchas observaciones. No automatiza la responsabilidad. Toda plataforma que promete descubrir rutas debe contestar las mismas preguntas que el trabajo de Horton hizo visibles: quién declara el enlace, quién paga sus consecuencias y quién puede decir que el mapa ya no debe gobernar el tráfico.

Fuentes

  1. Wikimedia Commons: retrato de Mary Ann Horton en 2012
  2. Conclusión del UUCP Mapping Project, Internet-Draft
  3. Perfil de UC Berkeley EECS
  4. Mary Ann Horton: logros
  5. Mary Ann Horton: historia de Internet
  6. Stargate Internet Museum: el proyecto UUCP
  7. Stargate Internet Museum: UUCP y correo
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton: What Is a Domain?
  10. RFC 1036: intercambio de mensajes USENET
  11. RFC 819: convención de nombres de dominio
  12. RFC 850: intercambio de mensajes USENET
  13. RFC 920: requisitos de los dominios
  14. RFC 974: correo y sistema de dominios
  15. RFC 976: formato de intercambio de correo UUCP
  16. Entrevista de USENIX con Mary Ann Horton