Résumé

  • La table commune ARPANET–DCNET comptait déjà plus de 400 noms et surnoms en 1981. Mills proposait de les répartir en domaines plutôt que de demander à chaque hôte de connaître tous les autres.
  • Un même ordinateur pouvait servir de relais pour COMSAT et INTELPOST. Mills@HOST pouvait alors désigner deux boîtes différentes; l’adresse de l’ordinateur ne disait pas quel domaine devait recevoir la réponse. Le nom complet et le trajet de retour devaient conserver ce contexte.

Sur deux bureaux, deux fiches portent Mills@HOST. Le préposé les rassemble derrière un seul guichet. La première lettre arrive sans problème; au moment de répondre, il cherche la couleur de la pile d’origine. D. L. Mills a construit ce casse-tête technique dans sa RFC 799 de septembre 1981. Il partait d’un constat plus large : les tables réunies de l’ARPANET et de DCNET avaient déjà dépassé 400 noms et surnoms. Le grand répertoire unique grinçait. Découper le répertoire en domaines ne suffisait pourtant pas si le courrier perdait en route l’indication du bon dossier.

Les domaines proposés pouvaient correspondre à ARPA, UCL ou COMSAT, se chevaucher et laisser des adresses hors de leur couverture. Mills analysait un seul niveau de domaines. Le nom complet d’une boîte, <user>.<host>@<domain>, suggérait tout de même une hiérarchie de trois éléments. Dans COMSAT, Mills@COMSAT-DLM pouvait être clair. Hors de ce domaine, Mills.COMSAT-DLM@COMSAT indiquait aussi de quelle administration locale relevait le nom. Deux domaines pouvaient employer le même surnom sans provoquer d’erreur, à condition que le domaine l’accompagne au moment utile.

Chaque domaine aurait un ou plusieurs processus de réexpédition du courrier. Le réexpéditeur tiendrait la liste des hôtes de son domaine et l’adresse d’au moins un réexpéditeur pour chaque autre domaine. Les hôtes ordinaires garderaient ces points de contact et, selon leurs besoins, quelques noms de plus. Un hôte pouvait appartenir à plusieurs domaines, avoir plusieurs adresses Internet ou faire fonctionner plusieurs processus de réexpédition. Les choix locaux n’étaient pas interdits; il fallait simplement que la frontière sache dans quel contexte les interpréter.

La présence de ces guichets n’obligeait pas tous les messages à passer par eux. Mills prévoyait que la majorité du courrier irait directement de l’hôte expéditeur à l’hôte destinataire. Un relais intermédiaire servait si les deux n’étaient pas connectés en même temps, si l’expéditeur ne pouvait pas résoudre le nom, si une liaison directe rencontrait des contraintes réglementaires, économiques ou de sécurité, ou si les deux côtés employaient des transports différents, par exemple TCP et NCP. Un simple relais pouvait stocker puis transmettre sans posséder l’ensemble des tables de noms d’un réexpéditeur.

Cette distinction gardait le carnet compliqué sur un nombre limité de bureaux.

Mills donne deux itinéraires : MRCP to:<@COMSAT,Mills@HOST> et MRCP to:<@INTELPOST,Mills@HOST>. Ils peuvent mener à deux boîtes distinctes, même si les deux réexpéditeurs tournent sur la même machine. Supposons que celle-ci se nomme FORWARDER dans les deux domaines. MRCP to:<@FORWARDER,Mills@HOST> perd alors le renseignement décisif. L’adresse Internet de la machine ne le restitue pas : elle désigne l’ordinateur, pas le rôle COMSAT ou INTELPOST joué pour ce message. Une réponse construite à partir de cette adresse arrive au guichet avec la même énigme.

Mills voulait donc une adresse de boîte complète quand un trajet traversait les domaines. Il relevait aussi un défaut dans la pratique décrite par RFC 780 : le destinataire devait construire un nom de retour à partir de l’adresse Internet de l’hôte qui lui avait remis le message. Si cet hôte était le guichet commun, le nom obtenu oubliait le domaine. L’expéditeur devait actualiser à la fois l’itinéraire du destinataire et celui de l’expéditeur, en recopiant la première entrée de l’itinéraire reçu vers le début du trajet de retour. Le reçu devait garder le nom du bon comptoir.

Restait à accueillir les anciens systèmes de courrier. Mills déconseillait de modifier les en-têtes RFC 733 à chaque étape : l’opération était intrusive et demandait trop d’analyse. Pour les hôtes ARPANET existants, il situait la conversion à l’entrée du système de courrier Internet. Un nom local <anything>@<host> devenait <anything>.<host>@ARPA; un <anything>@<domain> déjà reconnu gardait sa forme. Là, on savait encore d’où venait le raccourci, et les réponses ultérieures pouvaient s’appuyer sur une adresse explicite.

Le texte finit en invitant à discuter. Il présentait une proposition, avec ses choix et ses questions ouvertes. Sa découverte la plus nette ne dépend pourtant d’aucune adoption ultérieure : l’adresse unique d’une machine ne suffit pas à identifier la boîte qu’un de ses nombreux rôles représente. Le répertoire plat avait plus de 400 entrées; un seul guichet partagé montrait pourquoi le vrai problème se cachait dans le chemin du retour.