Résumé

  • STRU P décrivait les fichiers discontinus comme des pages indépendantes indexées ; l’indice donnait la place logique dans le fichier, pas l’ordre d’arrivée.
  • Une entrée vide de la table des pages n’était pas envoyée et ne devait pas être confondue avec une page existante dont les données valaient zéro.
  • Conçue surtout pour TOPS-20 et NLS, la structure de pages fut ensuite déconseillée en général, mais RFC 1123 imposa son format commun dès qu’un transfert de fichier troué ou à accès direct en avait réellement besoin.

Le silence avait une adresse

Dans un flux ordinaire, une portion absente ressemble à un défaut. Avec la structure de pages définie par RFC 959, une absence pouvait au contraire avoir une position exacte. Chaque unité annonçait un Page Index, c’est-à-dire un numéro logique dans la carte du fichier. Le texte précise qu’il ne s’agit pas d’un numéro de séquence de transmission.

Deux pages pouvaient donc arriver l’une après l’autre tout en laissant une position logique vide entre elles. L’annexe consacrée à TOPS-20 écarte l’ambiguïté : les pages vides, ou trous, n’étaient tout simplement pas envoyées, et un trou n’était pas la même chose qu’une page de zéros.

Cette phrase distingue deux états que de nombreux formats modernes continuent à mélanger. Une page présente porte une allocation et un contenu, même si tous ses mots valent zéro. Un trou affirme qu’aucune page n’occupe cette place dans la carte source. Produire des zéros pour combler le second cas n’est pas forcément restituer ; c’est matérialiser quelque chose qui n’existait pas.

Le fichier n’était pas toujours une suite d’octets

FTP proposait trois structures. STRU F, valeur par défaut, considérait le fichier comme une suite continue d’octets de données. STRU R conservait une succession d’enregistrements. STRU P conservait des pages indépendantes indexées.

Ces structures ne se confondaient ni avec TYPE, qui fixait la représentation logique, ni avec MODE, qui encadrait la transmission sur la connexion de données. Les paramètres interagissaient, mais chacun portait une partie distincte du contrat.

La diversité des machines l’exigeait. RFC 959 oppose le mainframe IBM, où un fichier source pouvait vivre en enregistrements de longueur fixe, à TOPS-20, où les applications voyaient souvent un flux de caractères découpé en lignes. Pour qu’un fichier reste utile après son passage, le récepteur devait connaître l’hypothèse structurelle de l’émetteur.

Une transformation locale était possible. Mais elle devait être réversible : un hôte orienté flux recevant des enregistrements pouvait les convertir, à condition de pouvoir restituer le même fichier lors d’une récupération ultérieure sous la même structure. RFC 1123 reprit cette exigence en demandant une inversion aussi complète que possible sans rendre le résultat inutilisable localement.

Un en-tête qui séparait position et contenu

Chaque page transportée avait un en-tête. Quatre champs au minimum en exprimaient la longueur, l’indice logique, la longueur des données et le type. Leur unité était l’octet logique défini par TYPE, et non une largeur supposée universelle de la machine réceptrice.

Le type empêchait une longueur nulle de devenir un sens universel. Une Last Page terminait la transmission avec un en-tête minimal et aucune donnée. Une Simple Page portait une page ordinaire. Une Descriptor Page pouvait décrire le fichier entier. Une Access Controlled Page ajoutait un champ de contrôle associé à la page.

Ainsi, « zéro donnée » pouvait signaler une fin explicite, tandis qu’un indice omis représentait un trou. Une page de description et une page de données ne répondaient pas à la même question. La reconstruction dépendait de l’ensemble type, indice et longueur, pas d’une simple concaténation des charges utiles.

L’empreinte de TOPS-20 et de NLS

RFC 765, puis RFC 959, disent d’où venait le besoin : principalement des transferts efficaces entre systèmes TOPS-20, notamment pour les fichiers de NLS.

