[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6068

Network Working Group                                          M. Duerst
Internet-Draft                                  Aoyama Gakuin University
Obsoletes: 2368 (if approved)                                L. Masinter
Intended status: Standards Track              Adobe Systems Incorporated
Expires: April 29, 2010                                      J. Zawinski
                                                              DNA Lounge
                                                        October 26, 2009


                        The 'mailto' URI Scheme
                       draft-duerst-mailto-bis-07

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the



Duerst, et al.           Expires April 29, 2010                 [Page 1]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document defines the format of Uniform Resource Identifiers
   (URI) to identify resources that are reached using Internet mail.  It
   adds better internationalization and compatibility with IRIs (RFC
   3987) to the previous syntax of 'mailto' URIs (RFC 2368).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . .  3
   3.  Semantics and Operations . . . . . . . . . . . . . . . . . . .  6
   4.  Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . .  7
   5.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Examples Conforming to RFC2368 . . . . . . . . . . . . . .  8
     6.2.  Examples of Complicated Email Addresses  . . . . . . . . .  9
     6.3.  Examples Using UTF-8-Based Percent-Encoding  . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Update of the Registration of the 'mailto' URI Scheme  . . 12
     8.2.  Registration of the Body Header Field  . . . . . . . . . . 15
   9.  Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 15
   10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Changes between draft 06 and draft 07  . . . . . . . . . . 16
     10.2. Changes between draft 05 and draft 06  . . . . . . . . . . 16
     10.3. Changes between draft 04 and draft 05  . . . . . . . . . . 16
     10.4. Changes between draft 03 and draft 04  . . . . . . . . . . 17
     10.5. Changes between draft 02 and draft 03  . . . . . . . . . . 17
     10.6. Changes between draft 01 and draft 02  . . . . . . . . . . 18
     10.7. Changes between draft 00 and draft 01  . . . . . . . . . . 18
     10.8. Changes from RFC 2368  . . . . . . . . . . . . . . . . . . 19
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     12.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20





Duerst, et al.           Expires April 29, 2010                 [Page 2]

Internet-Draft           The 'mailto' URI Scheme            October 2009


1.  Introduction

   The 'mailto' URI scheme is used to identify resources that are
   reached using Internet mail.  In its simplest form, a 'mailto' URI
   contains an Internet mail address.  For interactions that require
   message headers or message bodies to be specified, the 'mailto' URI
   scheme also allows setting mail header fields and the message body.

   This specification extends the previous scheme definition to also
   allow character data to be percent-encoded based on UTF-8, which
   offers a better and more consistent way of dealing with non-ASCII
   characters for internationalization.

   This specification does not address the needs of the ongoing Email
   Address Internationalization effort (see [RFC4952]).  In particular,
   this specification does not include syntax for fallback addresses.
   This may be fixed in a future version of this specification.

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in [RFC2119].

   In this document, URIs are enclosed in '<' and '>' as described in
   Appendix C of [STD66].  Extra whitespace and line breaks added to
   present long URIs are not part of the actual URI.


2.  Syntax of a 'mailto' URI

   The syntax of a 'mailto' URI is described using the ABNF of [STD68],
   non-terminal definitions from [RFC5322] (dot-atom, quoted-string) and
   non-terminal definitions from [STD66] (unreserved, pct-encoded):

      mailtoURI   = "mailto:" [ to ] [ hfields ]
      to          = [ addr-spec *("%2C" addr-spec ) ]
      hfields     = "?" hfield *( "&" hfield )
      hfield      = hfname "=" hfvalue
      hfname      = *qchar
      hfvalue     = *qchar
      addr-spec   = local-part "@" domain
      local-part  = dot-atom / quoted-string
      domain      = dot-atom
      qchar       = unreserved / pct-encoded / some-delims
      some-delims = "!" / "$" / "'" / "(" / ")" / "*"
                  / "+" / "," / ";" / ":" / "@"

   <addr-spec> is a mail address as specified in [RFC5322], but
   excluding <comment> from [RFC5322].  However, the following changes



Duerst, et al.           Expires April 29, 2010                 [Page 3]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   apply:

   1.  A number of characters that can appear in <addr-spec> have to be
       percent-encoded.  These are the characters that cannot appear in
       an URI according to [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.

   2.  <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] are not
       allowed.

   3.  Whitespace and comments within <local-part> and <domain> are not
       allowed.  They would not have any operational semantics.

   4.  Percent-encoding can be used in the <domain> part of an <addr-
       spec>, in order to denote an internationalized domain name.  The
       considerations for <reg-name> in [STD66] apply.  In particular,
       non-ASCII characters MUST first be encoded according to UTF-8
       [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 IDNA encoding where
       appropriate [RFC3490].  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.

   5.  Percent-encoding of non-ASCII octets in the <local-part> of an
       <addr-spec> is reserved for the internationalization of the
       <local-part>.  Non-ASCII characters MUST first be encoded
       according to UTF-8 [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>
       containing non-ASCII characters will be used to compose a
       message, the <local-part> MUST be transformed to conform to
       whatever encoding may be defined in a future specification for
       the internationalization of email addresses.

   <hfname> and <hfvalue> are encodings of an [RFC5322] header field
   name and value, respectively.  Percent-encoding is needed for the
   same characters as listed above for <addr-spec>. <hfname> is case-



Duerst, et al.           Expires April 29, 2010                 [Page 4]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   insensitive, but <hfvalue> in general is case-sensitive.

   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.  The "body" pseudo header field name has been registered with
   IANA for this special purpose, see Section 8.2.

   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.

   Because the "&" (ampersand) character is reserved in HTML and XML,
   any 'mailto' URI which contains an ampersand have to be spelled
   differently in HTML and XML than in other contexts.  A 'mailto' URI
   which appears in an HTML or XML document has to escape the "&", e.g.
   as "&amp;".

   Non-ASCII characters can be encoded in hfvalue as follows:

   1.  MIME encoded words (as defined in [RFC2047]) are permitted in
       header field values, but not in an <hfvalue> of a "body"
       <hfname>.  Please note that the '=' and '?' characters used as
       delimiters in MIME encoded words have to be percent-escaped.

   2.  Non-ASCII characters can be encoded according to UTF-8 [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,
       the <hfvalue> has to be suitably encoded (transformed into MIME
       encoded words [RFC2047]), except for an <hfvalue> of a "body"
       <hfname>, which has to be encoded according to [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.

   Also note that it is syntactically valid to specify both <to> and an
   <hfname> whose value is "to".  That is,

   <mailto:addr1@an.example%2C%20addr2@an.example>

   is equivalent to

   <mailto:?to=addr1@an.example%2C%20addr2@an.example>




Duerst, et al.           Expires April 29, 2010                 [Page 5]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   is equivalent to

   <mailto:addr1@an.example?to=addr2@an.example>

   However, the latter form is NOT RECOMMENDED.

   Implementations SHOULD NOT produce two "To:" header fields in a
   message; the "To:" header field may occur at most once in a message
   ([RFC5322], Section 3.6).  Also, creators of 'mailto' URIs SHOULD NOT
   include other message header fields multiple times if these header
   fields can only be used once in a message.

   Creators of 'mailto' URIs SHOULD avoid using the same <hfname>
   multiple times in the same URI to avoid interoperability problems.
   If the same <hfname> appears multiple times in an URI, behavior
   varies widely for different user agents, and for each <hfname>.
   Examples include only using the first or last <hfname>/<hfvalue>
   pair, combining each <hfvalue> by simple concatenation, or in a way
   appropriate for the corresponding header field, or creating multiple
   header fields.

   Note that this specification, like any URI scheme specification, does
   not define syntax or meaning of a fragment identifier, because these
   depend on the type of a retrieved representation.  In the currently
   known usage scenarios, a 'mailto' URI cannot be used to retreive such
   representations.  Therefore, fragment identifiers are meaningless,
   SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored upon
   resolution.  The character '#' in hfvalues MUST be escaped as %23.


3.  Semantics and Operations

   A 'mailto' URI 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.

   The operation of how any URI scheme is resolved is not mandated by
   the URI specifications.  In current practice, resolving URIs such as
   those in the 'http' URI scheme causes an immediate interaction
   between client software and a host running an interactive server.
   The 'mailto' URI has unusual semantics because resolving such a URI
   does not cause an immediate interaction.  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 this message



Duerst, et al.           Expires April 29, 2010                 [Page 6]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   unedited, or choose not to send the message.


4.  Unsafe Header Fields

   The user agent interpreting a 'mailto' URI SHOULD choose not to
   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.  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 an URI is well known, and/or specific header fields are
   limited to specific well-known values, other header fields may be
   considered safe, too.

   The creator of a 'mailto' URI cannot expect the resolver of a URI to
   understand more than the "subject" header field and "body".  Clients
   that resolve 'mailto' URIs into mail messages MUST be able to
   correctly create [RFC5322]-compliant mail messages using the
   "subject" header field and "body".


5.  Encoding

   [STD66] requires that many characters in URIs be encoded.  This
   affects the 'mailto' URI 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".

   When creating 'mailto' URIs, any reserved characters that are used in
   the URIs MUST be encoded so that properly-written URI interpreters
   can read them.  Also, client software that reads URIs MUST decode
   strings before creating the mail message so that the mail messages
   appear in a form that the recipient software will understand.  These
   strings SHOULD be decoded before showing the message to the sending
   user.

   Software creating 'mailto' URIs likewise has to be careful to encode
   any reserved characters that are used.  One kind of software creating
   'mailto' URIs are HTML forms.  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.
   When producing 'mailto' URIs, all spaces SHOULD be encoded as %20.

   The 'mailto' URI scheme is limited in that it does not provide for
   substitution of variables.  Thus, it is impossible to create a



Duerst, et al.           Expires April 29, 2010                 [Page 7]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   'mailto' URI that includes a user's email address in the message
   body.  This limitation also prevents 'mailto' URIs that are signed
   with public keys and other such variable information.


6.  Examples

6.1.  Examples Conforming to RFC2368

   A URI for an ordinary individual mailing address:

   <mailto:chris@example.com>

   A URI for a mail response system that requires the name of the file
   in the subject:

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

   A mail response system that requires a "send" request in the body:

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

   A similar URI, with two lines with different "send" requests (in this
   case, "send current-issue" and, on the next line, "send index"):

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

   An interesting use of 'mailto' URIs occurs when browsing archives of
   messages.  A link can be provided that allows to reply to a message
   and conserve threading information.  This is done by adding a In-
   Reply-To header field containing the Message-ID of the message where
   the link is added, for example:

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

   A request to subscribe to a mailing list:

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

   A URI for a single user which includes a CC of another user:

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

   Note the use of the "&" reserved character above.  The following
   example, using "?" twice, is incorrect:




Duerst, et al.           Expires April 29, 2010                 [Page 8]

Internet-Draft           The 'mailto' URI Scheme            October 2009


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

   According to [RFC5322], the characters "?", "&", and even "%" may
   occur in addr-specs.  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.

   To indicate the address "gorby%kremvax@example.com" one would use:

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

   To indicate the address "unlikely?address@example.com", and include
   another header field, one would use:

   <mailto:unlikely%3Faddress@example.com?blat=foop>

   As described above, the "&" (ampersand) character is reserved in HTML
   and has to be replaced e.g. with "&amp;".  Thus, a URI with an
   internal ampersand might look like:

   Click <a href="mailto:joe@an.example?cc=bob@
   an.example&amp;body=hello">mailto:joe@an.example?cc=bob@
   an.example&amp;body=hello</a> to send a greeting message to Joe and
   Bob.

   When an email address itself includes an "&" (ampersand) character,
   that character has to be percent-escaped.  For example, the 'mailto'
   URI to send mail to "Mike&family@example.org" is
   <mailto:Mike%26family@example.org>.

6.2.  Examples of Complicated Email Addresses

   Following are a few examples of how to treat email addresses that
   contain complicated escaping syntax.

   Email address: "not@me"@example.org; corresponding 'mailto' URI:

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

   Email address: "oh\\no"@example.org; corresponding 'mailto' URI:

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

   Email address: "\\\"it's\ ugly\\\""@example.org; corresponding
   'mailto' URI:




Duerst, et al.           Expires April 29, 2010                 [Page 9]

Internet-Draft           The 'mailto' URI Scheme            October 2009


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

6.3.  Examples Using UTF-8-Based Percent-Encoding

   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:

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

   The same subject, this time using an encoded-word (escaping the "="
   and "?" characters used in the encoded-word syntax, because they are
   reserved):

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

   The same subject, this time encoded as iso-8859-1:

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

   Going back to straight UTF-8 and adding a body with the same value:

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

   This 'mailto' URI may result in a message looking like this:

      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

   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:

      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

   Different content transfer encodings (i.e. "8bit" or "base64" instead



Duerst, et al.           Expires April 29, 2010                [Page 10]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   of "quoted-printable") and different encodings in encoded words (i.e.
   "B" instead of "Q") can also be used.

   For more examples of encoding the word coffee in different languages,
   see [RFC2324].

   The following example uses the Japanese word "natto" (Unicode
   characters U+7D0D U+8C46) as a domain name label, sending a mail to a
   user at "natto".example.org:

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

   When constructing the email, the domain name label is converted to
   punycode.  The resulting message may look as follows:

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

      NATTO


7.  Security Considerations

   The 'mailto' URI 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 encoded, they can also be read at any of those sites.

   A 'mailto' URI 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.
   Thus, a mail client SHOULD never send a message based on a 'mailto'
   URI without first showing the full message that will be sent to the
   user (including all header fields that were specified by the 'mailto'
   URI), 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.

   A mail client SHOULD never send anything without complete disclosure
   to the user of what will be sent; it SHOULD disclose not only the
   message destination, but also any header fields.  Unrecognized header
   fields, or header fields with values inconsistent with those the mail



Duerst, et al.           Expires April 29, 2010                [Page 11]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   client would normally send SHOULD be treated as especially suspect.
   MIME header fields (MIME- Version, Content-*) are most likely
   inappropriate, except when added by the MUA to correctly encode the
   text(s) being sent, as are those relating to routing (From,
   Apparently-To, etc.)

   Note that some header fields are inherently unsafe to include in a
   message generated from a URI.  For example, header fields such as
   "From:", and so on, SHOULD never be interpreted from a URI.  In
   general, the fewer header fields interpreted from the URI, the less
   likely it is that a sending agent will create an unsafe message.

   Examples of problems with sending unapproved mail include:

      mail that breaks laws upon delivery, such as making illegal
      threats;

      mail that identifies the sender as someone interested in breaking
      laws;

      mail that identifies the sender to an unwanted third party;

      mail that causes a financial charge to be incurred on the sender;

      mail that causes an action on the recipient machine that causes
      damage that might be attributed to the sender.

   Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP
   "From" address (the SMTP envelope return path given as an argument to
   the SMTP MAIL FROM command) is set and correct, and that the
   resulting email is a complete, workable message.

   'mailto' URIs on public Web pages expose mail addresses for
   harvesting.  This applies to all mail addresses included in the
   'mailto' URI, 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" hfvalues, but will still be publicly visible in the
   URI.

   The security considerations of [STD66], [RFC3490], [RFC3491], and
   [RFC3987] also apply.  Implementers and users are recommended to
   check them carefully.


8.  IANA Considerations

8.1.  Update of the Registration of the 'mailto' URI Scheme




Duerst, et al.           Expires April 29, 2010                [Page 12]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   This document changes the definition of the 'mailto' URI scheme; the
   registry of URI schemes needs to be updated to refer to this document
   rather than its predecessor, [RFC2368].  The registration template is
   as follows:















































Duerst, et al.           Expires April 29, 2010                [Page 13]

Internet-Draft           The 'mailto' URI Scheme            October 2009


 URI scheme name:
    'mailto'

 Status:
    permanent

 URI scheme syntax:
    See the syntax section of draft-duerst-mailto-bis-07.txt.
    (Note to RFC Editor and IANA: Replace this with
     RFC YYYY (RFC number of this specification)).

 URI scheme semantics:
    See the semantics section of draft-duerst-mailto-bis-07.txt.
    (Note to RFC Editor and IANA: Replace this with
     RFC YYYY (RFC number of this specification)).

 Encoding considerations:
    See the syntax and encoding sections of
    draft-duerst-mailto-bis-07.txt.
    (Note to RFC Editor and IANA: Replace this with
    RFC YYYY (RFC number of this specification)).

 Applications/protocols that use this URI scheme name:
    The 'mailto' URI scheme is widely used since the start of the Web.

 Interoperability considerations:
    Interoperability for 'mailto' URIs with UTF-8-based percent-encoding
    might be somewhat lower than interoperability for 'mailto' URIs with
    US-ASCII only.

 Security considerations:
    See the security section of draft-duerst-mailto-bis-07.txt.
    (Note to RFC Editor and IANA: Replace this with
     RFC YYYY (RFC number of this specification)).

 Contact:
    IETF

 Author/Change controller:
    IETF

 References:
    Internet-Draft draft-duerst-mailto-bis-07.txt
    (Note to RFC Editor and IANA: Replace this with
     RFC YYYY (RFC number of this specification))






Duerst, et al.           Expires April 29, 2010                [Page 14]

Internet-Draft           The 'mailto' URI Scheme            October 2009


8.2.  Registration of the Body Header Field

   IANA is herewith requested to register the Body header field in the
   Message Header Fields Registry ([RFC3864]) as follows:

   Header field name:
      Body

   Applicable protocol:
      None. This registration is made to assure that this header field
      name is not used at all, in order to not create any problems
      for 'mailto' URIs.

   Status:
      reserved

   Author/Change controller:
      IETF

   Specification document(s):
      Internet-Draft draft-duerst-mailto-bis-07.txt
      (Note to RFC Editor and IANA: Replace this with
      RFC YYYY (RFC number of this specification))

   Related information:
      none


9.  Main Changes from RFC 2368

   The main changes from RFC 2368 are as follows:

   o  Changed syntax from RFC 2822 <mailbox> to [RFC5322] <addr-spec>.

   o  Allowed UTF-8-based percent-encoding for domain names and in
      <hfvalue>.

   o  Nailed down percent-encoding in <local-part> to be based on UTF-8,
      reserved for future use.

   o  Removed prohibition against "Bcc:" header fields, but added a
      warning about their visibility and harvesting for spam.

   o  Added clarifications for escaping.







Duerst, et al.           Expires April 29, 2010                [Page 15]

Internet-Draft           The 'mailto' URI Scheme            October 2009


10.  Change Log

   Note to RFC Editor: Please completely remove this section before
   publication.

10.1.  Changes between draft 06 and draft 07

   o  Changed production for 'domain' from externally defined (dot-atom
      / domain-literal / obs-domain in [RFC5322]) to dot-atom only.
      This clarifies that obsolete [RFC5322] syntax and comments are
      disallowed.

   o  Capitalized various "must" and "should", and/or changed wording to
      more clearly distinguish spec requirements and other text.

   o  Added explanation about "the characters "?", "=", and "&" are
      reserved".

   o  Removed text about not mixing MIME encoded words and percent-
      encoding.

   o  Added text to say that '=' and '?' in MIME encoded words have to
      be percent-encoded.

   o  Added registration template for 'mailto' scheme itself.

   o  Made requirement for [RFC2047]RFC 2047 in email headers less
      strong (not necessary for EAI).

   o  Removed (extremly short) section on deployment with a notice in
      registration template.

   o  Changed 'legal' to 'syntactically valid' when not referring to the
      law.

   o  Added ":" to the exceptions from escaping in gen-delims.

10.2.  Changes between draft 05 and draft 06

   o  Fixed references ([RFC5322]).

   o  Changed IPR text to pre5378Trust200902.

10.3.  Changes between draft 04 and draft 05

   o  Added "Main Changes from RFC 2368" to help implementation updates
      from RFC 2368.




Duerst, et al.           Expires April 29, 2010                [Page 16]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   o  Added a warning about spam harvesting and visibility of bcc
      addresses.

   o  Clarified that <addr-spec> does not include comments.

   o  Changed names of syntax productions to be better in line with
      standard terminology: headers -> hfields, header -> hfield, hname
      -> hfname, hvalue -> hfvalue.

   o  Streamlined terminology: mailto, mailto: -> 'mailto'; LHS ->
      <local-part>; consistently used '<' and '>' for ABNF production
      names.

   o  Changed section heading from "Unsafe Headers" to "Unsafe Header
      Fields".

   o  Got rid of references and the word 'update' in the Abstract.

   o  Updated ABNF reference to [STD68]

   o  Some minor wording cleanup.

10.4.  Changes between draft 03 and draft 04

   o  Added mention of internationalization (not just IRI) to abstract.

   o  Updated reference from draft-ietf-eai-framework to RFC 4952,
      simplified referring text.

   o  Used MUST for resolvers to understand Subject and Body for clear
      interoperability.

   o  Noted that multiple identical hnames can cause interoperability
      problems and SHOULD be avoided.

   o  Note the problem of '+' produced by HTML forms, made clear that
      %20 SHOULD be used for encoding spaces.

   o  Removed warning against using bcc; doesn't seem to be of any harm
      if user checks explicitly.

   o  Some minor wording cleanup.

10.5.  Changes between draft 02 and draft 03

   o  Adjusted description of mailto URI in abstract to match intro.





Duerst, et al.           Expires April 29, 2010                [Page 17]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   o  Added registration template for body header field.

   o  Clarified requirements for produced email message.

   o  Clarified case (in)sensitivity of header field names and values.

   o  Introduced reference to EAI-framework, explained to what extent it
      has been taken into account.

   o  Changed reference label from RFC3986 to STD66.

10.6.  Changes between draft 01 and draft 02

   o  Fixed phone/fax for Martin.

   o  Changed examples to reduce cases with both a 'to' field and a 'to'
      hname.

   o  Fixed syntax to not rely on non-terminals from RFC 2396.  Changed
      description of set of characters that needs to be escaped.

   o  Mollified warning about header fields other than Subject,
      Keywords, and Body.

   o  Clarified prohibition of mixing different encodings (%-escaping
      and Mime encoded words) for header fields.

   o  Improved some examples.  Fixed some terminology.

10.7.  Changes between draft 00 and draft 01

   o  Added clarification about permitted syntax and escaping on email
      address LHS, and more complicated examples.

   o  Added text about more safe headers in case origin or mailto URIs
      is known.

   o  Fixed date of [STD66]

   o  Added a sentence referencing [RFC2119]

   o  Added Jamie back in as a co-author.  Changed address/affiliation
      for Martin.








Duerst, et al.           Expires April 29, 2010                [Page 18]

Internet-Draft           The 'mailto' URI Scheme            October 2009


10.8.  Changes from RFC 2368

   o  For interoperability with IRIs ([RFC3987]), allowed percent-
      encoding, fixed to UTF-8, in the domain name part of an email
      address, in LHS part of an address (currently reserved because not
      operationally usable), and in hvalue parts.

   o  Changed from 'URL' to 'URI'

   o  Updated references: ABNF to [STD68]; message syntax to [RFC5322],
      URI Generic Syntax to [STD66]

   o  Expanded "#mailbox", because the "#" shortcut is no longer
      available; needs checking


11.  Acknowledgments

   This document was derived from [RFC2368]; the acknowledgments from
   this specification still apply.  In addition, we thank Paul Hoffman
   for his work on [RFC2368].

   Valuable input on this document was received from (in no particular
   order): Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg,
   Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony Puls
   II, and Alfred Hoenes.


12.  References

12.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", November 1996.

   [RFC2047]  Moore, K., "MIME Part Three: Message Header Extensions for
              Non-ASCII Text", RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",



Duerst, et al.           Expires April 29, 2010                [Page 19]

Internet-Draft           The 'mailto' URI Scheme            October 2009


              RFC 3491, March 2003.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", RFC 3864, BCP 90,
              September 2004.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC5322]  Resnik, P., "Internet Message Format", RFC 5322,
              October 2008.

   [STD63]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [STD68]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

12.2.  Informative References

   [RFC2324]  Masinter, L., "Hyper Text Coffee Pot Control Protocol
              (HTCPCP/1.0)", RFC 2324, April 1998.

   [RFC2368]  Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
              URL scheme", RFC 2368, July 1998.

   [RFC4952]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 4952, July 2007.


Authors' Addresses

   Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever
                 possible, for example as "D&#252;rst" in XML and HTML.)
   Aoyama Gakuin University
   5-10-1 Fuchinobe
   Sagamihara, Kanagawa  229-8558
   Japan

   Phone: +81 42 759 6329
   Fax:   +81 42 759 6495
   Email: mailto:duerst@it.aoyama.ac.jp
   URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/





Duerst, et al.           Expires April 29, 2010                [Page 20]

Internet-Draft           The 'mailto' URI Scheme            October 2009


   Larry Masinter
   Adobe Systems Incorporated
   345 Park Ave
   San Jose, CA  95110
   USA

   Phone: +1-408-536-3024
   Email: LMM@acm.org
   URI:   http://larry.masinter.net/


   Jamie Zawinski
   DNA Lounge
   375 Eleventh Street
   San Francisco, CA  94103
   USA

   Email: jwz@jwz.org

































Duerst, et al.           Expires April 29, 2010                [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/