Résumé

  • RFC 2231 impose des sections numérotées à partir de zéro, sans trou, et réserve au début de la première section encodée la déclaration du jeu de caractères et de la langue. Le destinataire réassemble selon les indices, puis décode.
  • Le résultat n’est qu’une valeur de Content-Disposition. RFC 2183 demande au logiciel récepteur d’écarter les chemins, d’éviter l’écrasement et les emplacements dangereux, et d’empêcher toute exécution sans action explicite.

Quand le fragment 2 arrive avant le fragment 0

L’ordre d’affichage d’un en-tête MIME n’est pas l’ordre d’un récit. Les paramètres peuvent être réordonnés sans changer leur sens. Ainsi, une passerelle peut présenter filename*2 avant filename*0*. Le seul ordre utile se trouve dans les suffixes.

Prenons cet exemple construit pour l’explication :

filename*0*=utf-8'en'Quarterly%20; filename*1*=review%20; filename*2=final.pdf

Les trois champs ne proposent pas trois fichiers. Ils portent une seule valeur. La section zéro déclare UTF-8 et une langue facultative, puis commence le contenu. La section un continue sous forme d’octets échappés. La section deux termine sans encodage. Si la suite est complète et non ambiguë, on obtient Quarterly review final.pdf.

RFC 2231 exige que les numéros commencent à zéro et progressent de un en un. Les trous et les zéros initiaux sont exclus. Avant tout décodage, le récepteur doit donc identifier le nom de base commun, repérer les doublons, vérifier la continuité, trier par indice et réunir les charges utiles.

Cette chronologie protège aussi les caractères multioctets. Le jeu de caractères et la langue ne sont déclarés qu’au commencement ; une coupure entre deux sections n’est pas forcément une coupure entre deux caractères. Si chaque fragment UTF-8 est décodé séparément, un octet placé de l’autre côté de la frontière peut devenir un caractère de remplacement. Deux produits peuvent alors afficher deux noms différents à partir du même message.

La chaîne robuste sépare les questions : analyser les noms de paramètres ; valider une série unique ; concaténer par numéro ; convertir les séquences %HH des parties encodées en octets ; interpréter l’ensemble selon le jeu déclaré ; transmettre enfin la valeur à une politique de disposition. Le paragraphe de sécurité de RFC 2231 est succinct, mais la grammaire et la déclaration unique du jeu de caractères imposent cette discipline d’implémentation.

Une suggestion n’est pas un droit d’écriture

RFC 2231 étend la représentation. Il ne donne pas au correspondant distant la main sur le système de fichiers. RFC 2183, que le mécanisme complète, qualifie filename de nom suggéré pour extraire une partie de corps.

Le logiciel destinataire ne doit pas l’adopter aveuglément. Il doit ignorer les répertoires éventuels et ne considérer que le dernier composant. Il doit empêcher l’écrasement inattendu, les écritures dans des zones système ou de démarrage, l’usage de fichiers spéciaux et de tubes, ainsi que le dépôt d’un exécutable dans un chemin où il serait lancé. L’enregistrement d’une pièce jointe ne doit jamais suffire à l’exécuter sans initiative explicite de l’utilisateur.

Une valeur UTF-8 parfaitement reconstruite peut toujours contenir ../, un chemin absolu, un nom réservé, un caractère de contrôle, une commande bidirectionnelle ou une extension trompeuse. Le décodage en pourcentage n’assainit rien. Un jeu de caractères valide n’authentifie pas l’émetteur. La concordance entre filename et Content-Type ne prouve pas que les octets soient sûrs. Et aucune de ces observations ne vaut autorisation d’ouvrir, d’écraser, d’exécuter ou d’attribuer.

Les responsabilités doivent rester visibles. Le parseur MIME répond à la question de la structure. Le décodeur répond à celle du texte. Une règle locale construit un nom acceptable. La couche de stockage choisit un répertoire confiné et traite les collisions. Une décision distincte de l’utilisateur ou d’une politique autorisée permet éventuellement l’ouverture. Franchir une étape ne délivre pas le laissez-passer de la suivante.

Deux auteurs pour RFC 2231, pas un voisinage reconstitué

La page de garde de RFC 2231 nomme Ned Freed et Keith Moore. RFC 2184, son prédécesseur remplacé, porte les mêmes deux noms. Voilà la frontière exacte de la corédaction de cette convention.

Patrik Fältström appartient bien à l’histoire de l’internationalisation de l’Internet, mais pas comme auteur de RFC 2231 ou de RFC 2184. RFC 3490, l’ancienne spécification IDNA, associe son nom à ceux de Paul Hoffman et Adam Costello. Fusionner ces contributions voisines serait une erreur de provenance : deux travaux peuvent traiter les langues et les caractères tout en restant des documents, des équipes et des contrats différents.

Le parcours plus large de Freed est vérifiable dans l’IETF Datatracker. Nathaniel Borenstein raconte, dans son hommage, la rencontre entre son projet de courrier enrichi et la recherche de robustesse et d’interopérabilité de Freed. RFC 2045 structure les corps MIME ; RFC 2047 traite le texte non ASCII dans certains en-têtes ; RFC 2231 se concentre sur le reliquat précis des paramètres.

Cette étroitesse est une garantie. Une étoile ajoutée à n’importe quel champ ne suffit pas à lui conférer la sémantique de RFC 2231 : la spécification qui définit le champ doit l’adopter. Le mécanisme transporte une valeur ; il ne fabrique ni identité, ni propriété, ni confiance.

L’héritage HTTP a supprimé les continuations

RFC 8187 reprend pour HTTP une forme apparentée d’encodage des paramètres, impose la prise en charge d’UTF-8, mais écarte les continuations de RFC 2231. HTTP n’en avait pas besoin. La filiation technique ne dispense pas de redéfinir le périmètre.

RFC 6266 maintient la limite du Content-Disposition HTTP : le nom proposé est indicatif. Le destinataire retire les segments de chemin, garde la maîtrise du répertoire, traite les extensions dangereuses, les caractères de contrôle et les noms spéciaux. Un serveur peut suggérer une étiquette ; il ne gagne pas un pouvoir sur le disque du client.

L’apport durable de RFC 2231 tient donc dans une double rigueur. L’interopérabilité exige des règles communes exactes pour reconstruire une valeur. La sécurité exige de nommer tout ce que cette reconstruction ne prouve pas. Une chaîne de caractères peut retrouver son intégrité sans acquérir la moindre autorité.

Sources