Équipe d'ingénierie de l'Internet (IETF)	M. Düerst, Aoyama Gakuin University
Request for Comments : 6068	L. Masinter, Adobe Systems Incorporated
RFC rendue obsolète : 2368	J. Zawinski, DNA Lounge
Catégorie : Sur la voie de la normalisation	octobre 2010
ISSN: 2070-1721	Traduction Claude Brière de L'Isle

Schéma d'URI "mailto"

Résumé
Le présent document définit le format des identifiants de ressource universels (URI, Uniform Resource Identifier) pour identifier les ressources qui sont accessibles en utilisant la messagerie électronique Internet. Il ajoute une meilleure internationalisation et compatibilité avec les identifiants de ressource internationalisés (IRI, Internationalized Resource Identifier) [RFC3987] à la syntaxe précédente des URI "mailto" [RFC2368].

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc6068 

Notice de droits de reproduction
Copyright (c) 2010 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
2. Syntaxe d'URI "mailto"	2
3. Sémantique et fonctionnement	4
4.  Champs d'en-tête non sûrs	5
5. Codage	5
6. Exemples	5
6.1 Exemples de base	5
6.2 Exemples d'adresse de messagerie électronique compliquées	6
6.3 Exemples avec codage en pourcentage fondé sur UTF-8	7
7. Considérations sur la sécurité	8
8. Considérations relatives à l'IANA	9
8.1 Mise à jour de l'enregistrement du schéma d'URI 'mailto'	9
8.2 Enregistrement du champ d'en-tête de corps	9
9. Principaux changements par rapport à la RFC 2368	9
10. Remerciements	9
9. Références	10
9.1 Références normatives	10
11.2 Références pour information	10
Adresse des auteurs	10
 	1.	Introduction

Le schéma d'URI "mailto" est utilisé pour identifier des ressources auxquelles on accède en utilisant la messagerie Internet. Dans sa forme la plus simple, un URI "mailto" contient une adresse de messagerie Internet. Pour les interactions qui exigent que soient spécifiés des en-têtes ou des corps de message, le schéma d'URI "mailto" permet aussi de fournir des champs d'en-tête de messagerie et le corps du message.

La présente spécification étend la précédente définition de schéma pour permettre aussi des données de caractères codés en pourcentage sur la base de UTF-8 [RFC3629], qui offre une meilleure façon plus cohérente de traiter les caractères non ASCII pour l'internationalisation.

La présente spécification ne traite pas les besoins de l'effort actuel d'internationalisation des adresses de messagerie (voir la [RFC4952]). En particulier, la présente spécification n'inclut pas de syntaxe pour les adresses de repli.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Dans le présent document, les URI sont enclos dans des crochets '<' et '>' comme décrit dans l'Appendice C de la [RFC3986]. Des espaces et coupures de ligne supplémentaires sont ajoutés aux longs URI présents – ils ne font pas partie de l'URI réel.

 	2.	Syntaxe d'URI "mailto"

La syntaxe d'un URI "mailto" est décrite en utilisant l'ABNF de la [RFC5234], les définitions de non terminaux provenant de la [RFC5322] (dot-atom-text, quoted-string), et les définitions de non terminaux provenant de la [RFC3986] (unreserved, pct-encoded):

