Résumé

  • FTP a fini par imposer des octets de huit bits sur la connexion de données sans imposer la même taille à l’unité logique du fichier. TYPE L déclarait cette seconde taille.
  • Le destinataire pouvait adapter le stockage à sa machine, mais sa transformation devait être réversible et publiée. L’identité n’était promise que pour un dépôt et une reprise effectués avec les mêmes paramètres.
  • TYPE I transportait une suite de bits contigus ; TYPE L ajoutait des frontières interprétables. Ni l’enregistrement IANA ni une réponse positive ne prouvent une prise en charge universelle ou un usage actuel.

Tous les bits, mais plus la mesure

Un fichier ancien peut survivre matériellement et devenir pourtant indécidable. S’il contient 72 bits, on peut les lire comme neuf unités de huit bits, huit unités de neuf bits ou deux unités de trente-six bits. Les trois découpages préservent exactement la même suite. Aucun contrôle calculé sur cette suite ne choisit à lui seul le bon.

RFC 765 puis RFC 959 donnent un exemple sans ambiguïté : deux hôtes à mots de trente-six bits peuvent employer TYPE L 36. Deux mots forment 72 bits et occupent donc neuf octets de transmission. La limite du premier mot traverse le cinquième octet transmis ; elle n’est pas visible dans le découpage ordinaire de la connexion.

Le réseau garantit ici un véhicule commun. Il ne transforme pas chaque compartiment du véhicule en unité native du fichier. Conserver neuf octets sans conserver L 36 revient à garder une route exacte tout en jetant la légende qui permettait de la lire.

Le premier FTP exposait la diversité au lieu de la cacher

En 1971, RFC 114 proposait un catalogue de descripteurs bien plus large que l’opposition moderne entre texte et binaire. Il distinguait plusieurs formes d’ASCII, EBCDIC, SIXBIT, des entiers codés selon différentes conventions, ainsi que des flottants propres à l’IBM 360 ou au PDP-10. Certains entiers recevaient une taille explicite comprise entre un et 255 bits.

L’information de type était interprétative. Un hôte qui l’acceptait pouvait convertir les données vers une représentation interne adaptée. Une machine à mots de trente-six bits ne rangeait pas nécessairement de la même façon cinq caractères ASCII de sept bits, quatre caractères de huit ou neuf bits, et six caractères SIXBIT.

Ce catalogue n’est pas le langage de commande de RFC 959 et ne doit pas être présenté comme tel. Il révèle cependant la contrainte historique. Le réseau reliait des machines dont le mot, le caractère et le nombre n’avaient pas une géométrie commune. Une simple suite fiable de bits ne suffisait pas toujours à produire un fichier utilisable après réception.

Quand la taille de l’octet de transport était encore négociable

RFC 354, en 1972, séparait déjà le type de représentation de la taille choisie pour la connexion de données. Pour ASCII et certains formats d’impression, la taille était fixée à huit bits. Pour Image et Local Byte, un autre choix restait possible.

Le serveur n’était pas obligé d’accepter toutes les tailles. Il pouvait mettre en œuvre celles qu’il traitait efficacement, avec une recommandation minimale pour huit bits. La diversité interne devenait ainsi une diversité de la surface de transport : un client devait connaître non seulement la nature du fichier, mais aussi la largeur que les deux extrémités pouvaient réellement porter.

La transformation Local Byte dépendait de cette largeur et de l’hôte récepteur. Elle devait être réversible et suffisamment publiée pour que l’utilisateur sache ce que le site avait fait. La responsabilité de mémoriser type et taille ne disparaissait pas après la fermeture de la connexion.

Huit bits sur le fil, sans décret sur le fichier

RFC 765 a réduit cette surface : l’octet de transmission est désormais toujours long de huit bits. RFC 959 maintient la distinction en toutes lettres. FTP connaît la taille logique servant à interpréter le fichier et la taille utilisée pour transmettre les données. Cette dernière vaut huit bits ; aucune des deux ne doit être confondue automatiquement avec le mot physique employé par le système de stockage.

La simplification aurait pu supprimer tous les objets non alignés sur huit. Elle a choisi autre chose. TYPE L prend obligatoirement un second paramètre décimal, la taille de l’octet logique. Il n’existe pas de valeur par défaut, car l’absence de cette information rendrait le découpage arbitraire.

Les octets logiques sont empaquetés sans interruption, même lorsque leur frontière coupe un octet de transmission. Le fil n’ajoute pas un séparateur tous les huit bits. Il livre une suite ; les extrémités connaissent la largeur qui permet de reconstituer les unités.

Neuf octets ne deviennent pas neuf objets

Dans TYPE L 36, les quatre premiers octets transmis ne contiennent que 32 des 36 bits du premier objet. Les quatre bits suivants arrivent au début du cinquième octet ; les quatre bits restants de ce même octet appartiennent déjà au second objet. Celui-ci se poursuit jusqu’au neuvième.

Une passerelle peut donc recopier chaque octet à la perfection et détruire néanmoins le fichier si elle réaligne chaque groupe sur une frontière de huit bits. À l’inverse, un flux qui traverse des paquets TCP différents ne change pas de signification : le paquet, le segment et l’octet de transmission ne sont pas les unités logiques déclarées.

Le paramètre ne dit pas non plus comment interpréter les trente-six bits. Il ne normalise ni le signe, ni l’exposant d’un flottant, ni l’ordre interne d’un nombre, ni la sémantique d’une instruction. Il fournit une frontière, pas un dictionnaire complet.

Le remplissage est une dette de fin, non un séparateur

