Résumé

  • Le RFC 1927 imaginait agrafes et trombones électroniques pour exprimer le degré d’association de documents multiparties, puis leur confiait aussi couleur, processus, comptabilité, recyclage et repérage interne.
  • Les RFC MIME suivants ont distribué ces fonctions : Content-Disposition suggère une présentation, multipart/related définit un objet composé et sa racine, tandis que cid: et mid: donnent un contexte aux références.
  • Une icône peut rendre un lien intelligible. Seule une sémantique explicite, vérifiée par le destinataire, peut décider d’un stockage, d’une exécution ou d’une garantie d’intégrité.

Le trombone paraissait suffisant jusqu’à la première copie

Le RFC 1927 commence par une distinction empruntée au monde physique. Des documents agrafés devraient rester ensemble sur le bureau ; des documents réunis par un trombone devraient pouvoir être étalés facilement. Nul besoin de manuel pour saisir l’image.

Mais le texte lui demande aussitôt beaucoup plus. La taille du trombone pourrait signaler celle du document ou une hiérarchie. Un certificat attaché à chaque pièce servirait à facturer sa création et à repérer les contrefaçons. Un programme de recyclage récupérerait les accessoires à la suppression d’un dossier. Couleur et forme personnaliseraient l’apparence ; une source URL fournirait une image ; l’argent ou l’or déclencherait des composants de workflow différents. Un trombone deviendrait encore drapeau de page, ancre de paragraphe, sculpture et objet doté d’une fatigue propre.

Ce ne sont pas plusieurs nuances d’un même lien. Le texte empile contenance, présentation, identité, autorisation, facturation, durée de vie, position et état mutable. La plaisanterie fonctionne parce que la forme physique donne l’impression que tout cela va de soi. Pour un programme, rien ne va de soi : que faut-il conserver lors d’une copie, d’un transfert ou d’une suppression ?

Le RFC prévient que ces attaches pourraient casser les logiciels de copie rapide, puis déclare ne pas traiter la sécurité. Or sa couleur décorative commande déjà un processus. Le même champ est-il un choix esthétique ou une instruction exécutable ?

Le statut du texte empêchait le gag de devenir une norme

La notice d’origine précise qu’il s’agit d’un document informatif ne spécifiant aucune norme Internet. La fiche actuelle du RFC Editor le place dans l’Independent Stream et mentionne un erratum. Sa date du 1er avril 1996, les risques pour les disquettes et les enfants, ainsi que les sculptures de trombones, fixent le registre humoristique.

Pourtant, la satire révèle une vraie dette de conception. Le mot « pièce jointe » semble net tant qu’aucun système ne doit choisir entre afficher, conserver l’ordre, empêcher la séparation, vérifier une identité ou exécuter une action.

L’erratum vérifié corrige deux formulations du passage sur les enfants. L’éditeur peut établir les mots voulus. Il ne peut pas en déduire un comportement interopérable pour une agrafe électronique. Corriger le support documentaire ne produit pas la sémantique manquante.

Le type de contenu n’était pas un fourre-tout

Publié quelques mois plus tard, le RFC 2046 attribue à Content-Type une mission précise : décrire la nature d’un corps MIME. Les paramètres modifient un sous-type sans changer fondamentalement cette nature, et un paramètre inconnu doit être ignoré. Les formats composés relèvent de types multipart ou application.

Cette règle réduit utilement le pouvoir des imaginaires color=, shape= et src=. Un attribut d’apparence peut rester un attribut d’apparence. Il ne peut pas être, en même temps, l’unique preuve d’une dépendance indispensable et un ordre de lancer un traitement. L’extensibilité suppose que l’inconnu soit toléré ; l’intégrité suppose que l’essentiel ne disparaisse pas quand il est ignoré.

Même multipart/mixed ne promet qu’un ensemble ordonné de parties indépendantes. Voyager dans la même enveloppe prouve un emballage commun, pas l’existence d’un objet indivisible.

La présentation est restée du côté de la suggestion

Le RFC 2183 nomme clairement Content-Disposition comme information de présentation. inline propose un affichage immédiat ; attachment invite l’utilisateur à effectuer une action supplémentaire. Le nom de fichier proposé sert de base éventuelle au stockage, non de décision imposée.

La section sécurité en tire une limite concrète. Le destinataire ne doit pas suivre aveuglément un chemin fourni, écraser un fichier existant ou placer un exécutable dans un endroit où il démarrera sans intervention. L’expéditeur suggère ; l’environnement local valide.

