One document matched: draft-duerst-eai-mailto-04.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet href="rfc2629.css" type="text/css"?>
<?rfc symrefs='yes'?>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc sortrefs='yes'?>
<rfc ipr="pre5378Trust200902" docName="draft-duerst-eai-mailto-04" category="std" xml:lang="en"
obsoletes="6068">
<front>
<title>The 'mailto' URI/IRI Scheme</title>
<author initials="M.J." isurname="Dürst" surname="Duerst" ifullname="Martin J. Dürst" fullname="Martin J. Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.)">
<organization>Aoyama Gakuin University<ionly> (青山学院大学)</ionly> </organization>
<address>
<postal>
<street>5-10-1 Fuchinobe</street>
<street>Chuo-ku</street>
<city>Sagamihara</city>
<region>Kanagawa</region>
<code>252-5258</code>
<country>Japan</country>
</postal>
<phone>+81 42 759 6329</phone>
<facsimile>+81 42 759 6495</facsimile>
<email>duerst@it.aoyama.ac.jp</email>
<uri>http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/</uri>
</address>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization>Adobe Systems Incorporated</organization>
<address><postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country>
</postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri>
</address>
</author>
<author initials="J." surname="Zawinski" fullname="Jamie Zawinski">
<organization>DNA Lounge</organization>
<address>
<postal>
<street>375 Eleventh Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94103</code>
<country>USA</country>
</postal>
<email>jwz@jwz.org</email>
</address>
</author>
<date year="2012" month="September"/>
<area>Applications</area>
<keyword>mailto</keyword>
<keyword>Email Address</keyword>
<keyword>URI Scheme</keyword>
<keyword>IRI Scheme</keyword>
<abstract>
<t>This document defines the format of Uniform Resource Identifiers
(URIs) and Internationalized Resource Identfiers (IRIs) to identify
resources that are reached using Internet mail.
It adds the possibility to use Email Address Internationalization (EAI)
email addresses (RFC6530)
to the previous syntax of 'mailto' URIs (RFC 6068).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The 'mailto' URI/IRI scheme is a URI/IRI scheme <xref target="RFC4395bis"/> used to identify
resources that are reached using Internet mail. In its simplest form, a 'mailto' URI/IRI
contains an Internet mail address. For interactions that require message headers or
message bodies to be specified, the 'mailto' URI/IRI scheme also allows providing mail
header fields and a message body.</t>
<t>This specification extends the previous scheme definition (<xref target="RFC6068"/>)
to also allow non-ASCII characters in the left-hand sides (LHSs) of email addresses.
To work seamlessly with Internationalized Resource Identfiers (IRIs, <xref target="RFC3987"/>)
and Email Address Internationalization (EAI, <xref target="RFC6530"/>),
these LHSs are percent-encoded based on UTF-8 <xref target="STD63"/> when used in URIs.</t>
<t>This document is available in (line-printer ready) plaintext ASCII and PDF.
It is also available in HTML from
<eref target="http://www.sw.it.aoyama.ac.jp/2012/pub/draft-duerst-eai-mailto-04.html"
>http://www.sw.it.aoyama.ac.jp/2012/pub/draft-duerst-eai-mailto-04.html</eref>,
and in UTF-8 plaintext from
<eref target="http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-duerst-eai-mailto-04.utf8.txt"
>http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-duerst-eai-mailto-04.utf8.txt</eref>.
While all these versions are identical in their technical content,
the HTML, PDF, and UTF-8 plaintext versions show non-Unicode characters directly.
This often makes it easier to understand examples, and readers are therefore advised
to consult these versions in preference or as a supplement to the ASCII version.</t>
<t>Example URIs and IRIs are enclosed in '<' and '>' as described in
Appendix C of <xref target="STD66"/>.
Extra whitespace and line breaks are added to
present long URIs -- they are not part of the actual URI.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/>.</t>
</section>
<section title="Syntax of a 'mailto' URI" anchor="syntax">
<section title="Syntax Rules">
<t>The syntax of a 'mailto' URI is described using the
ABNF of <xref target="STD68"/>. The syntax of a 'mailto' IRI
can be obtained from this definition by allowing <iunreserved>
characters wherever <unreserved> characters are allowed.
The syntax below also uses non-terminal
definitions from <xref target="STD66"/>
(unreserved, pct-encoded):
</t>
<figure>
<artwork> mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec-enc *("," addr-spec-enc )
hfields = "?" hfield *( "&" hfield )
hfield = hfname "=" hfvalue
hfname = *qchar
hfvalue = *qchar
addr-spec-enc = local-part-enc "@" domain-enc
local-part-enc = dot-atom-text-enc / quoted-string-enc
domain-enc = dot-atom-text-enc / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 ; Printable US-ASCII
/ %d94-126 ; characters not including
; "[", "]", or "\"
dot-atom-text-enc = <percent-encoded version of
dot-atom-text or its EAI equivalent>
quoted-string-enc = <percent-encoded version of
dot-atom-text or its EAI equivalent>
qchar = unreserved / pct-encoded / some-delims
some-delims = "!" / "$" / "'" / "(" / ")" / "*"
/ "+" / "," / ";" / ":" / "@" / "/" / "?"</artwork>
</figure>
<t>In addition to the above syntax rules, the details given in the next two subsections are relevant.</t>
</section>
<section title="Additional Details about <addr-spec-enc>">
<t><addr-spec-enc> is a mail address as specified by <addr-spec>
in <xref target="RFC5322"/>
or <uAddr-Spec> in <xref target="RFC6532"/>, but excluding <comment>,
with the following changes:</t>
<t><list style="numbers">
<t>A number of characters that can appear in <addr-spec> MUST be percent-encoded.
These are the characters that cannot appear in a URI according to <xref target="STD66"/>
as well as "%" (because it is used for percent-encoding) and all the characters in gen-delims
except "@" and ":" (i.e., "/", "?", "#", "[", and "]").
Of the characters in sub-delims, at least the following also have to be percent-encoded:
"&", ";", and "=". Care has to be taken both when encoding as well as when decoding
to make sure these operations are applied only once.</t>
<t><obs-local-part> and <NO-WS-CTL> as defined in <xref target="RFC5322"/> MUST NOT be used.</t>
<t>Whitespace and comments within <local-part-enc> and <domain-enc> MUST NOT be used.
They would not have any operational semantics.</t>
<t>Percent-encoding can be used in the <domain-enc> part of an <addr-spec-enc>,
in order to denote an internationalized domain name.
The considerations for <reg-name> in <xref target="STD66"/> apply.
In particular, non-ASCII characters MUST first be encoded according to UTF-8
<xref target="STD63"/>, and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded
to be represented as URI characters. URI-producing applications MUST NOT use percent-encoding
in domain names unless it is used to represent a UTF-8 character sequence.
When the internationalized domain name is used to compose a message,
the name MUST be transformed to the Internationalizing Domain Names in Applications (IDNA) encoding
<xref target="RFC5891"/> where appropriate.
URI producers SHOULD provide these domain names in the IDNA encoding, rather than percent-encoded,
if they wish to maximize interoperability with legacy 'mailto' URI interpreters.</t>
<t>Percent-encoding of non-ASCII octets in the <local-part-enc> of an <addr-spec-enc>
is used for the internationalization of the <local-part-enc> according to Email Address
Internationalization (EAI; <xref target="RFC6532"/>).
Non-ASCII characters MUST first be encoded according to UTF-8 <xref target="STD63"/>,
and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded
to be represented as URI characters. Any other percent-encoding of non-ASCII characters is prohibited.
When a <local-part-enc> containing non-ASCII characters will be used to compose a message,
the <local-part-enc> MUST be transformed back to UTF-8 in order to conform to EAI.</t>
</list>
</t>
<t><dot-atom-text-enc> is the percent-encoded version of <dot-atom-text> in
<xref target="RFC5322"/> or <uDot-Atom-text> in <xref target="RFC6532"/>.
<quoted-string-enc> is the percent-encoded version of <quoted-string> in
<xref target="RFC5322"/> or <uQuoted-String> in <xref target="RFC6532"/>.
</t>
</section>
<section title="Additional Details about <hfname> and <hfvalue>" anchor="hfvalue">
<t><hfname> and <hfvalue> are encodings of an <xref target="RFC5322"/>
header field name and value, respectively. Percent-encoding is needed
for the same characters as listed above for <addr-spec-enc>. <hfname> is
case-insensitive, but <hfvalue> in general is case-sensitive.
Note that <xref target="RFC5322"/>
allows all US-ASCII printable characters except ":" in optional header
field names (Section 3.6.8), which is the reason why <pct-encoded> is part of the
header field name production. </t>
<t>The special <hfname> "body" indicates that the associated <hfvalue> is the body
of the message. The "body" field value is intended to contain the content for the first
text/plain body part of the message. The "body" pseudo header field is primarily intended
for the generation of short text messages for automatic processing (such as "subscribe"
messages for mailing lists), not for general MIME bodies.
Except for the encoding of
characters based on UTF-8 and percent-encoding, no additional encoding
(such as e.g., base64 or quoted-printable; see <xref target="RFC2045"/>) is used for the
"body" field value. As a consequence, header fields related to message encoding
(e.g., Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST be ignored.
The "body" pseudo header field name has been registered with IANA for this special purpose
(see <xref target="bodyRegister"/>).</t>
<t>Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, serving as delimiters.
They have to be escaped (as "%3F", "%3D", and "%26", respectively) when not serving as delimiters.</t>
<t>Additional restrictions on what characters are allowed might apply depending on the context
where the URI is used. Such restrictions can be addressed by context-specific escaping mechanisms.
For example, because the "&" (ampersand) character is reserved in HTML and XML, any 'mailto'
URI that contains an ampersand has to be written with an HTML/XML entity ("&") or numeric
character reference ("&" or "&").</t>
<t>Non-ASCII characters can be encoded in <hfvalue> as follows:
<list style="numbers">
<t>MIME encoded words (as defined in <xref target="RFC2047"/>)
are permitted in header field values, but not in an <hfvalue> of a "body"
<hfname>. Sequences of characters that look like MIME encoded words can appear in an
<hfvalue> of a "body" <hfname>, but in that case have no special meaning. Please note
that the '=' and '?' characters used as delimiters in MIME encoded words have to be
percent-encoded. Also note that the use of MIME encoded words differs slightly
for so-called structured and unstructured header fields.</t>
<t>Non-ASCII characters MUST be encoded according to UTF-8 <xref target="STD63"/>
, and then each octet of the corresponding UTF-8 sequence
is percent-encoded to be represented as URI characters.
When header field values encoded in this way are used to compose a message conforming to
<xref target="RFC5322"/>, the <hfvalue>
has to be suitably encoded (transformed into MIME encoded words <xref target="RFC2047"/>),
except for an <hfvalue> of a "body" <hfname>, which has to be encoded according to
<xref target="RFC2045"/>. Please note that for MIME encoded words and for bodies in
composed email messages, encodings other than UTF-8 MAY be used
as long as the characters are properly transcoded.
When header field values encoded in this way are used to compose a message conforming to
<xref target="RFC6532"/>, percent-encoding (including reserved characters) has to be decoded.
The header field values can then be used directly because EAI allows UTF-8 in header field
values.</t>
</list>
</t>
<t>Note that it is syntactically valid to specify both <to> and an <hfname> whose value is "to". That is,</t>
<t><spanx style="verb"><mailto:addr1@an.example,addr2@an.example></spanx></t>
<t>is equivalent to</t>
<t><spanx style="verb"><mailto:?to=addr1@an.example,addr2@an.example></spanx></t>
<t>is equivalent to</t>
<t><spanx style="verb"><mailto:addr1@an.example?to=addr2@an.example></spanx></t>
<t>However, the latter two forms are NOT RECOMMENDED because different user agents handle this case
differently. In particular, some existing clients ignore "to" <hfvalue>s.</t>
<t>Implementations MUST NOT produce two "To:" header fields in a message;
the "To:" header field may occur at most once in a message (<xref target="RFC5322"/>, Section 3.6).
Also, creators of 'mailto' URIs MUST NOT include other message header fields multiple times
if these header fields can only be used once in a message.</t>
<t>To avoid interoperability problems, creators of 'mailto' URIs SHOULD NOT use the same <hfname>
multiple times in the same URI. If the same <hfname> appears multiple times in a URI,
behavior varies widely for different user agents, and for each <hfname>.
Examples include using only the first or last <hfname>/<hfvalue> pair,
creating multiple header fields, and combining each <hfvalue> by simple concatenation
or in a way appropriate for the corresponding header field. </t>
<t>Note that this specification, like any URI/IRI scheme specification, does
not define syntax or meaning of a fragment identifier (see <xref target="STD66"/>),
because these depend on the type of a retrieved representation.
In the currently known usage scenarios, a 'mailto' URI cannot be used to retrieve
such representations. The character "#" in <hfvalue>s MUST be escaped as %23.</t>
</section>
</section>
<section title="Semantics and Operations" anchor="semantics">
<t>A 'mailto' URI/IRI designates an "Internet resource", which is the mailbox specified in the address.
When additional header fields are supplied, the resource designated is the same address
but with an additional profile for accessing the resource. While there are Internet resources
that can only be accessed via electronic mail, the 'mailto' URI is not intended as a way of
retrieving such objects automatically.</t>
<t>The operation of how any URI/IRI scheme is resolved is not mandated by the URI specifications.
In current practice, resolving URIs/IRIs such as those in the 'http' URI/IRI scheme causes
an immediate interaction between client software and a host running an interactive server.
The 'mailto' URI/IRI has unusual semantics
because resolving such a URI/IRI does not necessarily cause an immediate interaction with a server.
Instead, the client creates a message to the designated address with the various header fields set as default.
The user can edit the message, send the message unedited, or choose not to send the message.</t>
<t>Note that with the introduction of the possibility to register handlers of URI/IRI schemes
to web applications, there is no longer a guarantee that the resolution of a 'mailto' URI/IRI
is purely local. Registering a web mail service as a handler of 'mailto' URIs/IRIs
means that the creation of a message to the designated address is done with the help and
knowledge of that web mail service.</t>
<t>The <hfname>/<hfvalue> pairs in a 'mailto' URI/IRI, although syntactically equivalent
to header fields in a mail message,
do not directly correspond to the header fields in a mail message.
In particular, the To, Cc, and Bcc <hfvalue>s
don't necessarily result in a header field containing the specified value.
Mail client software MAY eliminate duplicate addresses.
Creators of 'mailto' URIs SHOULD avoid using the same address twice in a 'mailto'
URI/IRI.</t>
<t>Originator fields like From and Date, fields related to routing (Apparently-To, Resent-*, etc.),
trace fields, and MIME header fields (MIME-Version, Content-*),
when present in the URI/IRI, MUST be ignored.
The mail client MUST create new fields when necessary, as it would for any new message.
Unrecognized header fields and header fields with values inconsistent with those
the mail client would normally send SHOULD be treated as especially suspect.
For example, there may be header fields that are totally safe but not known
to the MUA, so the MUA MAY choose to show them to the user.</t>
</section>
<section title="Unsafe Header Fields">
<t>The user agent interpreting a 'mailto' URI/IRI SHOULD NOT create a message
if any of the header fields are considered dangerous; it MAY also choose to create a message
with only a subset of the header fields given in the URI/IRI. Only a limited set of header fields
such as Subject and Keywords, as well as Body, are believed to be both safe and useful in the general case.
In cases where the source of a URI/IRI is well known, and/or specific header fields are limited
to specific well-known values, other header fields MAY be considered safe, too.</t>
<t>The creator of a 'mailto' URI/IRI cannot expect the resolver of a URI/IRI to understand more
than the "subject" header field and "body".
Clients that resolve 'mailto' URIs/IRIs into mail messages MUST be able to correctly create
<xref target="RFC5322"/>-compliant mail messages using the "subject" header field and "body".</t>
</section>
<section title="Encoding" anchor="encoding">
<t><xref target="STD66"/> requires that many characters in URIs/IRIs be encoded.
This affects the 'mailto' URI/IRI scheme for some common characters that might appear in addresses,
header fields, or message contents. One such character is space (" ", ASCII hex 20).
Note the examples below that use "%20" for space in the message body.
Also note that line breaks in the body of a message MUST be encoded with "%0D%0A".
Implementations MAY add a final line break to the body of a message
even if there is no trailing "%0D%0A" in the body <hfield> of the 'mailto' URI/IRI.
Line breaks in other <hfield>s SHOULD NOT be used.</t>
<t>When creating 'mailto' URIs/IRIs, any reserved
characters that are used in the URIs/IRIs MUST be encoded so that properly written URI/IRI
interpreters can read them. Also, client software that reads URIs/IRIs
MUST decode strings before creating the mail message so
that the mail message appears in a form that the recipient software will
understand. These strings SHOULD be decoded before showing the message to
the sending user.</t>
<t>Software creating 'mailto' URIs/IRIs likewise has to be careful to encode
any reserved characters that are used. HTML forms are one kind of software that creates
'mailto' URIs/IRIs.
Current implementations encode a space as '+', but this creates problems
because such a '+' standing for a space cannot be distinguished from a real '+' in a 'mailto'
URI/IRI.
When producing 'mailto' URIs/IRIs, all spaces SHOULD be encoded as %20,
and '+' characters MAY be encoded as %2B.
Please note that '+' characters are frequently used as part of an email
address to indicate a subaddress, as for example in <bill+ietf@example.org>.</t>
<t>The 'mailto' URI/IRI scheme is limited in that it does not provide for
substitution of variables. Thus, it is impossible to create a 'mailto' URI/IRI
that includes a user's email address in the message body. This
limitation also prevents 'mailto' URIs/IRIs that are signed with public keys
and other such variable information.</t>
</section>
<section title="Examples">
<section title="Conventions Used">
<t>To represent characters outside US-ASCII in a document format
that is limited to US-ASCII, this document
uses 'XML Notation'. A non-ASCII character is denoted by a leading '&#x',
a trailing ';', and the hexadecimal number of the character in the UCS in between.
For example, Я stands for CYRILLIC CAPITAL LETTER YA<ionly> (Я)</ionly>.
An actual '&' is denoted by '&'. This notation is only used
in the ASCII version(s) of this document, because in the other versions,
non-ASCII characters are used directly.</t>
<t>Where the IRI form of an example is identical to the URI form, only one form is given.
If the IRI form is different, then both forms are given.</t>
</section>
<section title="Basic Examples"><t>
A URI for an ordinary individual mailing address:</t>
<t><spanx style="verb"><mailto:chris@example.com></spanx></t>
<t>A URI for a mail response system that requires the name of the file to be sent back
in the subject:</t>
<t><spanx style="verb"><mailto:infobot@example.com?subject=current-issue></spanx></t>
<t>A mail response system that requires a "send" request in the body:</t>
<t><spanx style="verb"><mailto:infobot@example.com?body=send%20current-issue></spanx></t>
<t>A similar URI, with two lines with different "send" requests (in
this case, "send current-issue" and, on the next line, "send index"):</t>
<t><spanx style="verb"><mailto:infobot@example.com?body=send%20current-issue%0D%0Asend%20index></spanx></t>
<t>An interesting use of 'mailto' URIs occurs when browsing archives of
messages. A link can be provided that allows replying to a message and conserving
threading information. This is done by adding an In-Reply-To header field containing
the Message-ID of the message where the link is added, for example:</t>
<t><spanx style="verb"><mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@example.com%3E></spanx></t>
<t>A request to subscribe to a mailing list:</t>
<t><spanx style="verb"><mailto:majordomo@example.com?body=subscribe%20bamboo-l></spanx></t>
<t>A URI that is for a single user and that includes a CC of another user:</t>
<t><spanx style="verb"><mailto:joe@example.com?cc=bob@example.com&body=hello></spanx></t>
<t>Note the use of the "&" reserved character above. The following
example, using "?" twice, is incorrect:</t>
<t><spanx style="verb"><mailto:joe@example.com?cc=bob@example.com?body=hello></spanx> ; WRONG!</t>
<t>According to <xref target="RFC5322"/>, the characters "?", "&",
and even "%" may occur
in <addr-spec>s. The fact that they are reserved characters is not a problem:
those characters may appear in 'mailto' URIs --
they just may not appear in unencoded form. The standard URI encoding
mechanisms ("%" followed by a two-digit hex number) MUST be used in
these cases.</t>
<t>To indicate the address "gorby%kremvax@example.com" one would use:</t>
<t><spanx style="verb"><mailto:gorby%25kremvax@example.com></spanx></t>
<t>To indicate the address "unlikely?address@example.com", and include
another header field, one would use:</t>
<t><spanx style="verb"><mailto:unlikely%3Faddress@example.com?blat=foop></spanx></t>
<t>As described above, the "&" (ampersand) character is reserved in HTML
and has to be replaced, e.g., with "&". Thus, in an HTML context a URI with an
internal ampersand might look like:</t>
<figure>
<artwork> Click <a
href="mailto:joe@an.example?cc=bob@an.example&body=hello"
>mailto:joe@an.example?cc=bob@an.example&body=hello</a>
to send a greeting message to Joe and Bob.
</artwork>
</figure>
<t>When an email address itself
includes an "&" (ampersand) character, that character has to be percent-encoded.
For example, the 'mailto' URI to send mail to <spanx style="verb">"Mike&family@example.org"</spanx>
is <spanx style="verb"><mailto:Mike%26family@example.org></spanx>.</t>
</section>
<section title="Examples of Complicated Email Addresses">
<t>Following are a few examples of how to treat email addresses
that contain complicated escaping syntax.</t>
<t>Email address: <spanx style="verb">not@me"@example.org</spanx>; corresponding 'mailto' URI:</t>
<t><spanx style="verb"><mailto:%22not%40me%22@example.org></spanx>.</t>
<t>Email address: <spanx style="verb">"oh\\no"@example.org</spanx>; corresponding 'mailto' URI:</t>
<t><spanx style="verb"><mailto:%22oh%5C%5Cno%22@example.org></spanx>.</t>
<t>Email address: <spanx style="verb">"\\\"it's\ ugly\\\""@example.org</spanx>; corresponding 'mailto' URI:</t>
<t><spanx style="verb"><mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org></spanx>.</t>
</section>
<section title="Examples Using UTF-8-Based Percent-Encoding usable with RFC 5322">
<t>Sending a mail with the subject "coffee" in French,
i.e., "cafe" where the final e is an e-acute, using UTF-8 and
percent-encoding, as an URI:</t>
<t><spanx style="verb"><mailto:user@example.org?subject=caf%C3%A9></spanx></t>
<t>The same as an IRI:</t>
<t><spanx style="verb"><mailto:user@example.org?subject=caf<aonly>é</aonly><ionly>é</ionly>></spanx></t>
<t>The same subject, this time using an encoded-word
(escaping the "=" and "?" characters used in the encoded-word
syntax, because they are reserved):</t>
<t><spanx style="verb"><mailto:user@example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D></spanx></t>
<t>The same subject, this time encoded as iso-8859-1:</t>
<t><spanx style="verb"><mailto:user@example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D></spanx></t>
<t>Going back to straight UTF-8 and adding a body with the same value, as an URI:</t>
<t><spanx style="verb"><mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9></spanx></t>
<t>The same as an IRI:</t>
<t><spanx style="verb"><mailto:user@example.org?subject=caf<aonly>é</aonly><ionly>é</ionly>&body=caf<aonly>é</aonly><ionly>é</ionly>></spanx></t>
<figure><preamble>This 'mailto' URI may result in an <xref target="RFC5322"/>
message looking like this:</preamble><artwork> From: sender@example.net
To: user@example.org
Subject: =?utf-8?Q?caf=C3=A9?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
caf=C3=A9
</artwork></figure>
<figure>
<preamble>The software sending the email is not restricted to UTF-8, but can use other encodings.
The following shows the same email using iso-8859-1
two times:</preamble><artwork> From: sender@example.net
To: user@example.org
Subject: =?iso-8859-1?Q?caf=E9?=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
caf=E9
</artwork>
<postamble>Different content transfer encodings (i.e., "8bit"
or "base64" instead of "quoted-printable") and different
encodings in encoded words (i.e., "B" instead of "Q") can also be used.</postamble></figure>
<figure><preamble>In a context where EAI is supported,
this 'mailto' URI can result in an <xref target="RFC6532"/> message looking like this
(encoded as UTF-8 on the wire):</preamble><artwork> From: sender@example.net
To: user@example.org
Subject: caf<aonly>é</aonly><ionly>é</ionly>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
caf<aonly>é</aonly><ionly>é</ionly>
</artwork>
</figure>
<t>For more examples of encoding the word coffee
in different languages, see <xref target="RFC2324"/>.</t>
<t>The following example uses the Japanese word "natto"
(Unicode characters U+7D0D U+8C46<ionly>, 納豆</ionly>)
as a domain name label, sending a mail to a user at
<spanx style="verb"><ionly>納豆</ionly><aonly>納豆</aonly>.example.org</spanx>,
as an URI:</t>
<t><spanx style="verb"><mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=%E7%B4%8D%E8%B1%86></spanx></t>
<t>The same as an IRI:</t>
<t><spanx style="verb"><mailto:user@<ionly>納豆</ionly><aonly>納豆</aonly>.example.org?subject=Test&body=<ionly>納豆</ionly><aonly>納豆</aonly>></spanx></t>
<figure>
<preamble>When constructing the email for use with <xref target="RFC5322"/>,
the domain name label is converted to punycode.
The resulting message might look as follows:</preamble><artwork> From: sender@example.net
To: user@xn--99zt52a.example.org
Subject: Test
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: base64
57SN6LGG
</artwork></figure>
<figure>
<preamble>The same message using EAI (<xref target="RFC6532"/>)
can look as follows (encoded as UTF-8 on the
wire):</preamble><artwork> From: sender@example.net
To: user@<ionly>納豆</ionly><aonly>納豆</aonly>.example.org
Subject: Test
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
<ionly>納豆</ionly><aonly>納豆</aonly>
</artwork></figure>
</section>
<section title="Examples Using UTF-8-Based Percent-Encoding usable only with EAI">
<t>All the previous 'mailto' URIs can be used with EAI. When used with EAI,
there is no need to use punycode in domain names, and no need to use MIME
encoding in headers and bodies. After decoding percent-encoding, UTF-8
can be used directly. This subsection gives a few additional examples
of 'mailto' URI and IRIs which can only be used with EAI.</t>
<t>Please note that the choice of URI vs. IRI is independent of
whether EAI can be used or not.</t>
<t>A hypothetical 'mailto' URI for ordering coffee from a French coffee pot:</t>
<t><spanx style="verb">mailto:caf%C3%A9@pot.example?Subject=Espresso,%20please</spanx></t>
<t>The same as an IRI:</t>
<t><spanx style="verb">mailto:caf<aonly>é</aonly><ionly>é</ionly>@pot.example?Subject=Espresso,%20please</spanx></t>
<t>A hypothetical 'mailto' URI for sending a potential erratum to the first author of this memo
("%C3%BC" represents an u-umlaut, "%E9%9D%92%E5%B1%B1" represents the
Unicode characters U+9752 (blue) and U+5C71 (mountain)):</t>
<t><spanx style="verb">mailto:Martin.D%C3%BCrst@%E9%9D%92%E5%B1%B1.example.net?Subject=Error%20in%20RFC6068bis</spanx></t>
<t>The same as an IRI:</t>
<t><spanx style="verb">mailto:Martin.D<aonly>ü</aonly><ionly>ü</ionly>rst@<aonly>青山</aonly><ionly>青山</ionly>.example.net?Subject=Error%20in%20RFC6068bis</spanx></t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>The 'mailto' URI/IRI scheme can be used to send a message from one user to another,
and thus can introduce many security concerns. Mail messages can be logged at the
originating site, the recipient site, and intermediary sites along the delivery path.
If the messages are not encrypted, they can also be read at any of those sites.</t>
<t>Also, if a web mail service is registered as a handler of 'mailto' URIs/IRIs,
this means that the creation of a message to the designated address is done with the
knowledge of that web mail service, even if the message is actually never sent.</t>
<t>A 'mailto' URI/IRI gives a template for a message that can be sent by mail client software.
The contents of that template may be opaque or difficult to read by the user at the
time of specifying the URI/IRI, as well as being hidden in the user interface
(for example, a link on an HTML Web page
might display something other than the content of the corresponding
'mailto' URI/IRI that would be used when clicked).
Thus, a mail client SHOULD NOT send a message based on a
'mailto' URI/IRI without first disclosing and showing to the user the full message that
will be sent (including all header fields that were specified by the 'mailto' URI/IRI),
fully decoded, and asking the user for approval to send the message as electronic mail.
The mail client SHOULD also make it clear that the user is about to send an electronic
mail message, since the user may not be aware that this is the result of a 'mailto' URI/IRI.
Users are strongly encouraged to ensure that the
'mailto' URI/IRI presented to them matches the address included in the
"To:" line of the email message.</t>
<t>Some header fields are inherently unsafe to include in a message generated from a URI/IRI.
For details, please see <xref target="semantics"/>.
In general, the fewer header fields interpreted from the URI/IRI,
the less likely it is that a sending agent will create an unsafe message.</t>
<t>Examples of problems with sending unapproved mail include:</t>
<t>
<list>
<t> mail that breaks laws upon delivery, such as making illegal threats;</t>
<t> mail that identifies the sender as someone interested in breaking laws;</t>
<t> mail that identifies the sender to an unwanted third party;</t>
<t> mail that causes a financial charge to be incurred by the sender;</t>
<t> mail that causes an action on the recipient machine that causes
damage that might be attributed to the sender.</t>
</list>
</t>
<t>Programs that interpret 'mailto' URIs/IRIs SHOULD ensure that the SMTP envelope return path address,
which is given as an argument to the SMTP MAIL FROM command, is set and correct,
and that the resulting email is a complete, workable message.</t>
<t>'mailto' URIs/IRIs on public Web pages expose mail addresses for harvesting.
This applies to all mail addresses that are part of the 'mailto' URI/IRI,
including the addresses in a "bcc" <hfvalue>.
Those addresses will not be sent to the recipients in the 'to' field
and in the "to" and "cc" <hfvalue>s,
but will still be publicly visible in the URI/IRI.
Addresses in a "bcc" <hfvalue> may also leak to other addresses
in the same <hfvalue> or become known otherwise, depending on the mail user agent used.</t>
<t>Programs manipulating 'mailto' URIs/IRIs have to take great care to not
inadvertently double-escape or double-unescape 'mailto' URIs/IRIs, and
to make sure that escaping and unescaping conventions relating to URIs/IRIs
and relating to mail addresses are applied in the right order.</t>
<t>Implementations parsing 'mailto' URIs/IRIs must take care to sanity check
'mailto' URIs/IRIs in order to avoid buffer overflows and problems resulting
from them (e.g., execution of code specified by the attacker).</t>
<t>The security considerations for URIs (<xref target="STD66"/>), IRIs (<xref target="RFC3987"/>),
IDNA (<xref target="RFC5890"/> and <xref target="RFC5891"/>),
and EAI (<xref target="RFC6530"/> and <xref target="RFC6532"/>) also apply.
Implementers and users are advised to check them carefully.</t>
</section>
<section title="IANA Considerations">
<section title="Update of the Registration of the 'mailto' URI/IRI Scheme" anchor="registryTemplate">
<figure>
<preamble>This document changes the definition of the 'mailto' URI/IRI scheme;
the registry of URI/IRI schemes should be updated to refer to this document rather
than its predecessor <xref target="RFC6068"/>.
The registration template is as
follows:</preamble><artwork>Resource Identifier (RI) Scheme name:
'mailto'
Status:
permanent
Scheme syntax:
See the syntax section of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Scheme semantics:
See the semantics section of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Encoding considerations:
See the syntax and encoding sections of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Applications/protocols that use this scheme name:
The 'mailto' URI/IRI scheme is widely used since
the start of the Web.
Interoperability considerations:
Interoperability for 'mailto' URIs/IRIs with UTF-8-based
percent-encoding might be somewhat lower than interoperability
for 'mailto' URIs with US-ASCII only. In particular,
interoperability for 'mailto' URIs/IRIs with UTF-8-based
percent-encoding in the LHS of email addresses requires
support of EAI [RFC6530].
Security considerations:
See the security considerations section of RFC YYYY.
[RFC Editor: Please replace with actual RFC number.]
Contact:
IETF
Author/Change controller:
IETF
References:
<aonly>Duerst</aonly><ionly>Dürst</ionly>, M., Masinter, L., and J. Zawinski,
"The 'mailto' URI/IRI Scheme", RFC YYYY, ???? 201?.
[RFC Editor: Please replace with actual RFC number and date.]</artwork></figure>
</section>
<section title="Registration of the Body Header Field" anchor="bodyRegister">
<t>IANA is herewith requested to update the reference for the registration of the
Body header field in the Message Header Fields Registry
(<xref target="RFC3864"/>) from <xref target="RFC6068"/> to this document (there are no
changes to the specification of the Body header field itself).</t>
</section>
</section>
<section title="Main Changes from RFC 6068">
<t>The main changes from <xref target="RFC6068"/> are as follows:</t>
<t>
<list style="symbols">
<t>Allowed UTF-8/percent-encoding in <local-part-enc>, to be used for EAI email addresses.</t>
<t>Added "/" and "?" back to some-delims, because they are allowed in query parts.</t>
<t>Added suffix "-enc" to some ABNF rule names to distinguish them from their counterparts
without percent-encoding.</t>
<t>Added a MUST for using UTF-8 in <hfvalue>.</t>
<t>Added examples as IRIs where there's a difference to the URI form.</t>
<t>Added non-ASCII examples in HTML and PDF versions for better understanding.</t>
</list>
</t>
</section>
<section title="Change Log">
<t>RFC Editor: Please remove this section before publication.</t>
<section title="Changes from -03 to -04">
<t>
<list>
<t>Added explanation of consequences of registration of URI/IRI to web mail service,
both in Semantics section and in Security Considerations.</t>
<t>Alligned registration template with the one in draft-ietf-iri-4395bis-irireg-04.</t>
<t>Added EAI references and acronyms to security section.</t>
<t>Removed sentence "Therefore, fragment identifiers are
meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
ignored upon resolution." because fragments are outside of the scope
of an URI/IRI scheme definition.</t>
<t>Various minor tweaks and fixes.</t>
<t>Fixed spelling of Pete Resnick's name (see http://www.rfc-editor.org/errata_search.php?rfc=6068&eid=3265).</t>
</list>
</t>
</section>
<section title="Changes from -02 to -03">
<t>
<list>
<t>Introduced non-ASCII text in author names and examples for better understanding and
as a trial for future draft/rfc formats.</t>
<t>Split "Main Changes" and changes by draft number so that the former can be kept, but
the later removed when moving to publication.</t>
<t>Fixed title of RFC 6068.</t>
<t>Various minor tweaks and fixes.</t>
</list>
</t>
</section>
<section title="Changes from -01 to -02">
<t>
<list>
<t>TODO: Change syntax definition to be in terms of IRI syntax, not URI syntax.</t>
<t>Split up the Syntax section into subsections.</t>
<t>Added "/" and "?" back to some-delims, because they are allowed in query parts.</t>
<t>Updated references.</t>
</list>
</t>
</section>
<section title="Changes from -00 to -01">
<t>
<list>
<t>Updated references.</t>
<t>Removed RFC Editor note for updating reference to RFC3987. Depending on how
the documents progress, this will be unnecessary or will happen automatically.</t>
<t>Minor editorial tweaks.</t>
</list>
</t>
</section>
<section title="Changes from RFC 6068 to -00">
<t>
<list>
<t>Changed title and various other places to also refer to IRIs.</t>
<t>Allowed UTF-8/percent-encoding in <local-part-enc>, to be used for EAI email addresses.</t>
<t>Updated syntax to use "-enc" prefix in some places.</t>
<t>Added MUST for using UTF-8 in <hfvalue>.</t>
<t>Added a new subsection with EAI-only examples.</t>
<t>Updated references.</t>
<t>Updated first author's address.</t>
</list>
</t>
</section>
</section>
<section title="Acknowledgments">
<t>This document was derived from <xref target="RFC6068"/>; the
acknowledgments from that specification and its predecessor still apply.</t>
<t>Valuable input on this document was received from (in no particular order):
Shawn Steele, Frank Ellermann, John Klensin, Yangwoo Ko<ionly> (고양우)</ionly>,
John Levine, and Roy Fielding.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2045"><front><title>Multipurpose Internet Mail Extensions
(MIME) Part One:
Format of Internet Message Bodies</title>
<author initials="N." surname="Freed" fullname="Ned Freed"><organization/></author>
<author initials="N." surname="Borenstein" fullname="Nathaniel Borenstein"><organization/>
</author>
<date month="November" year="1996"/></front>
<seriesInfo name="RFC" value="2045"/>
</reference>
<reference anchor="RFC2047">
<front>
<title>MIME Part Three: Message Header Extensions for Non-ASCII Text</title>
<author initials="K." surname="Moore" fullname="Keith Moore"><organization/></author>
<date year="1996" month="November"/>
</front>
<seriesInfo name="RFC" value="2047"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner"><organization/></author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials="J." surname="Klensin" fullname="John Klensin"><organization/></author>
<date year="2010" month="August"/>
</front>
<seriesInfo name="RFC" value="5890"/>
</reference>
<reference anchor="RFC5891">
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
<author initials="J." surname="Klensin" fullname="John Klensin"><organization/></author>
<date year="2010" month="August"/>
</front>
<seriesInfo name="RFC" value="5891"/>
</reference>
<reference anchor="RFC3987">
<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author initials="M.J." isurname="Dürst" surname="Duerst" ifullname="Martin Dürst" fullname="Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.)">
<organization/></author>
<author initials="M.L." surname="Suignard" fullname="Michel Suignard"><organization/></author>
<date year="2005" month="January"/>
</front>
<seriesInfo name="RFC" value="3987"/>
</reference>
<reference anchor="STD63">
<front>
<title abbrev="UTF-8">UTF-8, a transformation format of ISO 10646</title>
<author initials="F." surname="Yergeau" ifullname="François Yergeau" fullname="Francois Yergeau"><organization/></author>
<date month="November" year="2003"/>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
</reference><reference anchor="RFC3864">
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials="G." surname="Klyne" fullname="G. Klyne"><organization/></author>
<author initials="M." surname="Nottingham" fullname="M. Nottingham"><organization/></author>
<author initials="J." surname="Mogul" fullname="J. Mogul"><organization/></author>
<date year="2004" month="September"/>
</front>
<seriesInfo name="BCP" value="90"/>
<seriesInfo name="RFC" value="3864"/>
</reference>
<reference anchor="STD66">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"><organization/></author>
<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"><organization/></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter"><organization/></author>
<date month="January" year="2005"/>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
</reference>
<reference anchor="STD68">
<front>
<title abbrev="ABNF">Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="Dave Crocker"><organization/></author>
<author initials="P." surname="Overell" fullname="Paul Overell"><organization/></author>
<date month="January" year="2008"/></front>
<seriesInfo name="STD" value="68"/><seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="RFC5322">
<front>
<title>Internet Message Format</title>
<author initials="P." surname="Resnick" fullname="Pete Resnick"><organization/></author>
<date year="2008" month="October"/>
</front>
<seriesInfo name="RFC" value="5322"/>
</reference>
<reference anchor="RFC6532">
<front>
<title>Internationalized Email Headers</title>
<author initials="A." surname="Yang" fullname="A. Yang">
<organization/></author>
<author initials="S." surname="Steele" fullname="S. Steele">
<organization/></author>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/></author>
<date year="2012" month="February"/>
</front>
<seriesInfo name="RFC" value="6532"/>
<format type="TXT" octets="22725" target="http://www.rfc-editor.org/rfc/rfc6532.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2324"><front><title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>
<author initials="L." surname="Masinter" fullname="Larry Masinter"><organization/></author>
<date day="1" month="April" year="1998"/></front><seriesInfo name="RFC" value="2324"/>
</reference>
<reference anchor="RFC6068">
<front>
<title>The 'mailto' URI Scheme</title>
<author initials="M.J." isurname="Dürst" surname="Duerst" ifullname="Martin J. Dürst" fullname="Martin J. Duerst">
<organization>Aoyama Gakuin University</organization>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter"><organization/></author>
<author initials="J." surname="Zawinski" fullname="Jamie Zawinski"><organization/></author>
<date year="2010" month="October"/>
</front>
<seriesInfo name="RFC" value="6068"/>
</reference>
<reference anchor="RFC6530">
<front>
<title>Overview and Framework for Internationalized Email</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization/></author>
<author initials="Y." isurname="Ko (고양우)" surname="Ko" ifullname="고양우" fullname="Y. Ko">
<organization/></author>
<date year="2012" month="February"/>
</front>
<seriesInfo name="RFC" value="6530"/>
<format type="TXT" octets="64371" target="http://www.rfc-editor.org/rfc/rfc6530.txt"/>
</reference>
<reference anchor="RFC4395bis">
<front>
<title>Guidelines and Registration Procedures for New URI/IRI Schemes</title>
<author initials="T." surname="Hansen" fullname="Tony Hansen"><organization/></author>
<author initials="T." surname="Hardie" fullname="Ted Hardie"><organization/></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter"><organization/></author>
<date year="2011" month="December"/>
</front>
<seriesInfo name="draft" value="draft-ietf-iri-4395bis-irireg-04"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:54:16 |