Résumé

  • RFC 3459 plaçait Handling=REQUIRED|OPTIONAL sur chaque partie MIME : l’impossibilité de transmettre une partie REQUIRED faisait échouer tout le message, tandis qu’une partie OPTIONAL pouvait être supprimée sans échec de livraison.
  • Les parties non marquées et les valeurs inconnues devenaient REQUIRED; dans une structure signée ou chiffrée, la position du marquage déterminait si la passerelle pouvait transformer ou devait rejeter.

La livraison partielle exigeait un contrat de perte

Le courrier Internet général conservait ou exposait normalement chaque partie MIME, même sans logiciel capable de l’afficher. Un système de messagerie vocale pouvait être physiquement plus limité : stocker la voix et le fax, mais pas une présentation, un document binaire ou une vidéo. Une passerelle connaissant les capacités du terminal devait parfois enlever ce que celui-ci ne pouvait recevoir.

Publié en janvier 2003, RFC 3459 rendait cette transformation explicite. Le texte, la notice RFC Editor, le dossier Datatracker, son historique, ses références, ses citations et les errata en fixent la trace. Le mécanisme mettait à jour RFC 3204 en séparant Handling du transport ISUP/QSIG.

Attaché à Content-Disposition, REQUIRED signifiait que l’expéditeur ne considérait pas le message livré si cette partie ne passait pas. L’échec d’une seule partie requise emportait donc le message entier. OPTIONAL autorisait la suppression silencieuse et interdisait un avis d’échec sauf si une partie REQUIRED échouait aussi.

Il ne s’agissait pas d’un classement d’importance ou d’urgence. Le marquage distribuait le pouvoir de transformer et la conséquence d’une perte. Un logiciel pouvait ajouter une partie auxiliaire à l’insu de l’utilisateur; la rendre facultative empêchait qu’une plate-forme vocale refuse un enregistrement utile pour une pièce jointe indifférente à l’expéditeur.

Suppression, échec et notification restaient distincts

Le défaut était prudent : toute partie sans marque était REQUIRED, de même que toute future valeur inconnue. Les anciens agents pouvaient ignorer un paramètre Content-Disposition inconnu selon les règles MIME, tandis qu’une passerelle consciente du mécanisme ne supprimait pas silencieusement une sémantique qu’elle ne comprenait pas. RFC 2045 fournissait la base MIME; RFC 2421 illustrait le contexte vocal contraint.

La criticité ne demandait pas, à elle seule, un reçu. Les DSN SMTP suivaient RFC 3461, les MDN RFC 3798, et l’incapacité à stocker ou rendre pouvait employer le code 5.6.1 de RFC 3463. Avant livraison finale, une passerelle pouvait émettre un DSN; après livraison, en qualité d’agent utilisateur, un MDN; SIP renvoyait un statut, dont 415 dans le cas RFC 3204. La topologie et le rôle déterminaient la preuve, pas le seul mot REQUIRED.

Dans les enveloppes cryptographiques, l’emplacement faisait politique

Avec la sécurité multipart de RFC 1847, marquer l’enveloppe multipart/signed REQUIRED imposait son passage intact et une vérification véritable de bout en bout; un terminal incapable devait conduire au rejet. Marquer l’objet de contrôle de signature REQUIRED permettait à la passerelle de vérifier avant transfert, mais un échec imposait encore le rejet. Si la signature était OPTIONAL et la matière signée REQUIRED, la passerelle pouvait retirer les données de signature pour un terminal incapable, même si vérifier et signaler une altération restait fortement recommandé. RFC 2480 donnait des règles connexes.

Pour le chiffrement, un objet de contrôle REQUIRED exigeait le maintien du chiffrement de bout en bout. S’il était OPTIONAL, une passerelle capable pouvait déchiffrer puis transmettre du clair à un terminal incapable; l’autorisation venait précisément du choix de l’expéditeur. Une marque cachée à l’intérieur du chiffré obligeait à déchiffrer avant de la découvrir. Le contenu chiffré non visible restait donc REQUIRED par défaut.

RFC 3238 apportait le cadre OPES plus large : consentement, notification et comportement non bloquant plutôt qu’une modification invisible. La distinction rejoint les couches de réalité de Heng Lu : marquage, capacité déclarée, transformation réelle et résultat sont quatre reçus. La primauté du code en fonctionnement invite à comparer les arbres MIME avant et après la passerelle. Ce sont des lectures postérieures, non une preuve de l’intention privée de l’auteur.

RFC 3459 a ainsi transformé une perte partielle invisible en allocation explicite des conséquences. Une partie facultative pouvait disparaître sans invalider la livraison; une petite partie requise pouvait faire échouer l’ensemble.

Sources