Résumé

  • Mary Ann Horton a contribué à organiser le UUCP Mapping Project : des administrateurs déclaraient leurs voisins, des bénévoles entretenaient des cartes régionales et chaque site calculait ensuite ses propres itinéraires.
  • Cette histoire montre qu’une carte de réseau est un engagement de maintenance, de coût et de responsabilité, non une image neutre que les câbles produisent d’eux-mêmes.

Au début des années 1980, une adresse UUCP pouvait ressembler à duke!research!ucbvax!user. Les points d’exclamation formaient un itinéraire. Le message entier attendait, était appelé par une autre machine, puis repartait. Si un relais cessait d’appeler, si un nom était ambigu ou si la facture devenait insupportable, l’adresse correcte sur le papier ne suffisait plus.

Le travail de Mary Ann Horton se situe dans cet écart entre connexion et service. Elle n’a pas inventé UUCP ni le programme de calcul pathalias. Elle a aidé une communauté à rendre les liaisons déclarables, révisables et utilisables par des logiciels.

La facture derrière chaque arête

Dans son entretien avec USENIX, Horton explique que les universités limitaient parfois les appels interurbains tandis que certains sites de Bell Labs absorbaient des dépenses importantes. Un lien n’avait donc pas le même sens pour les deux extrémités. Il fallait savoir qui appelait, à quelle fréquence, à quelle vitesse et avec quelle fiabilité.

Horton distribuait des cartes logiques d’Usenet lors des conférences de 1982 et 1983. Les utilisateurs s’en servaient pour le courrier, alors que le graphe de diffusion des nouvelles et le réseau UUCP de messagerie étaient différents. Une carte incomplète pouvait ignorer une liaison utile et concentrer la charge sur les sites les plus coopératifs.

En 1984, la représentation était devenue trop ramifiée pour tenir dans un dessin réellement opératoire. Une carte géographique et un document logique de huit pages ont suivi. Mais multiplier les pages ne répondait pas à la question essentielle : qui collecte les changements entre deux éditions ?

Transformer des déclarations locales en bien commun

Une rencontre informelle à USENIX, en janvier 1984 à Washington, a donné une forme au UUCP Mapping Project. Des bénévoles ont pris en charge des régions, recueilli les descriptions de sites, corrigé les contradictions et publié les fichiers dans comp.mail.maps.

Les chiffres de participation doivent rester datés. Le musée Stargate évoque plus de trente volontaires recrutés à la réunion initiale. La page d’accomplissements de Horton parle d’une équipe d’environ cinquante personnes. D’autres rétrospectives englobent un cercle régional plus large. Il ne s’agit pas de trois estimations du même instant.

Les sources nuancent aussi la direction du projet. Horton raconte avoir convoqué la réunion et conduit sa création. Un projet de conclusion rédigé en 2000 attribue la direction initiale sous financement USENIX à Karen Summers-Horton, puis l’exploitation par Horton à partir de 1985. Cette divergence interdit le portrait d’une fondatrice solitaire. L’infrastructure décisive était précisément collective.

RFC 850 fixait déjà une limite de divulgation. Sa commande senduuname pouvait fournir la liste des voisins UUCP destinée aux cartes. L’administrateur pouvait éditer la réponse. Numéros de téléphone et mots de passe devaient rester hors du fichier public. Il fallait publier assez de topologie pour acheminer, mais pas les secrets permettant de composer ou de s’authentifier.

Le « meilleur » chemin n’était pas une vérité mathématique

Steve Bellovin et Peter Honeyman ont conçu pathalias. Le programme lisait un graphe orienté dont chaque arête portait un coût et un opérateur de routage, puis pré-calculait depuis le site local un chemin de coût minimal vers les destinations connues.

Leur article démonte lui-même l’apparente objectivité du résultat. Le coût pouvait représenter le prix de l’appel, la fréquence de connexion, la vitesse ou la fiabilité. Le barème a été ajusté pour retrouver les préférences d’opérateurs expérimentés. Les délais de composition et d’attente entre deux appels comptaient parfois davantage que le débit affiché.

