Résumé

  • La RFC 913 proposait trois types de représentation pour son Simple File Transfer Protocol. Pour une page TOPS-20 de 512 mots de 36 bits, ses exemples donnent 2 560 octets en ASCII, 2 048 en Binary et 2 304 en Continuous.
  • Binary prélève quatre octets dans chaque mot et laisse les quatre derniers bits; Continuous franchit les frontières entre mots et transmet toute la séquence. Le message « transfert terminé » ne tranche donc pas la question du contenu reçu.

Le logiciel félicite l'utilisateur : le fichier est arrivé. Reste à savoir ce qu'il appelle « le fichier ». Mark Lottor a mis cette question sous les yeux des lecteurs de la RFC 913, en septembre 1984. Son SFTP était un protocole simple proposé sur le port TCP 115, distinct de l'outil SSH qui portera plus tard les mêmes initiales. L'idée était de faire davantage que TFTP sans reprendre toute la puissance de FTP : une seule connexion TCP, avec transfert, contrôle d'accès et opérations sur les répertoires. Une petite commande, TYPE, décidait pourtant de la matière expédiée.

Le cas TOPS-20 rend le piège mesurable. Son mot a 36 bits; la page du document contient 512 mots, donc 18 432 bits. Le mode ASCII lit cinq caractères de sept bits par mot. Il emploie 35 bits, laisse le dernier de côté, transporte les caractères dans des octets dont le bit de tête vaut zéro et convertit les fins de ligne locales en CRLF selon NETASCII. Cinq caractères pour chacun des 512 mots : 2 560 octets transmis. Le destinataire reçoit du texte préparé pour l'échange, avec les conventions de texte qui vont avec. Il ne reçoit pas une copie bit pour bit de la page en mémoire.

Le mode Binary semble promettre cette copie. Dans la RFC, il prend quatre groupes de huit bits par mot de 36 : 32 bits partent, les bits 32 à 35 ne partent pas. La même page descend alors à 2 048 octets. Cela ne prouve pas qu'un fichier précis ait été abîmé : ces quatre bits peuvent être sans intérêt selon la manière dont le fichier a été stocké. Cela prouve que le mot « binaire » désigne ici des unités de huit bits, pas la conservation automatique de chaque bit du mot d'origine. L'étiquette rassurante cache un choix de découpage.

Continuous refuse de faire du mot une frontière sacrée. On déroule les bits à la suite. Après quatre octets pris dans le premier mot, ses quatre derniers bits se marient aux quatre premiers bits du deuxième. La séquence complète des 512 mots représente 18 432 bits, soit 2 304 octets de huit bits. Si la machine travaille déjà avec des mots dont la largeur est divisible par huit, la RFC prévoit que Binary et Continuous se comportent pareil. Sur TOPS-20, ils répondent à des demandes différentes. L'un extrait des octets de chaque mot; l'autre conserve la suite entière des bits.

Le récepteur devra encore savoir quoi faire de cette suite, mais aucune fin de mot n'aura été jetée par la représentation de transfert.

Le reste du protocole donne à ce réglage un poids pratique. Les commandes sont quatre lettres ASCII suivies d'un octet nul. Le type par défaut est Binary. Avant de manipuler les fichiers, le serveur peut demander identité, compte et mot de passe. Il sait lister ou changer de répertoire, renommer, supprimer, lire et écrire. Un transfert peut donc suivre un parcours normal, répondre positivement et produire un fichier d'une taille surprenante si l'opérateur n'a pas choisi le mode adapté aux mots de sa machine. La réussite de la connexion et la fidélité de la représentation sont deux constats séparés.

La notice du RFC Editor classe aujourd'hui ce texte comme historique. Les trois tailles sont des calculs de la proposition, pas un relevé de pertes chez des utilisateurs. Pourtant, elles suffisent à faire tomber un réflexe : « reçu » ne dit pas encore « identique ». Entre le disque, le fil et le disque d'arrivée, quelqu'un décide ce qu'est un caractère, un octet, un mot et une page. La RFC a laissé cette décision à un petit menu. Quatre bits pouvaient y rester à la maison sans que le réseau s'en plaigne.