Quand la longueur totale n’achève pas un octet de transmission, les spécifications permettent le remplissage nécessaire à la fin. Elles ne permettent pas d’insérer des zéros après chaque unité logique pour arranger la mémoire du récepteur.

Cette position est essentielle à la réversibilité. Des zéros intercalés peuvent être impossibles à distinguer de données authentiques. À la fin d’un fichier ou d’un enregistrement, le récepteur peut utiliser le terme de la structure et les paramètres actifs pour identifier ce qui complète le dernier octet.

La présence d’une longue série de zéros dans une capture ne prouve donc rien, isolément. Il faut savoir où se trouve la fin, quel type était actif et quelle taille logique avait été acceptée. Sans ces éléments, l’observateur voit le contenant de huit bits, pas la dette de remplissage.

La machine destinataire garde le choix du meuble

RFC 959 imagine un expéditeur de valeurs logiques de trente-six bits et un destinataire organisé en mots de trente-deux bits. Celui-ci peut placer chaque valeur dans un double mot de soixante-quatre bits afin de la manipuler facilement. L’espace inutilisé appartient à son organisation locale ; il n’est pas injecté dans le fichier transmis.

Cette autonomie n’est acceptable que si la conversion peut être inversée. Le site doit pouvoir restituer le fichier identique lorsque les mêmes paramètres sont employés. Il devrait en outre rendre publique sa méthode, afin que le propriétaire sache comment les objets existent dans le système local.

L’engagement est conditionnel. Stocker en TYPE L 36 et demander ensuite TYPE L 8 ne bénéficie pas d’une promesse générale d’identité. Une archive qui conserve les bits mais oublie le type, la largeur et la version de conversion a perdu une partie de la provenance nécessaire à la reprise.

Image et Local ne portent pas la même affirmation

Le type Image traite les données comme des bits contigus, empaquetés dans les octets de transmission. Le stockage peut exiger un alignement de fin ; les zéros ajoutés doivent alors être identifiables et supprimables lors d’une récupération. FTP ne demande pas à Image de nommer chaque unité interne.

Local ajoute cette unité. La largeur déclarée autorise le récepteur à organiser les données suivant des objets manipulables sur sa machine. Dans certains cas, le résultat est équivalent à Image. Sur une machine à octets de huit bits, TYPE L 8 et TYPE I ont le même effet ; entre deux machines à mots de m bits, TYPE L m devrait également produire le même effet qu’Image.

L’équivalence d’un résultat ne rend pas les preuves interchangeables. Image dit « préserve cette suite ». Local dit aussi « voici la frontière que tu peux employer pour une transformation réversible ». Deviner cette frontière dans un flux Image serait une décision d’application, pas une permission fournie par FTP.

RFC 1123 a fixé un plancher étroit

RFC 1123 exige qu’un programme FTP accepte TYPE I et TYPE L 8. Une machine dont la mémoire est organisée en mots de m bits, lorsque m n’est pas multiple de huit, peut également prendre en charge TYPE L m.

Le mot « peut » empêche une généralisation abusive. La syntaxe sait exprimer 36 ; elle ne contraint pas chaque serveur à l’accepter. Une réponse de refus prouve une limite de représentation pour cette session, non une panne de réseau, un manque de disque ou une corruption du fichier.

Le client peut choisir Image, effectuer lui-même une conversion vers un format commun ou renoncer. Il ne peut pas remplacer silencieusement L 36 par L 8 puis annoncer que l’intention d’origine a été respectée.

ALLO compte dans une unité définie ailleurs

La commande ALLO pouvait annoncer un besoin de stockage en octets logiques. Elle ne définissait pas leur largeur ; elle héritait de la représentation active. Le récent article consacré à ALLO étudiait la modestie de cette annonce : même une réponse positive pouvait ne correspondre à aucune réservation physique.

Le présent mécanisme est différent. TYPE L définit ce que signifie une unité dans la suite de bits. ALLO emploie éventuellement cette unité pour exprimer une estimation. Une quantité correcte peut ne rien réserver, et une réservation suffisante peut recevoir une représentation mal découpée. Les deux succès doivent rester séparés.

Un registre de commande n’est pas un inventaire de capacités

Le registre IANA des commandes et extensions FTP conserve TYPE comme commande de représentation et renvoie à la spécification. Il permet de retrouver le nom et son autorité documentaire.

Il ne dit pas quelles largeurs un serveur accepte, comment il les range, ni combien de transferts contemporains les utilisent. Entre la présence au registre et un aller-retour identique se trouvent l’implémentation, l’acceptation de session et la transformation locale. Chacune exige sa propre observation.

Ce que le fil a choisi de ne pas définir devait être conservé ailleurs

L’évolution de FTP n’a pas uniformisé les machines. Elle a réduit le noyau commun : un transport par octets de huit bits, auquel les extrémités pouvaient ajouter une largeur logique explicite. Le réseau transportait sans avoir à comprendre PDP-10, Multics ou le meuble de stockage du destinataire.

Cette modestie déplace la responsabilité. Plus le fil refuse de donner un sens global, plus les extrémités doivent conserver le paramètre qui rend leur transformation vérifiable. Un fichier de neuf octets peut être parfaitement intact et néanmoins incomplet comme preuve si personne ne sait plus qu’il contenait deux unités de trente-six bits.

Sources et limites

L’analyse repose sur RFC 114, RFC 354, RFC 765, RFC 959, RFC 1123 et le registre IANA. Ces textes établissent une architecture historique et des obligations normatives ; ils ne mesurent ni le déploiement actuel, ni le comportement d’un produit donné, ni la signification applicative d’une valeur de trente-six bits.