Un fichier disque TOPS-20 réunissait un chemin, une table de pages, un ensemble de pages éventuellement vide et des attributs. Une entrée de table pouvait rester EMPTY ou pointer vers une page ; les entrées occupées pouvaient aussi porter des bits d’accès propres à cette page. Les attributs du fichier comprenaient notamment des dates, la taille de l’octet, un pointeur de fin et des compteurs.

La table n’avait aucune obligation d’être compacte. Des cases vides pouvaient séparer des pages présentes. Le pointeur de fin de fichier, lui, était un nombre qui ne devait pas nécessairement désigner la dernière donnée. Les fichiers NLS exploitaient précisément ces deux possibilités.

Le cas documenté utilisait TYPE L 36, STRU P, MODE S. Les champs de l’en-tête avaient donc la largeur d’un mot TOPS-20 de 36 bits. Un indice indiquait la position dans la carte ; une page de description transportait les informations globales ; une page de données pouvait porter ses bits d’accès.

Le but n’était pas de transformer tous les hôtes en TOPS-20. Il s’agissait de ne pas effacer la structure utile d’un système sous prétexte que l’autre ne la stockait pas naturellement.

Trois manières de transporter moins

L’annexe décrit aussi des zéros finaux supprimés à l’intérieur d’une page existante : Data Length pouvait être réduit sous la taille habituelle. Ce cas ne se confondait ni avec le trou omis ni avec une page complète de valeurs nulles.

Les trois situations diminuent ce que l’on observe sur la connexion. Pourtant leurs cartes de fichier diffèrent. Un trou signifie qu’une position n’a pas de page. Une page nulle affirme qu’une page existe. Une page raccourcie affirme qu’elle existe avec une étendue de données transmise plus petite selon la règle prévue.

Un hachage des seules charges utiles ne suffit donc pas à prouver la fidélité du résultat. Il faut conserver les indices, les types, les longueurs, les descripteurs, les champs de contrôle et la règle de transformation. Sinon deux structures différentes peuvent produire des suites de données étonnamment proches.

Les RFC ne promettent pas qu’un système cible matérialise les trous comme TOPS-20, qu’un trou se lise toujours comme zéro ni que des droits par page soient applicables partout. FTP fournissait une représentation ; le mappage local restait à justifier.

Déconseiller sans privatiser

RFC 1123 adopta une position nuancée. La mise en œuvre de la structure paginée n’était pas recommandée en général. Sa spécialisation ne devait pas alourdir le noyau commun de tous les hôtes.

Mais si un système avait besoin d’échanger par FTP des fichiers à accès direct ou troués, il devait employer le format défini, et non inventer un format FTP privé. La rareté autorisait l’absence de prise en charge ; elle n’autorisait pas une sémantique incompatible sous le même protocole.

La structure de fichier restait obligatoire. La structure d’enregistrements n’était requise que pour les hôtes dont le système de fichiers la supportait, même si un autre pouvait accepter STRU R en enregistrant littéralement le flux. La structure de pages demeurait optionnelle. Exiger le verbe STRU ne revenait donc pas à promettre tous ses arguments.

Ce que le registre ne dit pas

RFC 5797 a classé STRU parmi les commandes de base obligatoires. Le registre IANA des commandes et extensions FTP le conserve comme commande de paramétrage « File Structure » référencée à RFC 959.

Cette inscription coordonne un nom et une fonction. Elle ne prouve pas qu’un serveur accepte P, qu’un client sait restituer la carte TOPS-20, que les contrôles par page seront conservés ni que la fonction est déployée aujourd’hui.

Une ligne présente dans un registre n’est pas une capacité présente sur un serveur. Et une page absente du transfert n’était pas, par magie, une page de zéros présente dans le fichier.

Le coût de remplir une absence

Les systèmes actuels confondent encore absent, nul, inconnu, masqué et sans objet pour simplifier un schéma. Ils obtiennent un fichier valide, parfois plus coûteux et souvent moins fidèle.

La discipline héritée de STRU P est plus sobre : donner un nom à l’absence, dissocier la place logique de l’ordre d’arrivée, transporter les métadonnées nécessaires, déclarer les conversions et tester leur retour.

La page manquante était une information. La remplir ne réparait pas le fichier ; cela en fabriquait un autre.

Sources