Résumé

  • RFC 784 décrivait un répartiteur de courrier TOPS20 capable de choisir, selon l’hôte destinataire, MTP sur TCP, MTP sur NCP, l’ancien FTP sur NCP ou un circuit particulier.
  • RFC 785 fixait une interface à deux fichiers : l’un conservait le texte, l’autre les chemins du destinataire et l’état des livraisons. Quand un circuit attendait, la feuille de contrôle changeait sans multiplier la lettre.

Une lettre envoyée à quatre personnes devrait demander une lettre et quatre adresses. Certains anciens systèmes de courrier fabriquaient quatre copies du texte. Suzanne Sluizer et Jon Postel ont proposé, en juillet 1981, de laisser le texte tranquille. Leur RFC 784 consacrée à l’implémentation MTP sur TOPS20 à l’ISI plaçait le message dans un fichier et les instructions de livraison dans un autre. La paperasse devenait un dispositif technique, et pour une fois elle simplifiait le travail.

Le courrier avait alors plusieurs chemins possibles. L’implémentation en préparation, écrite en BLISS-10, devait envoyer et recevoir par TCP comme par l’ancien NCP, tout en dialoguant avec d’autres mécanismes de messagerie. Des programmes de rédaction et des récepteurs de réseau créaient des fichiers; un répartiteur de fond les distribuait aux canaux de sortie. Une version appelée par l’utilisateur pouvait essayer tout de suite si le canal nécessaire était libre. Un tableau indiquait pour chaque hôte s’il acceptait MTP sur TCP, MTP sur NCP ou FTP sur NCP.

Un autre consignait les cas particuliers, notamment les envois vers des hôtes anglais par un système de l’UCL. Quatre destinataires ne prenaient donc pas forcément le même carrefour.

Dans ce bureau de tri, le fichier de contrôle portait les chemins et un pointeur vers le fichier contenant le courrier, avec son en-tête RFC 733. Le répartiteur pouvait marquer les destinataires déjà servis et garder ceux dont le canal restait indisponible. Le contenu du message se lisait pour chaque tentative; le fichier finissait par être renommé ou supprimé selon le traitement local. C’était la liste de travail qui devait changer. Réécrire la lettre parce qu’une route était fermée aurait été une drôle de manière de gérer l’attente.

La RFC 785 sur la définition des fichiers montre la mécanique ligne par ligne. FILE: désignait le fichier du message, FROM: donnait le chemin de l’expéditeur et chaque TO: ajoutait un destinataire. Le second fichier contenait en-tête et corps. Les auteurs comparaient ce couple aux anciens programmes qui produisaient N copies du texte pour N adresses dans les champs To, Cc et Bcc. Leur interface créait deux fichiers quelle que soit la longueur de la liste. L’enveloppe de routage gardait son propre compte, séparé des phrases rédigées par l’expéditeur.

La liaison à un système voisin avait aussi sa notice. La RFC 786 expliquait l’échange de fichiers entre MTP et NIMAIL, avec des exemples de conversion entre une adresse à signes pour cent et un chemin MTP. Un courrier pouvait traverser des conventions d’adresse aussi différentes que ses canaux de transport. Le répartiteur devait choisir la bonne route, puis présenter le bon libellé à la prochaine machine.

Sluizer et Postel décrivaient un travail en cours. Ils énuméraient les récepteurs et expéditeurs qu’ils construisaient, les programmes qu’ils espéraient voir adaptés par d’autres et les tableaux à créer. La RFC 784 livrait un plan précis; RFC 785 en fixait l’interface de fichiers. Le résultat le plus parlant de cette architecture était déjà là : la progression d’une adresse pouvait être notée indépendamment de la progression de ses voisines.

La scène ressemble à un bureau de poste doté d’un excellent classeur. Une lettre reste sur la table. À côté, une fiche indique qui attend encore et par quelle porte sortir. En 1981, ces portes s’appelaient TCP, NCP ou FTP sur NCP. Si l’une fermait, sa ligne restait sur la fiche pendant que les autres colis avançaient. Les mots du message avaient enfin le droit de ne pas participer à chaque changement d’itinéraire.