Résumé

  • La RFC 2158 reliait JPEG et GIF à des noms de parties de corps, des OID, des types MIME et des octets transmis sans conversion ; ces éléments se corroborent sans être interchangeables.
  • Sa sous-section FTAM EMA GIF imprime image/jpeg, alors que le titre, le nom de la partie et l’OID gif-image(4) désignent GIF.
  • Une reprise erronée du texte JPEG est l’explication la plus probable, mais le registre de la RFC Editor ne contient actuellement aucun erratum pour la RFC 2158 ; le document ne prouve pas non plus ce qu’une passerelle déployée a réellement fait.

Une entrée contredisait sa propre chaîne d’identité

La RFC 2158, publiée en janvier 1998, tient en quelques pages. Elle décrit deux chemins pour transporter des images entre MIME et X.400. Le premier définit des parties de corps étendues : mime-jpeg-body sous { mixer-bp-data 3 } et mime-gif-body sous { mixer-bp-data 4 }, sans paramètres. Le second documente des identifiants de pièces jointes FTAM attribués par l’Electronic Messaging Association.

Trois entrées suivent une logique régulière. La partie étendue JPEG correspond à image/jpeg; FTAM EMA JPEG porte aussi image/jpeg et un OID se terminant par jpeg-image(6); la partie étendue GIF correspond à image/gif. La quatrième porte le titre « image/gif - FTAM EMA GIF », nomme FTAM EMA GIF et donne un OID qui finit par gif-image(4). Entre ces repères, pourtant, elle imprime MIME Content-Type: image/jpeg, puis appelle cet OID celui de JPEG.

Ce n’est donc pas une ambiguïté fabriquée par une lecture contemporaine. Les identifiants d’une seule entrée ne peuvent pas être vrais ensemble : trois désignent GIF, tandis qu’un champ et un substantif repris de la section précédente désignent JPEG.

« Sans conversion » rendait l’étiquette décisive

Chaque correspondance de la RFC 2158 annonce Conversion: None. La passerelle n’était pas chargée de décoder un format raster pour en encoder un autre ; elle devait associer une représentation X.400 à un type MIME tout en conservant les octets. Une étiquette JPEG ne transforme donc pas des octets GIF, pas plus qu’une branche d’OID nommée GIF ne transforme des octets JPEG.

La RFC 2046 fixe la frontière pertinente : sous le type principal image, le sous-type identifie le format précis. Le registre IANA des types de média conserve des entrées distinctes pour image/gif et image/jpeg. Un récepteur peut choisir son décodeur à partir de ce champ, mais ce champ demeure une affirmation sur les octets. La sélection du bon tableau, la continuité du hachage et le succès du décodage sont trois observations différentes.

La RFC 2157, texte compagnon, renforce la structure environnante : ses tableaux associent mime-jpeg-body à image/jpeg et mime-gif-body à image/gif. Elle n’amende pas silencieusement la RFC 2158, mais montre pourquoi un implémenteur devait comparer plusieurs identifiants.

La correction évidente reste une inférence

La lecture la mieux étayée est que la section FTAM EMA GIF aurait dû indiquer image/gif et parler d’un OID attribué à GIF. Le titre, le nom de partie, la feuille d’OID et les entrées voisines convergent. Le brouillon MIXER antérieur associe lui aussi la partie étendue GIF à image/gif, mais il précède l’ajout des sous-sections FTAM et ne contient donc pas une version corrigée de la ligne litigieuse.

L’enquête doit s’arrêter à cette limite. La recherche d’errata de la RFC Editor ne renvoie actuellement aucune entrée pour la RFC 2158. Dire « coquille probable » est une analyse appuyée ; dire « correction officielle » dépasserait les preuves disponibles.

Ce silence ne révèle pas non plus les déploiements. Un éditeur de passerelle a pu suivre littéralement le champ MIME, privilégier le titre et l’OID, importer une correction privée, reconnaître la signature des octets, ou ne jamais implémenter cette voie FTAM.

Une ligne normative ne témoigne pas pour le logiciel

Pour établir le comportement d’une passerelle, il faut la version du tableau de correspondance, l’identifiant de partie X.400, l’OID complet, le champ MIME d’entrée, les octets et leurs hachages, le champ de sortie, le gestionnaire choisi et le résultat du décodage. Un hachage inchangé prouve une continuité binaire à l’étape observée, non la justesse du libellé. Un affichage réussi prouve qu’un gestionnaire a accepté l’objet, non que tous les destinataires feront le même choix.

La règle éditoriale est simple : document, implémentation et résultat observé sont des couches susceptibles de s’aligner, mais aucune ne peut emprunter la preuve des autres. La RFC 2158 ne rend pas les libellés inutiles. Elle montre plutôt que l’identité d’un format est une affirmation jointe : lorsque les champs se contredisent, il faut les réconcilier avant de laisser l’étiquette parler au nom des octets ou du code.

Sources