Résumé

  • RFC 2160 conservait deux représentations X.400 de PostScript : un Extended Body Part sans paramètres, identifié par mime-postscript-body, et un FTAM Body Part reconnu par id-mime-ftbp-postscript dans son environnement de transfert.
  • Les deux mappages vers application/postscript étaient déclarés sans conversion. Cette propriété concernait le flux d’octets, pas l’identité de son enveloppe, l’adoption de FTAM, la politique de l’interpréteur ou la page obtenue.

Un document peut arriver intact et rester inutilisable. Il suffit que l’armoire d’arrivée ne reconnaisse pas le coffret qui le contient. Cette image est plus fidèle à RFC 2160 qu’une simple flèche « X.400 vers MIME ».

Publié en janvier 1998, RFC 2160 traitait une transition concrète. Le monde X.400 disposait déjà d’une représentation PostScript héritée de RFC 1494. Le nouveau cadre de transfert de fichiers offrait une autre représentation, que le document recommandait sans effacer immédiatement l’ancienne.

Deux identités observables

Dans l’Extended Body Part, les données formaient un OCTET STRING sans paramètres. L’OID mime-postscript-body appartenait à { mixer-bp-data 2 }. Dans le FTAM Body Part, l’identité se trouvait ailleurs : FileTransferParameters.environment.application-reference devait prendre la valeur id-mime-ftbp-postscript, sous { mixer-bp-data 6 }.

Un logiciel ne pouvait donc pas déduire le second format du seul contenu. Il devait connaître la structure qui portait le flux. La recommandation FTAM indiquait une préférence de conception ; elle n’attestait ni le choix réel de la passerelle, ni la prise en charge chez le correspondant. Le maintien de l’ancien type reconnaissait précisément que les installations ne migrent pas toutes au même instant.

RFC 2157 sépare les Extended Body Parts, FTAM et leurs règles d’identification. RFC 2156 expose le projet plus large de MIXER : rendre les passerelles cohérentes, éviter la perte d’information et viser la réversibilité lorsqu’elle est praticable. Un objectif de conception ne remplace toutefois jamais une trace d’exécution.

La formule « aucune conversion »

Pour chaque représentation, RFC 2160 associait le type X.400 à application/postscript et inscrivait « Conversion Type: No conversion ». Les deux côtés contenaient un seul flux d’octets ; il pouvait être copié directement, sans autre donnée à transformer.

Cette phrase mérite d’être lue littéralement. Elle permet de vérifier une propriété du payload. Deux empreintes identiques avant et après la passerelle montrent que le programme n’a pas été réécrit. Elles ne montrent pas que la passerelle a choisi FTAM plutôt que l’ancien EBP, ni que le destinataire savait ouvrir la forme choisie.

Il faut donc conserver deux preuves : le flux et le support. Sans l’objet X.400 original ou au moins son type et son identifiant, une archive réduite au seul PostScript ne peut plus reconstruire le chemin de représentation.

Reconnaître PostScript n’est pas l’exécuter correctement

RFC 2160 renvoyait à RFC 1521 pour application/postscript. RFC 2046 précise ensuite que ce média transporte un programme PostScript et recommande fortement les conventions de structuration DSC. Sans elles, un système ne peut pas vérifier à l’avance si le document fonctionnera dans son environnement ; un refus peut être raisonnable.

Le même texte détaille des risques d’exécution : opérations sur les fichiers, état persistant de l’interpréteur, paramètres système, extensions non standard, code machine et consommation sans limite des ressources. Une politique sûre peut neutraliser des opérateurs ou refuser l’affichage. Dans ce cas, l’absence de page ne contredit pas l’intégrité des octets ; elle prouve que deux contrôles différents ont été exercés.

La fiche RFC Editor et la fiche Datatracker situent le document ; la recherche d’errata ne renvoie actuellement aucune entrée. Aucune de ces fiches ne mesure un déploiement ni une compatibilité produit.

Une chaîne de preuves, pas un verdict unique

Une exploitation sérieuse conserve séparément l’empreinte du flux, le type X.400, l’OID exact, la décision de capacité du destinataire, la classification MIME, la politique de l’interpréteur et le résultat visible. L’arrivée, la reconnaissance, l’autorisation d’exécuter et le rendu sont des événements différents.

Le cadre de Heng Lu sur la spécification initiale minimale aide à maintenir la règle commune au bon niveau : identifiants et copie déterministe. La primauté du code exécuté demande d’observer ce que les systèmes adoptent réellement. Enfin, les couches de réalité empêchent de transformer une étiquette ou une empreinte en preuve d’un résultat utilisateur.

RFC 2160 ne promettait pas trop. Il réglait proprement le transport d’un flux. C’est l’opérateur qui promet trop lorsqu’il fait de cette réussite une preuve générale d’interopérabilité.

Sources