Résumé

  • Les premiers travaux FTP d’Abhay Bhushan cherchaient une manière commune d’agir sur des systèmes de fichiers incompatibles, pas un système de fichiers universel.
  • Le questionnaire sur les hôtes et l’atelier de 1972 ont rendu visibles les conventions qui résistaient à l’unification, notamment les noms de chemin et les règles d’accès.
  • Un refus explicite d’une combinaison impossible pouvait servir l’interopérabilité mieux qu’une acceptation de façade.

Le nom que le réseau ne pouvait pas choisir

Un nom de fichier appartient toujours à quelqu’un. Dans un réseau contemporain, cette évidence est masquée par des conventions devenues familières. Sur ARPANET, elle sautait aux yeux : chaque machine organisait ses fichiers, ses comptes et ses droits à sa manière. Le protocole pouvait demander à un hôte de livrer un objet ; il ne pouvait pas décider à sa place comment cet objet devait être nommé.

C’est à cet endroit que le travail d’Abhay Bhushan devient plus intéressant qu’une simple généalogie de FTP. Il ne s’agissait pas d’accumuler des commandes jusqu’à obtenir une norme. Il fallait déterminer la surface exacte sur laquelle des systèmes profondément différents pouvaient se comprendre. L’interface serait uniforme dans ses actes, tout en reconnaissant que certains noms et certaines autorités resteraient du côté de l’hôte distant.

L’Internet Hall of Fame présente Bhushan comme l’auteur de la première spécification de FTP, rédigée pendant ses années au Project MAC du MIT, de 1967 à 1974, et lui attribue plus de vingt RFC. Les textes techniques donnent du relief à cette notice : on y voit un rédacteur de protocole qui organise également la collecte des besoins, convoque les participants et conserve la trace des désaccords.

Une spécification qui commence par une enquête

Dans le RFC 114 d’avril 1971, Bhushan distingue l’usage direct d’un hôte distant d’un usage indirect, confié à un processus intermédiaire capable de masquer une partie des commandes et conventions étrangères. Il qualifie pourtant sa proposition de première ébauche. L’interface uniforme est encore un objectif. Pour l’éprouver, il faut connaître les besoins et capacités des hôtes du réseau.

Cette chronologie inverse la tentation habituelle. On ne définit pas d’abord une abstraction parfaite en obligeant ensuite la réalité à s’y conformer. On inventorie la réalité pour savoir quelle abstraction sera honnête. Efficacité, extensibilité, adaptation, reprise après erreur et indépendance à l’égard d’une application particulière comptent parmi les critères, mais aucun ne suffit à effacer la diversité existante.

Le RFC 180 transforme ce principe en questionnaire. Le sous-comité y précise qu’il n’entend pas encore normaliser les conventions de nommage ni celles du contrôle d’accès. L’utilisateur d’un hôte distant doit donc en connaître les usages. Bhushan demande à Alex McKenzie de recueillir auprès des représentants des hôtes les formes légales de noms, les valeurs implicites, les opérations sur les répertoires, les restrictions d’accès et les représentations de fichiers disponibles.

Ce document administratif en apparence remplit une fonction architecturale. Il force chaque système à expliciter ce qu’un protocole générique risquerait de prendre pour une vérité universelle. La compatibilité commence alors non par l’effacement des écarts, mais par leur description comparable.

L’utilité d’un projet abandonné

Le RFC 309 annonce en 1972 un atelier consacré au transfert de données et de fichiers. Les participants intéressés sont invités, les contributions écrites sont sollicitées et une séance de travail doit réviser le protocole selon les besoins présents et futurs. Bhushan ouvre donc le texte à l’expérience des applications et des machines, au lieu de rechercher une approbation formelle d’un projet déjà figé.

Les notes du RFC 327 préservent le résultat le plus fécond : tout n’a pas été résolu. L’idée d’une « image virtuelle de fichier réseau », susceptible de représenter davantage de structure en commun, est discutée sans produire d’accord et mise de côté pour le moment. Restent des objectifs plus circonscrits : conserver l’intégrité des données, préciser leur représentation et leur interprétation, transporter autant de structure qu’il est raisonnablement possible, et garder un système de fichiers virtuel comme horizon plus lointain.

L’atelier arrête aussi des choix immédiatement exploitables. Les commandes doivent être imprimables ; les connexions de contrôle et de données doivent être séparées ; un socle de représentations doit être disponible. Surtout, un serveur incapable d’accepter une structure demandée doit le dire et rejeter la demande. Bhushan est chargé de consigner les débats et de préparer la nouvelle version.

Le projet virtuel non adopté n’est donc pas un échec caché. Il dessine la frontière de l’accord réel. Le protocole avance parce qu’il distingue ce que le groupe sait rendre commun de ce qu’il n’est pas encore prêt à uniformiser.

Des verbes communs, des noms locaux

Le RFC 171 sépare un mécanisme général de transfert des fonctions propres aux applications, afin d’éviter la multiplication de solutions particulières. Le RFC 172 promet de protéger l’utilisateur des variations entre hôtes dans la mesure du possible, autorise des sous-ensembles ainsi que des extensions convenues entre parties, et maintient le nommage des chemins dans le domaine du site.

La répartition devient nette. Le protocole définit des verbes — récupérer, stocker, énumérer — et négocie des paramètres de représentation, de structure ou de mode. Le substantif sur lequel porte le verbe, lui, reste formulé dans la langue locale de l’hôte. Un slash, un numéro de génération ou un nom qualifié par un compte n’a pas la même portée partout. Les règles qui autorisent l’accès à cet objet ne sont pas davantage transférées au protocole.

Le RFC 354 formalise ce compromis borné. La conversation de contrôle sélectionne représentation, type et mode. Un serveur n’est pas tenu d’accepter toutes les combinaisons ni toutes les tailles d’octet ; il doit en revanche informer l’utilisateur de ce qu’il ne sait pas faire. L’interopérabilité inclut ainsi une réponse négative disciplinée.

Ce point est décisif. Un refus précis permet au logiciel de modifier sa demande ou d’expliquer l’échec. Une conversion silencieuse peut livrer un fichier dont le sens a changé tout en affichant une réussite. La limite visible est donc une fonction du protocole, pas une lacune de documentation.

Une frontière qui a permis le déploiement

Le FTP mûr du RFC 959 de 1985 témoigne d’une longue évolution. Il serait trompeur de projeter rétrospectivement tous ses choix sur les textes de 1971 et 1972. Leur valeur tient justement à la séquence : une première proposition, une enquête, un atelier ouvert, un accord plus étroit et une nouvelle spécification.

Cette méthode a permis à des hôtes différents d’échanger avant d’avoir résolu l’ensemble de leurs différences. Elle a aussi déplacé une part de complexité vers les clients, qui devaient connaître les conventions distantes, et vers les extensions qui se sont accumulées. Mais exiger un modèle universel complet aurait probablement retardé toute utilisation réelle ou inscrit dans la norme le modèle du système dominant.

Le nom de chemin marque donc le lieu où l’interface cesse de parler au nom de tous. Le réseau transporte une opération ; l’hôte de destination conserve le pouvoir de définir l’objet et les conditions de son accès. La leçon d’Abhay Bhushan est une leçon de mesure : une norme devient solide non seulement par ce qu’elle unifie, mais par la précision avec laquelle elle déclare ce qu’elle laisse local.

Sources