Network Working Group                                          M. Duerst
Internet-Draft                                  Aoyama Gakuin University
Updates: XXXX (if approved)                            February 18, 2008                                March 9, 2009
Intended status: Experimental
Expires: August 21, 2008 September 10, 2009

          An update to the mailto URI scheme for Email Address
                          Internationalization
                        draft-ietf-eai-mailto-00
                        draft-ietf-eai-mailto-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of which he BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or she is aware
   have been IETF Contributions published or will 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 disclosed, modified outside the IETF Standards Process, and any
   derivative works of which he or she becomes
   aware will it may not be disclosed, in accordance with Section 6 of BCP 79. 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 August 21, 2008. September 10, 2009.

Copyright Notice

   Copyright (C) The (c) 2009 IETF Trust (2008). and the persons identified as the
   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 updates the definition of the mailto: URI Scheme for
   use with internationalized email addresses.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Syntax of a mailto URI  . . . . . . . . . . . . . . . . . . . . 3
   3.  Deployment  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Examples Using UTF-8-Based Percent-Encoding . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgments  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Changes between draft 00 and draft 01 . . . . . . . . . . . 5
   8.  Normative References  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . 6
   Intellectual Property and Copyright Statements . . . . . . . . . . 7 . . . . . . . 6

1.  Introduction

   [RFCXXXX] defines the mailto URI scheme.  It allows for the encoding
   of non-ASCII characters in arbitrary header fields and in the right-
   hand side of email addresses, but not in the left-hand side of email
   addresses.  This document experimentally extends the syntax of
   mailto: URIs to allow the encoding of non-ASCII characters on the
   left-hand side of email addresses, and the designation of fallback
   addresses.  It also defines the mapping of mailto: URIs to email
   messages using EAI features.

   In order to keep this memo short and to reduce accidental
   differences, where possible this memo does not repeat the provisions
   in [RFCXXXX].  Whenever this memo does not specify something
   different, the provisions in [RFCXXXX] MUST be followed.

   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].

   Please send comments on this document to the mailing list
   ima@ietf.org.

2.  Syntax of a mailto URI

   The syntax of the mailto URI given in [RFCXXXX] is changed to use the
   "mailbox" production in [RFCYYYY] [RFC5335] instead of [RFC2822]. [RFC5322].  Following
   the syntax conventions of [STD66], and using the ABNF syntax defined
   in [RFC5234], a "mailto" URI has the form:

      mailtoURI   = "mailto:" [ to ] [ headers ]
      to          = [ mailbox *("%2C" mailbox ) ]
      headers     = "?" header *( "&" header )
      header      = hname "=" hvalue
      hname       = *urlc
      hvalue      = *urlc

   "mailbox" is as specified in [RFCYYYY], [RFC5335], i.e. it is a mail address,
   possibly including "phrase" and "comment" components.  It also
   possibly includes the alt-address component of angle-addr as
   specified in [RFCYYYY]. [RFC5335].  However, the following changes apply:

   1.  All characters that can appear in "mailbox" but are reserved or
       not allowed in URIs have to be percent-encoded.  Examples are
       parentheses, commas, the less-than and greater-than signs ("<"
       and ">") and the percent sign ("%"), which commonly occur in the
       "mailbox" syntax.

   2.  Percent-encoding can be used to denote non-ASCII characters, in
       order to denote an internationalized email address.  Before
       applying percent-encoding, it has to be made sure that the email
       address is encoded in UTF-8 [STD63].  This makes the mailto URI
       directly usable with EAI [RFC4952] and makes it compatible with
       IRIs [RFC3987].

   "hname" is an encoding of an [RFC2822] [RFC5322] header name. "hvalue" is an
   encoding of a [RFCYYYY] [RFC5335] header value.  As with "to", all URI reserved
   characters must be encoded.

   Non-ASCII characters can be encoded in "hvalue" as follows:

   1.  Non-ASCII characters SHOULD be encoded by first encoing the
       characters according to UTF-8 [STD63], and then encoding each
       octet of the corresponding UTF-8 octet sequence using percent-
       encoding, to result in URI characters.  This makes the mailto URI
       directly usable with EAI [RFC4952] and makes it compatible with
       IRIs [RFC3987].

   2.  MIME encoded words (as defined in [RFC2047]) MAY be used in
       header values, but MUST NOT be used in an hvalue of a "body"
       hname.

3.  Deployment

   For the forseeable future, URIs conforming to this memo should only
   be used in contexts where it can be expected that the recipient can
   create email messages conforming to the EAI framework [RFC4952].

4.  Examples

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

   Sending a mail to the user "coffee" (in French, i.e. "cafe" where the
   final e is an e-acute) at the mailhost "natto".example.org ("natto"
   is Japanese, written with the two Unicode characters U+7D0D and
   U+8C46).

   mailto:%3Ccaf%C3%A9@%E7%B4%8D%E8%B1%86.example.org%3E

   Please note that if the left-hand side of the mail address contains
   non-ASCII characters, the less-than and greater-than sign (angle
   brackets, escaped as %3C and %3E) are mandatory.

   The above example, with an "alt-address" (see [RFCYYYY])added: [RFC5335])added:

   mailto:%3Ccaf%C3%A9@%E7%B4%8D%E8%B1%86.example.org%20%3Ccafe@
   natto.example.org%3E%3E

   Please note that at least a space is needed before the "alt-address",
   and that such a space also has to be percent-encoded.  Also, please
   note that the URI above is separated into two lines to conform to
   formatting conventions, but that there is no line bleak in actual
   use.

5.  Security Considerations

   The security considerations of [RFCXXXX], [RFCYYYY], [RFC5335], and [RFC4952]
   apply, please read them carefully.  There are no known security
   threats specific to this memo alone.

6.  IANA Considerations

   This document updates the definition of the mailto: URI scheme; in
   the registry of URI schemes, a reference to this memo should be added
   to the current reference.

7.  Change Log

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

7.1.  Changes between draft 00 and draft 01

   o  Updated references ([RFC5322], [RFC5335],...).

   o  Changed IPR text to pre5378Trust200902.

8.  Acknowledgments

   This document is the product of the EAI WG of the IETF.  We thank all
   the members of this WG.

8.

9.  Normative References

   [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.

   [RFC2822]  Resnik, P., "Internet Message Format", RFC 2822,
              April 2001.

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

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

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

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

   [RFC5335]  Abel, Y., "Internationalized Email Headers (work in
              progress)", September 2008.

   [RFCXXXX]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme (work in progress)", January 2008.

   [RFCYYYY]  Abel, Y., "Internationalized Email Headers (work in
              progress)", February 2008. March 2009.

   [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, April 2004.

Author's Address

   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/

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).