Résumé

  • RFC 2368 a étendu mailto: afin qu’une URL puisse proposer plusieurs destinataires, des en-têtes et un court corps en texte brut, sans imposer une interaction réseau immédiate.
  • Le client pouvait écarter les champs dangereux et devait montrer le message décodé avant de demander l’accord ; ni le lien, ni le clic, ni le brouillon ne prouvaient l’envoi ou la réception.

Le Web avait habitué ses lecteurs à une mécanique simple : un lien désigne une ressource, le navigateur contacte un serveur, une réponse revient. mailto: rompait cette séquence. Son résultat normal pouvait être une fenêtre locale, remplie mais encore silencieuse sur le réseau.

RFC 1738 ne plaçait après mailto: qu’une adresse. RFC 2368 ajoutait une liste de boîtes, puis des couples nom-valeur après ?, séparés par &. Le nom spécial body préparait le premier corps text/plain. On pouvait ainsi fabriquer un abonnement à une liste, une demande à un robot documentaire, une réponse d’archive ou un message avec copie sans demander au lecteur de recopier chaque champ.

Cette commodité créait une chaîne de responsabilités. L’auteur de la page écrivait les octets de l’URL. Le parseur décidait comment les décoder. Le client de messagerie appliquait sa politique de sécurité. L’utilisateur voyait, corrigeait ou refusait. Ensuite seulement venaient la soumission, l’acceptation par un serveur, le transport, la remise et l’action du destinataire. Le texte ne confondait aucun de ces reçus.

L’encodage matérialisait cette séparation. Les caractères ?, = et & structuraient l’URL ; employés comme données, ils devaient être échappés. L’espace devenait %20, un saut de ligne du corps %0D%0A, un signe pour cent d’adresse %25. Dans HTML, le séparateur & devait apparaître sous la forme &. Le code source, le lien analysé et le message affiché n’étaient donc pas la même chaîne.

Les limites linguistiques étaient celles de 1998. Les octets sur huit bits étaient interdits. Les mots encodés de MIME pouvaient servir dans certains en-têtes, mais pas dans body. Aucune substitution de variable n’existait : le lien statique ne pouvait pas introduire de façon fiable l’adresse de la personne qui l’activait, ni produire une signature dépendant du contexte local. Il s’agissait d’un gabarit, pas d’un programme général.

La grammaire acceptait davantage que ce qu’un client devait exécuter. RFC 2368 recommandait de ne pas créer de message si un en-tête paraissait dangereux, ou de ne conserver qu’un sous-ensemble sûr. Subject, Keywords et Body étaient jugés utiles et sûrs ; l’auteur d’un lien ne devait guère compter au-delà de Subject et Body. From, Bcc, les champs de routage et plusieurs champs MIME ne recevaient aucune autorité du seul fait d’être syntaxiquement présents.

Le point décisif concernait l’accord. Avant l’envoi, le client devait présenter le message entièrement décodé, y compris les en-têtes fournis, expliquer qu’un courrier allait partir et demander l’approbation. Le risque portait sur l’identité et les conséquences : révéler l’utilisateur à un tiers, provoquer une dépense, produire un acte illégal ou déclencher une action dommageable attribuée à l’expéditeur.

Ainsi, une URL prouve qu’un éditeur a proposé un gabarit. Un clic indique au mieux qu’une interface l’a activé. Un compositeur rempli montre que certains champs ont passé le filtre local. Seuls d’autres journaux peuvent établir l’approbation, la remise au serveur, son acceptation, la livraison, la lecture ou l’exécution d’une commande.

RFC 6068 a remplacé le texte en 2010. Il a introduit l’encodage UTF-8 avant l’échappement, clarifié les doublons et révisé plusieurs règles. Il a préservé l’essentiel : l’URI fournit un modèle de message, non la preuve d’un envoi. Une représentation plus juste des caractères ne vaut toujours ni consentement ni livraison.

L’apport historique de RFC 2368 réside donc dans une forme limitée d’automatisation. Un document extérieur pouvait économiser la saisie, mais le client gardait son filtre et la personne gardait le dernier geste réversible.

Sources