La donnée d’entrée posait autant de problèmes que l’algorithme. Les déclarations pouvaient être contradictoires, erronées ou périmées. Des cartes déduites d’Usenet sous-estimaient la connectivité. pathalias inférait parfois un retour pour rendre un hôte accessible et appliquait des heuristiques aux domaines. Un chemin minimal était donc une décision locale issue d’un savoir imparfait.

Avec Adam Buchsbaum, Horton a travaillé à smail, qui utilisait les tables produites pour acheminer le courrier. La répartition des fonctions était élégante : la communauté publiait les possibilités ; chaque site les évaluait ; le logiciel exécutait ; les administrateurs payaient et réparaient.

Séparer le nom de l’itinéraire

Dans « What Is a Domain? », Horton insiste sur un point souvent oublié : les points d’un domaine ne sont pas des étapes de routage. Le domaine donne un nom absolu dans une hiérarchie administrative. Une table, un résolveur ou une passerelle doit encore choisir le prochain saut.

RFC 819 rattache le domaine à une juridiction de nommage et à une responsabilité de traduction. RFC 920 affirme qu’un domaine n’a pas besoin d’une topologie, d’un protocole, d’un matériel ou même d’une géographie commune. Le nom rend l’organisation durable malgré les changements de liens.

Selon le récit rétrospectif de Horton, le projet UUCP a participé avec BITNET, CSNET et la communauté ARPANET à l’espace de noms commun de 1986. Sa page d’accomplissements évoque plus de 150 organisations UNIX sans connexion Internet directe ayant reçu un service de courrier en .com ou .edu entre 1986 et 1988. Ce total est une déclaration de l’auteure, pas un recensement indépendant.

RFC 976 décrit le mécanisme de compatibilité. Plutôt que créer un format supplémentaire, il adopte les domaines de RFC 920 et le courrier de RFC 822, distingue plusieurs classes d’hôtes et impose davantage de capacités aux passerelles. Derrière user@domain, la route UUCP demeure, mais l’utilisateur n’a plus à la porter.

RFC 974 confie ensuite au DNS une indirection de messagerie via les enregistrements MX. Un administrateur peut modifier les préférences pour contourner un hôte défaillant. La simplicité du nom correspond donc à un déplacement du travail vers un plan de contrôle partagé.

Savoir retirer une carte

Le projet de conclusion de 2000 indique que la base a été gelée en août, les cartes n’étant plus largement utilisées. Il avertit qu’une donnée ancienne peut perdre ou mal livrer du courrier. Ce texte est resté un Internet-Draft : il documente la décision du projet, pas une norme adoptée.

La leçon dépasse UUCP. Une carte est fiable tant que des personnes identifiées acceptent les mises à jour, arbitrent les incohérences, publient un état frais et annoncent la fin de service. Conserver le fichier sans conserver cette institution transforme discrètement un outil de routage en archive.

Les systèmes actuels découvrent des routes plus vite. Ils n’échappent pas à la question que Horton a contribué à rendre visible : qui affirme la liaison, qui en supporte le coût, et qui a l’autorité de dire que la carte ne doit plus guider personne ?

Sources

  1. Wikimedia Commons : portrait de Mary Ann Horton en 2012
  2. Conclusion du UUCP Mapping Project, Internet-Draft
  3. Portrait par UC Berkeley EECS
  4. Mary Ann Horton : accomplissements
  5. Mary Ann Horton : histoire d’Internet
  6. Stargate Internet Museum : le projet UUCP
  7. Stargate Internet Museum : UUCP et le courrier
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton : What Is a Domain?
  10. RFC 1036 : échanges de messages USENET
  11. RFC 819 : convention de nommage des domaines
  12. RFC 850 : échanges de messages USENET
  13. RFC 920 : exigences relatives aux domaines
  14. RFC 974 : routage du courrier et DNS
  15. RFC 976 : format d’échange du courrier UUCP
  16. Entretien USENIX avec Mary Ann Horton