mailtoURI = "mailto:" [ to ] [ hfields ]	; (URI mailto)
to = addr-spec *("," addr-spec )	; (à = spécification d'adresse)
hfields = "?" hfield *( "&" hfield )	; (champs d'en-tête)
hfield = hfname "=" hfvalue	; (= nom de champ d'en-tête = valeur de champ d'en-tête)
hfname = *qchar	
hfvalue = *qchar	
addr-spec = local-part "@" domain	; (partie locale@domaine)
local-part = dot-atom-text / quoted-string	; (texte avec point / chaîne entre guillemets)
domain = dot-atom-text / "[" *dtext-no-obs "]"	
dtext-no-obs = %d33-90 /	 ; US-ASCII imprimable %d94 à 126 ; non inclus les caractères "[", "]", ou "\"
qchar = unreserved / pct-encoded / some-delims	; (non réservé / codé en pct /des délimiteurs)
some-delims  = "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";" / ":" / "@"

<addr-spec> est une adresse de messagerie comme spécifié dans la [RFC5322], mais excluant les <comment> provenant de la [RFC5322]. Cependant, les changements suivants s'appliquent :

1.	Un certain nombre de caractères qui peuvent apparaître dans <addr-spec> DOIVENT être codés en pourcentage. Ce sont les caractères qui ne peuvent pas apparaître dans un URI conformément à la [RFC3986] ainsi que "%" (parce qu'il est utilisé pour le codage en pourcentage) et tous les caractères dans gen-delims excepté "@" et ":" (c'est-à-dire, "/", "?", "#", "[", et "]"). Des caractères dans sub-delims, au moins les suivants ont aussi à être codés en pourcentage : "&", ";", et "=". Il faut veiller aussi bien lors du codage que du décodage à s'assurer que ces opérations ne sont appliquées qu'une seule fois.

2.	<obs-local-part> et <NO-WS-CTL> comme définis dans la [RFC5322] NE DOIVENT PAS être utilisés.

3.	Les espaces et commentaires dans <local-part> et <domain> NE DOIVENT PAS être utilisés. Ils n'auraient aucune signification opérationnelle.

4.	Le codage en pourcentage peut être utilisé dans la partie <domain> d'une <addr-spec> afin de noter un nom de domaine internationalisé. Les considérations sur <reg-name> de la [RFC3986] s'appliquent. En particulier, les caractères non ASCII DOIVENT d'abord être codés en accord avec l'UTF-8 [RFC3629], et ensuite chaque octet de la séquence UTF-8 correspondante DOIT être codé en pourcentage pour être représenté comme des caractères d'URI. Les applications qui produisent des URI NE DOIVENT PAS utiliser de codage en pourcentage dans les noms de domaine sauf si il est utilisé pour représenter une séquence de caractères UTF-8. Quand le nom de domaine internationalisé est utilisé pour composer un message, le nom DOIT être transformé en codage d'application de nom de domaine internationalisé (IDNA, Internationalized Domain Names in Applications) [RFC5891] lorsque approprié. Les producteurs d'URI DEVRAIENT fournir ces noms de domaine dans le codage IDNA, plutôt que codé en pourcentage, si ils souhaitent maximiser l'interopérabilité avec les interpréteurs d'URI "mailto" traditionnels.

5.	Le codage en pourcentage d'octets non ASCII dans la <local-part> d'une <addr-spec> est réservé pour l'internationalisation de la <local-part>. Les caractères non ASCII DOIVENT d'abord être codés en accord avec UTF-8 [RFC3629], et ensuite chaque octet de la séquence UTF-8 correspondante DOIT être codé en pourcentage pour être représenté comme caractères d'URI. Tout autre codage en pourcentage de caractères non ASCII est interdit. Quand une <local-part> contenant des caractères non ASCII va être utilisée pour composer un message, la <local-part> DOIT être transformée pour se conformer à tout codage qui pourra être défini dans une future spécification pour l'internationalisation des adresses de messagerie électronique.

<hfname> et <hfvalue> sont respectivement les codages d'un nom et valeur de champ d'en-tête [RFC5322]. Le codage en pourcentage est nécessaire pour les mêmes caractères que mentionnés ci-dessus pour <addr-spec>. <hfname> est insensible à la casse, mais <hfvalue> est en général sensible à la casse. Noter que la [RFC5322] permet tous les caractères US-ASCII imprimables sauf":" dans des noms de champ d'en-tête facultatif (paragraphe 3.6.8) ce qui est la raison pour laquelle <pct-encoded> fait partie de la production de nom de champ d'en-tête.

Le "corps" spécial <hfname> indique que la <hfvalue> associée est le corps du message. La valeur du champ "body" est destinée à contenir le contenu de la première partie de corps text/plain du message. Le pseudo champ d'en-tête "body" est principalement destiné à la génération de courts messages de texte pour un traitement automatique (comme des messages "subscribe" pour les listes de diffusion) et non pour les corps MIME généraux. Sauf pour le codage de caractères fondé sur UTF-8 et le codage en pourcentage, aucun codage supplémentaire (comme par exemple, base64 ou quoted-printable ; voir la [RFC2045]) n'est utilisé pour la valeur du champ "body". Par conséquent, les champs d'en-tête relatifs au codage du message (par exemple, Content-Transfer-Encoding) dans un URI "mailto" sont non pertinents et DOIVENT être ignorés. Le nom du pseudo champ d'en-tête "body" a été enregistré par l'IANA pour ce besoin particulier (voir le paragraphe 8.2).

Dans les URI "mailto", les caractères "?", "=", et "&" sont réservés, comme servant de délimiteurs. Ils peuvent être échappés (comme respectivement "%3F", "%3D", et "%26") quand ils ne servent pas de délimiteurs.

Des restrictions supplémentaires sur quels caractères sont permis peuvent s'appliquer selon le contexte où l'URI est utilisé. De telles restrictions peuvent être traitées par des mécanismes d'échappement spécifiques du contexte. Par exemple, parce que le caractère "&" (esperluette) est réservé dans HTML et XML, tout URI "mailto" qui contient une esperluette doit être écrit avec une entité HTML/XML ("&amp;") ou une référence de caractère numérique ("&#x26;" ou "&#38;").

Les caractères non ASCII peuvent être codés en <hfvalue> comme suit :

1.	Les mots codés en MIME (comme défini dans la [RFC2047]) sont permis dans les valeurs de champ d'en-tête, mais pas dans une <hfvalue> d'un "corps" <hfname>. Les séquences de caractères qui ressemblent à des mots codés en MIME peuvent apparaître dans une <hfvalue> d'un "corps" <hfname>, mais dans ce cas elles n'ont pas de signification particulière. On notera que les caractères '=' et '?' utilisés comme délimiteurs dans les mots codés en MIME doivent être codés en pourcentage. On notera aussi que l'utilisation de mots codés en MIME diffère légèrement pour les champs d'en-tête dits structurés et non structurés.

2.	Les caractères non ASCII peuvent être codés en accord avec UTF-8 [RFC3629], et ensuite chaque octet de la séquence UTF-8 correspondante est codé en pourcentage pour être représenté comme caractères d'URI. Quand des valeurs de champ d'en-tête codées de cette façon sont utilisées pour composer un message, la <hfvalue> doit être convenablement codée (transformée en mots codés en MIME [RFC2047]) sauf pour une <hfvalue> d'un "corps" <hfname>, qui doit être codé conformément à la [RFC2045]. Noter que pour les mots codés en MIME et pour les corps dans les messages électroniques composés, les codages autres que UTF-8 PEUVENT être utilisés pour autant que les caractères soient correctement transcodés.

Noter aussi qu'il est syntaxiquement valide de spécifier à la fois <to> et un <hfname> dont la valeur est "to". C'est-à-dire,
<mailto:addr1@an.exemple,addr2@an.exemple>
est équivalent à
<mailto:?to=addr1@an.exemple,addr2@an.exemple>
est équivalent à
<mailto:addr1@an.exemple?to=addr2@an.exemple>

Cependant, la dernière forme est NON RECOMMANDÉE parce que différents agents d'utilisateurs traitent ce cas de façons différentes. En particulier, certains clients existants ignorent les <hfvalue> "to".

Les mises en œuvre NE DOIVENT PAS produire deux champs d'en-tête "To:" dans un message ; le champ d'en-tête "To:" peut se produire au plus une fois dans un message ([RFC5322], paragraphe 3.6). Aussi, les créateurs d'URI "mailto" NE DOIVENT PAS inclure d'autres champs d'en-tête de message plusieurs fois si ces champs d'en-tête peuvent seulement être utilisés une seule fois dans un message.

Pour éviter des problèmes d'interopérabilité, les créateurs d'URI "mailto" NE DEVRAIENT PAS utiliser le même <hfname> plusieurs fois dans le même URI. Si le même <hfname> apparaît plusieurs fois dans un URI, le comportement varie largement pour les différents agents d'utilisateur, et pour chaque <hfname>. Des exemples incluent d'utiliser seulement la première ou la dernière paire <hfname>/<hfvalue>, créant plusieurs champs d'en-tête, et combinant chaque <hfvalue> par simple enchaînement ou d'une façon appropriée pour le champ d'en-tête correspondant.

Noter que la présente spécification, comme toute spécification de schéma d'URI, ne définit pas de syntaxe ou de signification d'un identifiant de fragment (voir la [RFC3986]) parce que cela dépend du type de représentation restituée. Dans les scénarios d'usage connus actuellement, un URI "mailto" ne peut pas être utilisé pour restituer de telles représentations. Donc, les identifiants de fragment n'ont pas de signification, NE DEVRAIENT PAS être utilisés dans les URI "mailto", et DEVRAIENT être ignorés à la résolution. Le caractère "#" dans les <hfvalue> DOIT être échappé comme  %23.

 	3.	Sémantique et fonctionnement

Un URI "mailto" désigne une "ressource Internet", qui est la boîte aux lettres spécifiée dans l'adresse. Quand des champs d'en-tête supplémentaires sont fournis, la ressource désignée est la même adresse mais avec un profil supplémentaire pour accéder à la ressource. Bien qu'il y ait des ressources Internet qui puissent seulement être accédées via messagerie électronique, l'URI "mailto" n'est pas conçu comme un moyen de restituer automatiquement de tels objets.

L'opération par laquelle un schéma d'URI est résolu n'est pas rendue obligatoire par les spécifications d'URI. Dans la pratique courante, résoudre des URI comme ceux du schéma d'URI 'http' cause une interaction immédiate entre le logiciel client et un hôte d'un serveur interactif. L'URI "mailto" a une sémantique inhabituelle parce que la résolution d'un tel URI ne cause pas une interaction immédiate avec un serveur. À la place, le client crée un message pour l'adresse désignée avec les divers champs d'en-tête réglés par défaut. L'utilisateur peut éditer le message, envoyer le message non édité, ou choisir de ne pas envoyer le message.

Les paires <hfname>/<hfvalue> dans un URI "mailto", bien que syntaxiquement équivalentes aux champs d'en-tête d'un message électronique, ne correspondent pas directement aux champs d'en-tête dans un message électronique. En particulier, les <hfvalue> To, Cc, et Bcc ne résultent pas nécessairement en un champ d'en-tête contenant la valeur spécifiée. Le logiciel client de messagerie PEUT éliminer les adresses dupliquées. Les créateurs d'URI "mailto" DEVRAIENT éviter d'utiliser la même adresse deux fois dans un URI "mailto".

Les champs qui désignent l'origine comme From et Date, les champ relatifs à l'acheminement (Apparently-To, Resent-*, etc.), les champs de trace, et les champs d'en-tête MIME (MIME-Version, Content-*) quand ils sont présents dans l'URI, DOIVENT être ignorés. Le client de messagerie DOIT créer de nouveaux champs quand nécessaire, comme il le ferait pour tout nouveau message. Les champs d'en-tête non reconnus et les champs d'en-tête avec des valeurs incohérentes avec celles que le client de messagerie enverrait normalement DEVRAIENT être traités comme particulièrement suspects. Par exemple, il peut y avoir des champs d'en-tête qui sont totalement sûrs mais inconnus du MUA, de sorte que le MUA PEUT choisir de les montrer à l'utilisateur.

 	4. 	Champs d'en-tête non sûrs

L'agent d'utilisateur qui interprète un URI "mailto" NE DEVRAIT PAS créer un message si un des champs d'en-tête est considéré comme dangereux ; il PEUT aussi choisir de créer un message avec seulement un sous ensemble des champs d'en-tête donnés dans l'URI. Seul un ensemble limité de champs d'en-tête comme Sujet et Mots clés, ainsi que Body, sont estimés être à la fois sûrs et utiles en général. Dans des cas où la source d'un URI est bien connue, et/ou des champs d'en-tête spécifiques sont limités à des valeurs spécifiques bien connues, d'autres champs d'en-tête PEUVENT être considérés aussi comme sûrs.

Le créateur d'un URI "mailto" ne peut pas espérer que le résolveur d'un URI va comprendre plus que les champs d'en-tête "subject" et "body". Les clients qui résolvent les URI "mailto" en messages électroniques DOIVENT être capables de créer correctement des messages conformes à la [RFC5322] en utilisant les champs d'en-tête "subject" et "body".

 	5.	Codage

La [RFC3986] exige que de nombreux caractères dans les URI soient codés. Cela affecte le schéma d'URI "mailto" pour certains caractères courants qui pourraient apparaître dans les adresses, les champs d'en-tête, ou le contenu des messages. Un de ces caractères est espace (" ", ASCII hex 20). Noter que les exemples ci-dessous utilisent "%20" pour espace dans le corps de message. Noter aussi que les coupures de ligne dans le corps d'un message DOIVENT être codées avec "%0D%0A". Les mises en œuvre PEUVENT ajouter une coupure de ligne finale au corps d'un message même si il n'y a pas de "%0D%0A" en queue dans le corps <hfield> de l'URI "mailto". Les coupures de ligne dans d'autres <hfield> NE DEVRAIENT PAS être utilisées.

Quand on crée les URI "mailto", tous les caractères réservés qui sont utilisés dans les URI DOIVENT être codés afin que les interpréteurs d'URI écrits correctement puissent les lire. Aussi, le logiciel client qui lit les URI DOIT décoder les chaînes avant de créer le message électronique afin qu'il apparaisse sous une forme que le logiciel du receveur puisse comprendre. Ces chaînes DEVRAIENT être décodées avant de montrer le message à l'envoyeur.

Le logiciel qui crée les URI "mailto" doit de même être attentif à coder tout caractères réservé qui serait utilisé. Les formulaires HTML sont un des logiciels qui créent des URI "mailto". Les mises en œuvre actuelles codent un caractère espace par '+', mais cela crée des problèmes parce que un tel '+' à la place d'une espace ne peut pas être distingué d'un '+' réel dans un URI "mailto". Quand on produit des URI "mailto", toutes les espaces DEVRAIENT être codées comme %20, et les caractères '+' PEUVENT être codés par %2B. On notera que les caractères '+' sont fréquemment utilisés au titre d'une adresse de messagerie électronique pour indiquer une sous adresse, comme par exemple dans <paul+ietf@exemple.org>.

Le schéma d'URI "mailto" est limité en ce qu'il ne fournit pas de substitution des variables. Donc, il est impossible de créer  un URI "mailto" qui inclue l'adresse de messagerie d'un usage dans le corps de message. Cette limitation empêche aussi les URI "mailto" qui sont signés avec des clés publiques et autres informations variables.

 	6.	Exemples
 	6.1	Exemples de base
Un URI pour une adresse ordinaire individuelle de messagerie :

<mailto:chris@exemple.com>

Un URI pour un système de réponse de messagerie qui exige le nom du fichier à renvoyer dans le sujet :

<mailto:infobot@exemple.com?subject=current-issue>

Un système de réponse de messagerie qui exige une demande "send" dans le corps :

<mailto:infobot@exemple.com?body=send%20current-issue>

Un URI similaire, avec deux lignes ayant des demandes "send" différentes (dans ce cas, "send current-issue" et, sur la ligne suivante, "send index"):

<mailto:infobot@exemple.com?body=send%20current-issue
%0D%0Asend%20index>

Une utilisation intéressante des URI "mailto" se produit quand on parcourt les archives de messages. Un lien peut être fourni qui permet de répondre à un message tout en conservant les informations de trace. Cela se fait en ajoutant un champ d'en-tête In-Reply-To contenant l'identifiant de message (Message-ID) du message où le lien est ajouté, par exemple :

<mailto:list@exemple.org?In-Reply-To=%3C3469A91.D10AF4C@exemple.com%3E>

Une demande pour souscrire à une liste de diffusion :

<mailto:majordomo@exemple.com?body=subscribe%20bamboo-l>

Un URI qui est pour un seul utilisateur et qui inclut un CC (en copie) d'un autre utilisateur :

<mailto:joe@exemple.com?cc=bob@exemple.com&body=hello>

Noter l'utilisation du caractère réservé "&" ci-dessus. L'exemple qui suit, qui utilisé deux fois "?", est incorrect :

<mailto:joe@exemple.com?cc=bob@exemple.com?body=hello>	; MAUVAIS !

Conformément à la [RFC5322], les caractères "?", "&", et même "%" peuvent apparaître dans les spécifications d'adresse. Le fait qu'ils soient des caractères réservés n'est pas un problème : ces caractères peuvent apparaître dans les URI "mailto" – mais pas sous une forme non codée. Le mécanisme standard de codage d'URI ("%" suivi par un nombre hexadécimal de deux chiffres) DOIT être utilisé dans ces cas.

Pour indiquer l'adresse "gorby%kremvax@exemple.com" on utiliserait :

<mailto:gorby%25kremvax@exemple.com>

Pour indiquer l'adresse "improbable?adresse@exemple.com", et inclure un autre champ d'en-tête, on utiliserait :

<mailto:improbable%3Fadresse@exemple.com?blat=foop>

Comme décrit plus haut, le caractère "&" (esperluette) est réservé dans HTML et doit être remplacé, par exemple, par "&amp;". Donc, un URI avec une esperluette interne pourrait ressembler à :

   Click
   <a href="mailto:joe@an.exemple?cc=bob@an.exemple&amp;body=hello"
   >mailto:joe@an.exemple?cc=bob@an.exemple&amp;body=hello</a> pour envoyer un message d'accueil à Joe et Bob.

Quand une adresse de messagerie comporte elle-même un caractère "&" (esperluette) ce caractère doit être codé en pourcentage. Par exemple, l'URI "mailto" pour envoyer un message à "Mike&family@exemple.org" est <mailto:Mike%26family@exemple.org>.

 	6.2	Exemples d'adresse de messagerie électronique compliquées
Exemples de la façon de traiter les adresses de messagerie qui contiennent une syntaxe d'échappement compliquée.

Adresse de messagerie : "not@me"@exemple.org ; l'URI "mailto" correspondant est :

<mailto:%22not%40me%22@exemple.org>.

Adresse de messagerie : "oh\\no"@exemple.org ; l'URI "mailto" correspondant est :

<mailto:%22oh%5C%5Cno%22@exemple.org>.

Adresse de messagerie : "\\\"it's\ ugly\\\""@exemple.org ; l'URI "mailto" correspondant est :

<mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@exemple.org>.

 	6.3	Exemples avec codage en pourcentage fondé sur UTF-8
Envoi d'un message avec le sujet "coffee" en français c'est-à-dire, "café" où le e final est un 'e accent aigu, en utilisant UTF-8 et codage en pourcentage :

<mailto:user@exemple.org?subject=caf%C3%A9>

Le même sujet, cette fois en utilisant un mot codé (échappant les caractères "=" et "?" utilisés dans la syntaxe de mot codé, parce qu'ils sont réservés) :

<mailto:user@exemple.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D>

Le même sujet, cette fois codé comme iso-8859-1 :

<mailto:user@exemple.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D>

En revenant à l'UTF-8 pur et en ajoutant un corps avec la même valeur :

<mailto:user@exemple.org?subject=caf%C3%A9&body=caf%C3%A9>

Cet URI "mailto" peut résulter en un message ressemblant à :

From: sender@exemple.net
To: user@exemple.org
Subject: =?utf-8?Q?caf=C3=A9?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

caf=C3=A9

Le logiciel qui envoie le message électronique n'est pas restreint à l'UTF-8, mais peut utiliser d'autres codages. On montre ci-après le même message utilisant deux fois iso-8859-1 :

From: sender@exemple.net
To: user@exemple.org
Subject: =?iso-8859-1?Q?caf=E9?=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

caf=E9

Différents codages de transfert de contenu (c'est-à-dire, "8bit" ou "base64" au lieu de "quoted-printable") et différents codages dans des mots codés (c'est-à-dire, "B" au lieu de "Q") peuvent aussi être utilisés.

Pour plus d'exemples de codage du mot café dans différentes langues, voir la [RFC2324].

L'exemple suivant utilise le mot japonais "natto" (caractères Unicode U+7D0D U+8C46) comme étiquette de nom de domaine, envoyant un message à un utilisateur à "natto".exemple.org:

<mailto:user@%E7%B4%8D%E8%B1%86.exemple.org?subject=Test&body=NATTO>

Quand on construit le message, l'étiquette de nom de domaine est convertie en punycode. Le message résultant peut ressembler à :

From: sender@exemple.net
To: user@xn--99zt52a.exemple.org
Subject: Test
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

NATTO

 	7.	Considérations sur la sécurité

Le schéma d'URI "mailto" peut être utilisé pour envoyer un message d'un utilisateur à un autre, et donc peut introduire de nombreux problèmes de sécurité. Les messages électroniques peuvent être enregistrés au site d'origine, au site receveur, et dans des sites intermédiaires le long du chemin de livraison. Si les messages ne sont pas chiffrés, ils peuvent aussi être lus dans tous ces sites.

Un URI "mailto" donne un gabarit pour un message qui peut être envoyé par le logiciel client de messagerie. Le contenu de ce gabarit peut être opaque ou difficile à lire par l'utilisateur au moment de la spécification de l'URI, ainsi qu'être caché dans l'interface d'utilisateur (par exemple, un lien sur une page HTML de la Toile pourrait afficher quelque chose d'autre que le contenu de l'URI "mailto" correspondant qui serait utilisé quand on clique dessus). Donc, un client de messagerie NE DEVRAIT PAS envoyer un message sur la base d'un URI "mailto" sans d'abord divulguer et montrer à l'utilisateur le message complet qui va être envoyé (incluant tous les champs d'en-tête qui étaient spécifiés par l'URI "mailto") pleinement décodé, et en demandant à l'utilisateur son approbation de l'envoi du message comme message électronique. Le client de messagerie DEVRAIT aussi rendre clair que l'utilisateur est sur le point d'envoyer un message électronique, car l'utilisateur peut ne pas savoir que c'est le résultat d'un URI "mailto". Les utilisateurs sont fortement encouragés à s'assurer que l'URI "mailto" qui leur est présenté correspond à l'adresse incluse dans la ligne "To:" du message.

Certains champs d'en-tête sont de nature non sûre pour être inclus dans un message généré à partir d'un URI. Pour les détails, voir la Section 3. En général, moins il y a de champs d'en-tête interprétés d'après l'URI, moins il est probable qu'un agent envoyeur va créer un message non sûr.

Des exemples de problèmes avec l'envoi de messages non approuves incluent :
des messages qui violent les lois de livraison, comme de faire des menaces illégales ;
des messages qui identifient l'envoyeur comme quelqu'un qui est intéressé à violer les lois ;
des messages qui identifient l'envoyeur à un tiers non désiré ;
des messages qui causent l'imputation d'un coût financier à l'envoyeur ;
des messages qui causent une action sur la machine du receveur, causant des dommages qui pourraient être attribués à l'envoyeur.

Les programmes qui interprètent les URI "mailto" DEVRAIENT s'assurer que l'adresse du chemin de retour de l'enveloppe SMTP, qui est donnée comme argument de la commande SMTP MAIL FROM, est établie et correcte, et que le message électronique résultant est un message complet, utilisable.

Les URI "mailto" sur les pages publiques de la Toile exposent les adresses de messagerie au ramassage. Cela s'applique à toutes les adresses de messagerie qui font partie de l'URI "mailto", incluant les adresses dans une <hfvalue> "bcc". Ces adresses ne vont pas être envoyées aux receveurs dans le champ 'to' et dans les <hfvalue> "to" et "cc", mais vont quand même être publiquement visibles dans l'URI. Les adresses dans une <hfvalue> "bcc" peuvent aussi fuiter à d'autres adresses dans la même <hfvalue> ou devenir autrement connues, selon l'agent d'utilisateur de messagerie utilisé.

Les programmes qui manipulent les URI "mailto" doivent faire très attention à ne pas, par inadvertance, faire un double échappement ou un double dés-échappement des URI "mailto", et de s'assurer que les conventions d'échappement et de dés-échappement relatives aux URI et aux adresses de messagerie sont appliquées dans le bon ordre.

Les mises en œuvre qui analysent les URI "mailto" doivent faire attention aux vérifications de bonne santé des URI "mailto" afin d'éviter des débordements de mémoire tampon et les problèmes qui en résultent (par exemple, exécution de code spécifié par l'attaquant).

Les considérations sur la sécurité des [RFC3986], [RFC5890], [RFC5891], et [RFC3987] s'appliquent aussi. Il est conseillé aux développeurs et utilisateurs de les vérifier avec soin.

 	8.	Considérations relatives à l'IANA
 	8.1	Mise à jour de l'enregistrement du schéma d'URI 'mailto'
Le présent document change la définition du schéma d'URI "mailto" ; le registre des schémas d'URI a été mis à jour pour se référer au présent document plutôt qu'à son prédécesseur, la [RFC2368]. Le gabarit d'enregistrement est comme suit :

Nom de schéma d'URI : 'mailto'
Statut : permanent
Syntaxe de schéma d'URI : voir la Section Syntaxe de la RFC 6068.
Sémantique de schéma d'URI : voir la Section Sémantique de la RFC 6068.
Considérations de codage : voir les Sections Syntaxe et Codage de la RFC 6068.
Applications/protocoles qui utilisent ce schéma d'URI : le schéma d'URI "mailto" est largement utilisé depuis le début de la Toile.
Considérations d'interopérabilité : l'interopérabilité des URI "mailto" avec le codage en pourcentage fondé sur UTF-8 pourrait être un peu inférieure à l'interopérabilité des URI "mailto" avec seulement US-ASCII.
Considérations sur la sécurité : voir la Section Considérations sur la sécurité de la RFC 6068.
Contact : IETF
Auteur/contrôleur des changements : IETF
Référence : RFC 6068

 	8.2	Enregistrement du champ d'en-tête de corps
L'IANA a enregistré le champ d'en-tête Body dans le registre de champs d'en-tête de message ([RFC3864]) comme suit :

Nom de champ d'en-tête : Body
Protocole applicable : aucun. Cet enregistrement est fait pour s'assurer que ce nom de champ d'en-tête n'est pas utilisé du tout, afin de ne pas créer de problème pour les URI "mailto".
Statut : réservé
Auteur/contrôleur des changements : IETF
Document de spécification : RFC 6068
Informations en rapport : aucune

 	9.	Principaux changements par rapport à la RFC 2368

Les principaux changements par rapport à la RFC 2368 sont les suivants :
o	Changement de la syntaxe de la RFC 2822 <mailbox> en <addr-spec> de la [RFC5322].
o	Le codage en pourcentage fondé sur UTF-8 est permis pour les noms de domaines et dans <hfvalue>.
o	Réduction du codage en pourcentage dans la <local-part> à se fonder sur UTF-8, réservé pour si et quand il y a une spécification pour l'internationalisation des adresses de messagerie électronique.
o	Suppression de l'interdiction des champs d'en-tête "Bcc:", mais ajout d'un avertissement sur leur visibilité et leur collecte pour les pourriels.
o	Ajout de précisions sur l'échappement.

 	10.	Remerciements

Le présent document dérive de la [RFC2368] ; les remerciements de cette spécification s'appliquent ici aussi. De plus, nous remercions Paul Hoffman de son travail sur la [RFC2368].

Des apports précieux sur le présent document ont été reçus (sans ordre particulier) de : Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg, Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony Puls II, Eliot Lear, Dave Crocker, Dan Harkins, Nevil Brownlee, John Klensin, Alfred Hoenes, Ned Freed, Sean Turner, Peter Saint-Andre, Adrian Farrel, Avshalom Houri, Robert Sparks, et de nombreux autres.

 	9.	Références
 	9.1	Références normatives

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003.

[RFC3864]	G. Klyne, M. Nottingham, J. Mogul, "Procédures d'enregistrement pour les champs d'en-tête de message", septembre  2004. (BCP0090)

[RFC3986]	T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005. (P.S.  ; MàJ par RFC8820)

[RFC3987]	M. Düerst et M. Suignard, "Identifiant de ressource internationalisé (IRI)", janvier 2005.

[RFC5234]	D. Crocker, éd., P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008. (Remplace RFC2822) (MàJ RFC4021) (D.S.)

[RFC5890]	J. Klensin, "Noms de domaine internationalisés pour les applications (IDNA) : Définitions et cadre documentaire", août  2010. (Remplace RFC3490) (P.S.)

[RFC5891]	J. Klensin, "Noms de domaine internationalisés pour les applications (IDNA) : Le protocole", août 2010. (Remplace RFC3490, RFC3491) (MàJ RFC3492) (P.S.)

 	11.2	Références pour information

[RFC2324]	L. Masinter, "Protocole de contrôle hyper texte de la cafetière (HTCPCP/1.0)", 1er avril 1998. (Info. MàJ par 7168)

[RFC2368]	P. Hoffman, L. Masinter, J. Zawinski, "Le schéma d'URL mailto", juillet 1998. (P.S.) (Obsolète, voir la RFC6068)

[RFC4952]	J. Klensin, Y. Ko, "Généralités et cadre pour la messagerie électronique internationalisée", juillet 2007. (Remplacée par la RFC6530) (Information)

 	Adresse des auteurs
Martin Düerst 	Larry Masinter	Jamie Zawinski	
Aoyama Gakuin University	Adobe Systems Incorporated	DNA Lounge	
5-10-1 Fuchinobe	345 Park Ave	375 Eleventh Street	
Sagamihara, Kanagawa  229-8558	San Jose, CA  95110	San Francisco, CA  94103	
Japon	USA	USA	
mél : duerst@it.aoyama.ac.jp 	mél : LMM@acm.org 	mél : jwz@jwz.org