Résumé

  • La RFC 1 répartissait le problème : BBN avait défini le logiciel des IMP, tandis qu’aux groupes des hôtes revenait l’accord sur les logiciels permettant à leurs ordinateurs d’utiliser le réseau.
  • Steve Crocker présentait ses propositions comme provisoires et attendait des réactions. La RFC 3 expliqua ensuite que les lecteurs pouvaient confondre un texte publié avec une décision faisant autorité, alors que la série voulait justement faciliter la discussion d’idées encore peu abouties.
  • Les modifications consignées dans la RFC 6, l’implémentation GORDO de l’UCLA décrite par la RFC 11 et les révisions signalées dans la RFC 33 témoignent d’un processus en cours. Elles ne prouvent pas que toutes les machines aient repris la RFC 1 sans changement.

L’accord manquant se situait au-dessus du réseau de paquets

Le premier réseau ARPA reposait sur une séparation technique et institutionnelle. Bolt, Beranek and Newman avait spécifié les IMP, les machines qui acheminaient les messages entre les sites. Restait à définir, pour les ordinateurs qui leur étaient raccordés, les conventions nécessaires à l’ouverture des connexions, au choix des liens et au traitement des données reçues à distance.

Datée du 7 avril 1969, la RFC 1 de Steve Crocker mettait ce problème hôte à hôte dans un document commun. Elle résumait le format des messages des IMP et esquissait les logiciels hôtes : demandes de connexion, sessions proches du télétype, transferts de fichiers plus volumineux, contrôle d’erreurs et échanges interactifs. Elle envisageait aussi une interface locale capable de répondre immédiatement à certaines actions sans transmettre chaque frappe sur le réseau.

Cette architecture n’était pas décidée d’un seul bloc. L’acheminement par les IMP et le comportement logiciel des hôtes relevaient de responsabilités différentes. Un message pouvait parvenir au bon IMP sans que les deux systèmes d’exploitation sachent encore comment ouvrir une session ou interpréter les échanges.

L’introduction de Crocker est explicite : le groupe avait conclu quelques accords provisoires, rencontré des questions ouvertes et rien de ce qui suivait n’était très ferme. La note vaut aussi par ce qu’elle laisse incertain. La lire comme une spécification achevée ferait disparaître la phase de travail qu’elle documente.

Ce que la première note mettait à l’essai

La RFC 1 organisait les communications autour de liens logiques reliant deux hôtes. Elle proposait d’en réserver un au contrôle entre systèmes d’exploitation et d’utiliser les autres pour les sessions des utilisateurs. Une connexion pouvait imiter une ligne de télétype ; une connexion parallèle adaptée aux fichiers aurait permis des transferts plus lourds sans les mécanismes de tamponnement et d’interruption propres au terminal.

Le texte cherchait aussi à rendre le travail à distance plus réactif malgré le délai du réseau. Il proposait d’envoyer une petite interface locale, écrite dans un langage alors appelé DEL, afin de traiter près de l’utilisateur les réactions ordinaires du terminal. Cette idée était encore discutée ; la note ne dit pas qu’elle était déjà installée sur tous les hôtes.

Les expériences initiales étaient tout aussi circonscrites. Crocker décrivait les travaux du SRI sur un système de consultation et une interface DEL, puis un usage envisagé avec l’UCLA et Utah. Cela indique ce que les participants tentaient de construire. Ce n’est ni un registre d’installation pour chaque site, ni la preuve que les quatre premiers hôtes avaient mis en œuvre toutes les propositions.

La première RFC célèbre n’est donc pas un ordre émis par une autorité de normalisation. Elle offrait un support commun pour exposer des choix, solliciter des corrections et donner à un groupe réparti entre plusieurs sites un objet concret de discussion.

Une série conçue pour rendre le désaccord visible

Deux jours après la RFC 1, Bill Duvall publia la RFC 2, elle aussi intitulée « Host Software ». La RFC 3 fixa ensuite quelques conventions documentaires : toute personne d’un site pouvait produire une note ; la rapidité comptait davantage que la finition ; le titre n’avait pas à être unique. Bill Duvall, au SRI, attribuait les numéros de série.

