Résumé

  • Le mode COMPRESSED distinguait les données ordinaires, la répétition d’un octet quelconque et le remplissage propre à la représentation.
  • Seul le remplissage omettait la valeur : TYPE fournissait un espace en ASCII/EBCDIC et un octet nul en Image/Local byte.
  • Une capture MODE C privée du dialogue de paramètres peut être exacte au bit près et néanmoins insuffisante pour reconstruire le fichier.

L’absence était la syntaxe attendue

Le premier indice tient dans les deux bits de tête. Avec 11, les six bits restants donnent le nombre d’octets de remplissage. Rien ne suit : un seul octet encodé peut développer toute la suite.

RFC 765 puis RFC 959 réservent une autre forme aux répétitions ordinaires. La classe 10 porte une longueur sur six bits et exige ensuite l’octet d à répéter. Une série de caractères arbitraires possède donc son modèle explicite ; le remplissage en est dispensé.

Cette séparation empêche de diagnostiquer la troncature au seul regard d’une longueur. Après 10, l’absence du modèle est un défaut. Après 11, consommer l’octet suivant comme modèle décale tout le flux. Le parseur doit d’abord savoir quelle promesse le descripteur fait.

Le TYPE terminait la phrase

Pour la représentation ASCII, le remplissage est l’espace de code 32. En EBCDIC, c’est l’espace de code 64. En Image ou Local byte, le destinataire produit un octet nul.

Le même descripteur peut donc donner une rangée d’espaces ou une rangée de zéros. Les octets reçus ne changent pas ; seul change l’état de représentation accepté sur la connexion de contrôle. Le mode apporte le verbe « répéter » et le nombre, tandis que le TYPE fournit le complément d’objet.

RFC 959 qualifie généralement représentation et transmission d’indépendantes, avant de nommer précisément cette exception. En COMPRESSED, la nature du remplissage dépend du type. Lire MODE C comme un codec autonome efface la règle qui rend sa forme la plus courte décodable.

Trois économies, trois contrats

Une chaîne ordinaire commence par un bit nul et une longueur positive sur sept bits, jusqu’à 127 ; les n octets qui suivent sont littéraux. La répétition utilise 10, une longueur plus courte et une valeur explicite. Le remplissage utilise 11, la longueur seule.

Ce n’est pas uniquement une classification par fréquence. Une série de zéros en ASCII n’est pas automatiquement le remplissage privilégié de cette représentation : celui-ci est l’espace. À l’inverse, Image peut produire des zéros sans en transporter un seul comme échantillon. L’admissibilité d’une forme vient d’un sens négocié en amont.

Les informations de contrôle empruntent encore une autre voie : un octet d’échappement nul suivi d’un descripteur reprend les codes du mode BLOCK. Avant tout stockage, le destinataire doit donc départager littéral, réplication, remplissage implicite et contrôle.

Les blancs des imprimantes avaient un prix

RFC 959 présente ce mode comme un échange entre bande passante et un peu de calcul. Les gros fichiers d’impression, notamment ceux des hôtes RJE, devaient en tirer le meilleur parti. Des zones entières réservées à la mise en page pouvaient contenir le même espace.

Accorder à l’espace textuel une représentation d’un octet répondait à cette réalité. Accorder le même privilège au zéro pour Image et Local byte répondait à une autre convention d’absence. La compression gagnait parce que le TYPE avait déjà réduit les possibilités.

Mais l’économie déplaçait une partie de l’objet hors de la connexion de données. Un collecteur qui gardait seulement celle-ci perdait la table de remplissage. Un journal réécrivant TYPE A en TYPE I sans toucher au flux pouvait modifier la reconstruction future. Un outil exigeant une valeur après chaque longueur rejetait une forme parfaitement valide.

Chaque négociation ouvrait une époque de décodage

TYPE, STRU et MODE sont des paramètres acceptés par commandes et réponses. La preuve utile relie chaque transfert à l’état effectivement accepté, non à la seule intention du client. Si le TYPE change avant le transfert suivant, le même octet de remplissage change de résultat.

Il faut donc conserver le dialogue de contrôle, les limites du transfert, l’état initial et terminal du parseur et les deux empreintes—flux encodé et objet décodé. Un hachage de paquet répond à « qu’a-t-on capturé ? », pas à « quel fichier ce contexte produisait-il ? ».

Le registre ne testait pas l’argument C

RFC 959 attribue S, B et C, mais choisit Stream comme mode par défaut. RFC 1123 resserre ensuite le minimum obligatoire autour de Stream. La conception de MODE C appartient donc bien au standard sans autoriser une affirmation d’universalité, hier comme aujourd’hui.

RFC 5797 et le registre IANA maintiennent MODE parmi les commandes de base. Ils coordonnent le nom et sa référence. Ils ne prouvent ni l’acceptation de C, ni la justesse du parseur, ni la conservation après stockage.

Garder l’encodage et la restitution

Une trace défendable associe le flux brut, sa longueur et son empreinte à la chronologie TYPE/STRU/MODE, aux classes et longueurs décodées, aux contrôles, à l’état final et à l’empreinte canonique du fichier produit. Elle distingue remplissage et réplication explicite même lorsqu’ils aboutissent fortuitement aux mêmes octets.

Les canaris rejouent un descripteur de remplissage sous ASCII, EBCDIC, Image et Local byte ; placent à côté une répétition arbitraire ; découpent descripteur et modèle entre deux lectures ; et ferment après un 10 privé de sa valeur. Les frontières de tampon n’ont aucun pouvoir syntaxique.

L’émetteur n’envoyait pas l’octet parce que la session l’avait déjà nommé. L’économie de FTP reste intelligible si l’on conserve avec les données l’état auquel elles empruntaient leur sens.

Sources