Voilà la version sérieuse du trombone doré. Une couleur peut aider une équipe à reconnaître sa file interne. Pour devenir une commande portable, elle aurait besoin d’un vocabulaire authentifié, de droits explicites et d’un comportement d’échec. La familiarité visuelle ne fournit aucun de ces éléments.

L’objet composé a reçu une racine

Le RFC 2387 traite une relation plus forte avec multipart/related. Ses parties sont interdépendantes au point qu’un affichage séparé ne suffit pas. Le paramètre type décrit le type de la racine ; start peut désigner cette racine par Content-ID, sinon la première partie joue ce rôle. Les liens internes expriment les relations entre composants.

La racine transforme la question. On ne demande plus seulement quelles pièces ont été transportées ensemble, mais quel composant organise l’objet et quelles ressources il appelle. L’application qui comprend le type composé interprète l’ensemble. Dans ce contexte, Content-Disposition peut être redondant, voire trompeur ; le traitement de multipart/related l’emporte.

Le repli est lui aussi honnête. Un agent qui ne comprend pas le type lié le traite comme un multipart mélangé. Il ne feint pas qu’un symbole inconnu ait créé une obligation structurelle.

Nommer la cible exigeait aussi son contexte

Une ligne dessinée entre deux icônes ne désigne toujours pas des octets précis. Le RFC 2392 définit cid: pour une partie MIME et mid: pour un message, ou pour une partie dans un message nommé. Les Content-ID sont conçus pour être uniques, mais de nombreux magasins n’indexent pas une partie indépendamment de son message. La forme longue de mid: réintroduit ce contexte.

Un drapeau placé sur « le troisième paragraphe » peut dériver après modification. Une URL extérieure peut changer. Un identifiant contextualisé permet au moins de savoir ce qui était visé et où le résoudre. Il ne prouve pas que la cible est sûre et ne donne pas le droit de l’exécuter. Adresse, intégrité et autorité restent trois faits différents.

L’agrégat devait rester cohérent sans réécrire sa preuve

Le RFC 2557 applique cette architecture à un besoin pratique : transporter en un message un document HTML complet, avec images et ressources auxiliaires. Une racine text/html et ses dépendances sont réunies dans multipart/related, puis référencées par Content-ID ou Content-Location.

Le document sépare l’URI de l’agrégat de celle de la racine. Une localisation peut étiqueter une partie sans la rendre récupérable partout. Il évite aussi de réécrire inutilement le HTML existant, car modifier les références peut invalider les contrôles d’intégrité. Être ensemble, être localisable et être intact ne sont pas la même propriété.

Le mécanisme est moins séduisant qu’une agrafe dessinée. Il est toutefois copiable et vérifiable : la racine, les composants et leurs références sont déclarés, et l’application responsable est identifiable.

Le socle commun doit porter la relation, pas le décor

Dans Running-Code Primacy, Heng Lu place la réalité d’un changement dans l’implémentation, la validation, le déploiement et l’adoption. Une agrafe publiée ne relie rien si les destinataires ne partagent pas son comportement et ne le préservent pas dans leurs opérations.

La spécification initiale minimale ne demande pas une convention vague. Elle exige de définir strictement ce qui doit être commun : racine, portée des identifiants, règles de relation, intégrité et traitement sûr de l’inconnu. Les couleurs et préférences de bureau peuvent rester locales.

La distinction entre couche symbolique et couche exécutable achève le raisonnement. L’icône convainc l’œil que les éléments vont ensemble. Le pouvoir réel apparaît quand un logiciel interdit la séparation, déclenche un flux ou efface une ressource. Les confondre transforme une interface aimable en surface de contrôle non examinée.

Le RFC 1927 ne démontre donc pas que l’informatique manquait d’accessoires de bureau. Il montre qu’un dessin familier ne dispense jamais de définir une relation. L’image peut expliquer ; la sémantique vérifiable doit décider.

Sources

  1. RFC 1927 — Suggested Additional MIME Types for Associating Documents
  2. RFC Editor — fiche actuelle du RFC 1927
  3. RFC Editor — errata du RFC 1927
  4. RFC 2046 — MIME Part Two: Media Types
  5. RFC 2183 — Content-Disposition
  6. RFC 2387 — MIME Multipart/Related
  7. RFC 2392 — URL Content-ID et Message-ID
  8. RFC 2557 — MIME Encapsulation of Aggregate Documents
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — On Reality Layers