La RFC 3 nomma également un risque toujours familier dans la gouvernance technique : le lecteur peut considérer un texte comme faisant autorité parce qu’il est écrit et publié. La souplesse du format visait au contraire à faciliter l’échange d’idées encore dépourvues d’autorité. Le numéro permettait de retrouver une note ; il ne tranchait pas la question qu’elle soulevait.

Il ne s’agissait pas d’un processus de normalisation achevé en miniature. Les premières notes mêlaient propositions, questions, détails d’implémentation et demandes de réponse. Leur utilité commune venait du fait qu’elles rendaient le raisonnement technique visible entre des sites qui devaient interopérer tout en conservant leurs propres ordinateurs et systèmes d’exploitation.

Révision et implémentation n’apportent pas les mêmes preuves

La RFC 6, compte rendu de Crocker sur une conversation avec Bob Kahn le 10 avril, consigne un changement du champ de lien Host–IMP : celui-ci était passé à cinq bits, auxquels s’ajoutait un bit signalant la conversion. Le détail est limité, mais le calendrier est parlant : quelques jours après la RFC 1, un de ses éléments était encore discuté et modifié.

En août, la RFC 11 de Gerard Deloche décrivit les procédures hôte à hôte et leur implémentation dans GORDO, le système en temps partagé de l’UCLA sur SDS Sigma 7. Elle précisait les types de connexion, les messages de contrôle, les sommes de contrôle, les tampons et les programmes reliant les utilisateurs à l’interface IMP. La RFC 13, publiée le même mois, renvoyait à la RFC 11 et proposait un message de longueur nulle pour marquer la fin d’un transfert de fichier sur une connexion auxiliaire.

Ces documents montrent des idées devenues plus concrètes dans une implémentation nommée, puis une proposition ciblée en réponse à un besoin. Ils ne démontrent pas que tous les hôtes aient repris les procédures de GORDO ni que le réseau ait cessé d’évoluer. Une implémentation opérationnelle est une preuve plus forte qu’une simple proposition pour un site donné ; elle ne révèle toutefois pas combien de sites l’ont adoptée.

La RFC 33 rend cette distinction explicite. En février 1970, elle signale de nombreux changements par rapport à l’ancien protocole de la RFC 11, les rattache à une réunion de réseau en décembre et précise que le document joint ne suffit pas encore à écrire un Network Control Program. Elle sollicite des réponses. Les connexions existaient et le réseau était utilisé, mais le protocole hôte restait en révision et en cours de documentation.

Pourquoi la première RFC compte sans être le dernier mot

L’importance historique de la RFC 1 ne tient pas au fait que chaque champ ou procédure serait devenu permanent. Elle a rendu discutable un problème de conception partagé avant que toutes les machines disposent d’une implémentation stabilisée. Elle identifiait les responsabilités, avançait des options et rendait les incertitudes lisibles.

C’est un accomplissement différent du déploiement d’un protocole. Un texte peut cadrer un problème commun ; une révision peut réduire un désaccord ; du code peut montrer qu’un système fonctionne ; des échanges répétés peuvent démontrer que des systèmes indépendants donnent le même sens aux messages. Ces étapes se répondent, mais aucune ne certifie la suivante.

Les premières archives étayent donc un récit plus précis de la coordination. BBN spécifiait la couche IMP. Les groupes d’hôtes travaillaient aux logiciels qui la surplombaient. Les RFC fournissaient un espace de discussion portable et numéroté. Les implémentations et les notes ultérieures indiquaient ce qui avait été essayé ou modifié. Le premier numéro a ouvert ce travail ; il ne l’a pas achevé.

Sources

La RFC 1 est la source principale de la proposition provisoire de Crocker. La RFC 2 consigne la note de Bill Duvall intitulée « Host Software » ; la RFC 3 expose les premières conventions documentaires. La RFC 6 rapporte une discussion ultérieure sur l’interface Host–IMP. La RFC 11 de Deloche décrit les procédures et leur implémentation GORDO ; la RFC 13 de Cerf propose un marqueur de fin pour les transferts auxiliaires. La RFC 33 de Crocker et ses collègues documente les changements ultérieurs et les incertitudes persistantes. L’index RFC 170 de 1971 catalogue les premières notes avec leurs dates.