Résumé

  • Pour la RFC 2157, une conversion décrivait un sens ; l’équivalence exigeait deux conversions qui, ensemble, ramenaient le corps sans perte.
  • L’encapsulation pouvait conserver le format d’origine pour une passerelle ultérieure tout en restant opaque au système intermédiaire.
  • Une copie d’octets, un nom de fichier convaincant ou une première conversion réussie ne démontrait donc ni le bon type, ni un retour fidèle, ni un usage réel chez le destinataire.

Deux flèches, pas un simple synonyme

La RFC 2157, publiée en janvier 1998, complétait MIXER en traitant les corps de messages échangés entre X.400 et MIME. Là où la RFC 2156 organisait l’interfonctionnement général des passerelles, ce texte descendait au niveau du contenu : texte, pièces jointes, messages transférés, structures multiparties et objets signés ou chiffrés.

Son glossaire posait une frontière formelle. Une « mapping » était la règle transformant un corps X.400 en corps MIME, ou l’inverse. Une équivalence était l’ensemble de deux règles qui, prises ensemble, réalisaient une conversion sans perte. Le premier résultat pouvait être visible après une seule opération. Le second exigeait de refermer la boucle.

Cette différence change la manière d’évaluer une démonstration. Obtenir un corps X.400 valide à partir d’une entité MIME ne dit rien, à lui seul, de la règle choisie au retour. Une autre passerelle peut ne pas posséder la conversion inverse, préférer un autre type ou perdre des paramètres que la première avait déplacés. Un feu vert de syntaxe prouve une sortie acceptable, pas l’identité de la composition.

L’encapsulation organisait la garde, pas la compréhension

La troisième relation définie par le texte était l’encapsulation. Elle enveloppait un objet d’un système afin de le transporter dans l’autre. Le système intermédiaire n’était pas censé en tirer un sens raisonnable ; une passerelle ramenant l’objet dans son monde d’origine devait pouvoir restaurer son format sans perte.

Cette opacité n’était pas un accident. Une enveloppe FTBP ou BP15 pouvait retenir les en-têtes, paramètres et octets canoniques de MIME. Réciproquement, application/x400-bp pouvait faire traverser MIME à un corps X.400 étendu. La valeur était la continuité de garde vers un décapsuleur identifié, non une promesse d’affichage ou d’édition à l’étape intermédiaire.

La RFC décrivait aussi un passage par BP14 qui n’offrait pas cette garantie. Les en-têtes MIME disparaissaient, l’encodage de transfert était défait et seul le flux d’octets restait. Aucune traduction inverse ne reconstituait le type MIME ; au retour, l’objet devenait application/octet-stream. Le transport avait sauvé une matière, pas son mode d’emploi.

Le nom pouvait orienter sans devenir une preuve

Dans un univers où les deux familles de messagerie évoluaient encore, la RFC laissait une marge de décision importante. La passerelle pouvait tenir compte des capacités du destinataire, d’une représentation demandée par l’expéditeur, des limites du prochain saut ou d’indices tirés du contenu et du nom de fichier. Face à BP14, à un fichier FTAM générique ou à application/octet-stream, regarder l’extension pouvait aider à choisir une conversion.

Mais l’indice restait local. Le texte expliquait aussi comment un filename de Content-Disposition devenait un chemin FTBP, puis prenait /etc/passwd comme exemple d’une chaîne exigeant les précautions normales du système de fichiers. Le caractère transmis ne commandait pas le disque du destinataire et ne certifiait pas le type du contenu.

Le cas application/octet-stream révèle mieux encore cette prudence. Une passerelle MIXER devait savoir utiliser deux cibles : le corps X.400 BilaterallyDefined, hérité des systèmes de 1984, et la pièce jointe FTBP inconnue. Elle devait également permettre de configurer le choix. La première voie supprimait les paramètres MIME ; la seconde transportait davantage de métadonnées de fichier et copiait les octets dans les deux sens.

Ces deux chemins pouvaient chacun produire une sortie valide. Ils n’offraient pourtant pas les mêmes invariants. La disparition du paramètre padding pouvait modifier l’interprétation du dernier octet. Le type de disposition était ignoré puis recréé comme attachment. Un champ MIME récent pouvait n’avoir aucun emplacement dans le corps X.400 choisi. La réussite locale d’un choix ne transformait pas les deux chemins en équivalents interchangeables.

Le registre décrivait un accord reproductible

Le registre d’équivalences demandait le nom du type MIME, l’identité précise du corps X.400, les identifiants d’objet et syntaxes ASN.1 nécessaires, les algorithmes de conversion et l’effet des interdictions de conversion avec ou sans perte. La description devait permettre une mise en œuvre indépendante.

Cet enregistrement visait l’uniformité. Il ne créait pas une obligation universelle : une passerelle n’avait pas à offrir toutes les conversions enregistrées, et une conversion locale n’avait pas forcément à figurer au registre. La ligne publique attestait donc une règle disponible et révisable. Elle n’attestait ni son installation, ni sa sélection pour un message précis, ni l’action du logiciel destinataire.

Les tables elles-mêmes associaient certains types à des couples définis — IA5Text, GeneralText, images, messages transférés et fichiers génériques — tandis que d’autres renvoyaient à l’encapsulation. Les contenus signés et chiffrés demandaient une attention particulière : modifier leur structure pour les rendre « lisibles » pouvait détruire la propriété que le corps était censé préserver.

La preuve utile suit l’objet jusqu’au retour

Un test sérieux fige d’abord les octets, en-têtes, paramètres et niveau d’imbrication de l’entrée. Il enregistre la configuration de la table, les capacités ou indices ayant conduit au choix, puis la sortie et tout élément conservé, déplacé ou supprimé. Il applique ensuite la règle inverse nommée et compare le résultat au corps initial.

Même un aller-retour parfait à ce niveau ne prouve pas l’usage. L’agent du destinataire peut ne pas disposer du lecteur nécessaire. Le nom peut être dangereux dans l’espace local. Un objet chiffré peut demeurer opaque par conception. Livraison, présentation sûre et compréhension humaine restent des observations ultérieures.

La primauté du code exécuté de Lu Heng fournit ici une grille éditoriale : une table définit une possibilité, tandis que l’exécution et la comparaison produisent le constat. La spécification initiale minimale incite à standardiser le couple réversible sans nationaliser les politiques de réception. Les couches de réalité empêchent enfin le registre, le code présent, la règle sélectionnée, les octets restaurés et le résultat humain de se servir mutuellement de certificat.

La leçon de la RFC 2157 est donc plus exigeante qu’un slogan d’interopérabilité. Une flèche prouvait une conversion. L’équivalence demandait la seconde flèche et le retour sans perte. L’encapsulation assumait que conserver et comprendre pouvaient être deux services différents.

Sources