Résumé

  • La RFC 2049 rendait l’ignorance prévisible : un agent conforme n’avait pas à connaître chaque sous-type d’un système ouvert.
  • Un codage de transfert inconnu, un charset inconnu ou un type non textuel inconnu devait descendre vers application/octet-stream, sans afficher les octets bruts comme du texte.
  • Le mot « safe » ne certifiait ni fichier, ni auteur, ni intégrité : il visait le passage dans les systèmes RFC 821/822 conformes connus et l’absence d’affichage textuel accidentel.

Une règle commune pour ce que le logiciel ne savait pas

Un registre extensible dépasse nécessairement les logiciels déjà installés. Exiger tous les sous-types aurait rendu la conformité périssable ; ne rien prescrire aurait laissé chaque client imprimer, exécuter ou deviner différemment les mêmes données.

La RFC 2049 a donc défini un plancher. L’agent devait produire MIME-Version: 1.0, reconnaître Content-Transfer-Encoding, décoder quoted-printable et base64 et distinguer 7bit, 8bit et binary. Si le transport sous-jacent ne portait pas 8bit ou binary, l’émetteur devait encoder et étiqueter correctement. L’étiquette indiquait une opération à inverser ; elle ne prouvait pas que les octets avaient survécu.

Lorsqu’un Content-Transfer-Encoding était inconnu, le type déclaré ne pouvait plus sauver l’interprétation : l’entité entière devait être traitée comme application/octet-stream. Il fallait d’abord obtenir la séquence d’octets, puis seulement juger son type.

L’erratum EID 5470 précise le sujet implicite de la phrase, « une entité MIME avec » un codage inconnu. Son statut est Held for Document Update : c’est une clarification enregistrée, pas un remplacement silencieux du texte publié.

La famille supérieure ne donnait qu’un indice limité

Pour text, le minimum comprenait l’affichage US-ASCII et, pour les autres charsets, au moins l’information donnée à l’utilisateur. Un sous-type textuel inconnu pouvait être proposé en version brute seulement si le charset était connu et après conversion de la forme canonique vers la forme locale. Un charset inconnu devenait octet-stream.

Les sous-types inconnus d’image, d’audio et de vidéo suivaient le même repli. Pour application, l’agent devait pouvoir retirer base64 ou quoted-printable et placer le résultat dans un fichier utilisateur. Cette capacité de garde n’était pas une autorisation d’exécution. La RFC 2046 avertissait qu’un visualiseur général hérite des risques de son format le plus dangereux.

Les types composites gardaient leur propre logique. L’agent reconnaissait mixed, alternative et digest ; un multipart inconnu devenait mixed. Il présentait message/rfc822 récursivement ; un sous-type message inconnu devenait octet-stream. Un Content-Type entièrement inconnu devenait octet-stream sans paramètres. Enregistrer le résultat ou choisir un programme restait une décision locale.

« Safe » ne dépassait pas le bord de l’écran

Après dix obligations, la RFC expliquait son vocabulaire. Des données correctement marquées étaient réputées sûres à envoyer parce que le système pouvait au moins les garder comme binaire indifférencié et ne les projetait pas sur l’écran d’un utilisateur qui s’attendait à du texte. Elles étaient aussi « safe » face aux systèmes conformes connus de RFC 821 et RFC 822 : elles ne les cassaient pas et n’étaient pas cassées par eux.

Un objet opaque peut pourtant être hostile. Le programme choisi peut être vulnérable. Un décodage réussi ne prouve ni l’identité de l’émetteur, ni l’intégrité, ni le consentement, ni le rendu, ni la lecture humaine. Informer l’utilisateur d’un charset inconnu ou permettre d’enregistrer un sous-type inconnu pouvait suffire. Le refus utile appartenait au contrat.

Les mauvais relais n’étaient pas légitimés

Le document constatait aussi de nombreux MTA non conformes, largement déployés, qui adaptaient les messages à leur stockage local ou les endommageaient. NUL, TAB, espaces finales, longues lignes, caractères non invariants, un point seul et From en début de ligne pouvaient changer. Base64 respectait l’alphabet et les lignes les plus portables ; quoted-printable ne traversait pas tous les anciens gateways évoqués.

Mais cette liste n’était pas une recommandation. RFC 821 interdisait les modifications d’espace et le repli de ligne. La spécification qualifiait ces pratiques de mauvaises et invalides : la robustesse devait affronter la réalité sans la convertir en règle.

La page d’information actuelle affiche Draft Standard, tandis que le document historique dit Standards Track et novembre 1996. Cela situe le texte, pas son déploiement. EID 3933, Verified, corrige la référence de la condition 10 vers la grammaire de RFC 822 et la reconnaissance de RFC 2047 ; il ne transforme pas un encoded-word d’affichage en identité.

L’héritage de la RFC 2049 est une ignorance disciplinée : décoder ce qui est connu, conserver le reste et ne jamais appeler compréhension la simple garde de bytes.

Sources