Résumé

  • RFC 3458 définissait Message-Context, champ facultatif décrivant le mode d’interaction attendu avec le message entier, et non la nature certaine de chacune de ses parties MIME.
  • Une indication fausse, inconnue ou périmée pouvait orienter une interface, mais elle ne devait ni faire échouer le transfert ni rendre le message moins intelligible qu’en l’absence du champ.

Une boîte aux lettres n’était plus un seul média

En janvier 2003, le courrier Internet pouvait réunir messages classiques, télécopies, alertes de radiomessagerie, voix enregistrée et assemblages multimédias. Deux objets contenant du texte ne réclamaient pas nécessairement la même interaction : l’un pouvait être une lettre, l’autre un SMS ou la transcription d’un appel. Examiner intégralement une charge volumineuse pour choisir une icône ou une visionneuse était coûteux.

RFC 3458 proposait donc un champ de niveau supérieur, présent au plus une fois. Ses premières valeurs enregistrées comprenaient voice-message, fax-message, pager-message, multimedia-message, text-message et none; l’absence du champ équivalait à none. Le texte brut, la notice RFC Editor, la fiche Datatracker, son historique, ses références, ses citations ultérieures et la recherche d’errata fixent ce dossier normatif.

Une application pouvait employer l’indice pour choisir une présentation, regrouper les entrées, régler l’ordre d’une liste, limiter ce qui transitait sur un accès contraint ou préparer une réponse. Aucune de ces commodités ne prouvait qu’un son, une image de fax ou un programme se trouvait réellement dans le corps.

La transformation rendait l’écart légitime

L’exemple le plus éclairant concernait une passerelle qui retirait la partie audio d’un message vocal et conservait sa transcription. L’histoire de l’objet restait celle d’une communication vocale, mais le terminal ne pouvait jouer un son disparu. À l’inverse, une étiquette vocale accompagnée seulement d’une télécopie n’autorisait pas l’abandon de celle-ci : le client devait montrer ce qu’il possédait.

RFC 2822 définissait la syntaxe du message. RFC 2183 traitait de la disposition d’une partie, RFC 2387 et RFC 2557 des structures composées, et RFC 2423 du contexte VPIM. Ces mécanismes voisins ne cédaient pas leur autorité à Message-Context.

Ainsi, une classe invalide ou inexacte ne devait provoquer ni rejet du transport ni échec d’affichage. Le résultat devait rester au moins aussi significatif que si l’en-tête n’existait pas. La réexpédition, au-delà de la simple conservation, demeurait hors périmètre : une valeur devenue ancienne était une anomalie à observer, pas une vérité à imposer.

L’indice restait sous la frontière de confiance

La section de sécurité interdisait le raccourci le plus dangereux : exécuter aveuglément un programme parce qu’un contexte le suggérait. Un expéditeur malveillant pouvait provoquer une consommation de ressources, une mauvaise orientation ou une priorité indue. Le champ n’authentifiait ni l’auteur ni le corps, n’autorisait aucune action et ne prouvait ni livraison, ni urgence, ni lecture humaine.

RFC 3459 portait séparément sur les parties MIME critiques. RFC 3938 modifia ensuite la politique d’enregistrement, tandis que RFC 3864 établissait le cadre général des champs. Le registre IANA constate l’allocation; il ne constate pas le comportement d’un logiciel donné.

La distinction rejoint, rétrospectivement, les couches de réalité de Heng Lu : déclaration et corps reçu sont deux faits différents. La primauté du code en fonctionnement invite à regarder l’arbre MIME, les transformations et le rendu de secours. Le principe de spécification initiale minimale éclaire l’utilité d’un petit champ facultatif qui n’absorbe ni MIME ni la politique de sécurité. Ce sont des lectures éditoriales postérieures, non l’intention privée des auteurs.

RFC 3458 fut donc robuste parce qu’il refusa de transformer une indication pratique en autorité. Le contexte préparait la lecture; le contenu restant décidait ce qui pouvait être lu.

Sources