idnits 2.17.1 draft-ietf-eai-mailto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 266. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Duerst 3 Internet-Draft Aoyama Gakuin University 4 Updates: XXXX (if approved) February 18, 2008 5 Intended status: Experimental 6 Expires: August 21, 2008 8 An update to the mailto URI scheme for Email Address 9 Internationalization 10 draft-ietf-eai-mailto-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document updates the definition of the mailto: URI Scheme for 44 use with internationalized email addresses. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Syntax of a mailto URI . . . . . . . . . . . . . . . . . . . . 3 50 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.1. Examples Using UTF-8-Based Percent-Encoding . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 Intellectual Property and Copyright Statements . . . . . . . . . . 7 60 1. Introduction 62 [RFCXXXX] defines the mailto URI scheme. It allows for the encoding 63 of non-ASCII characters in arbitrary header fields and in the right- 64 hand side of email addresses, but not in the left-hand side of email 65 addresses. This document experimentally extends the syntax of 66 mailto: URIs to allow the encoding of non-ASCII characters on the 67 left-hand side of email addresses, and the designation of fallback 68 addresses. It also defines the mapping of mailto: URIs to email 69 messages using EAI features. 71 In order to keep this memo short and to reduce accidental 72 differences, where possible this memo does not repeat the provisions 73 in [RFCXXXX]. Whenever this memo does not specify something 74 different, the provisions in [RFCXXXX] MUST be followed. 76 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 77 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 78 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 80 Please send comments on this document to the mailing list 81 ima@ietf.org. 83 2. Syntax of a mailto URI 85 The syntax of the mailto URI given in [RFCXXXX] is changed to use the 86 "mailbox" production in [RFCYYYY] instead of [RFC2822]. Following 87 the syntax conventions of [STD66], and using the ABNF syntax defined 88 in [RFC5234], a "mailto" URI has the form: 90 mailtoURI = "mailto:" [ to ] [ headers ] 91 to = [ mailbox *("%2C" mailbox ) ] 92 headers = "?" header *( "&" header ) 93 header = hname "=" hvalue 94 hname = *urlc 95 hvalue = *urlc 97 "mailbox" is as specified in [RFCYYYY], i.e. it is a mail address, 98 possibly including "phrase" and "comment" components. It also 99 possibly includes the alt-address component of angle-addr as 100 specified in [RFCYYYY]. However, the following changes apply: 102 1. All characters that can appear in "mailbox" but are reserved or 103 not allowed in URIs have to be percent-encoded. Examples are 104 parentheses, commas, the less-than and greater-than signs ("<" 105 and ">") and the percent sign ("%"), which commonly occur in the 106 "mailbox" syntax. 108 2. Percent-encoding can be used to denote non-ASCII characters, in 109 order to denote an internationalized email address. Before 110 applying percent-encoding, it has to be made sure that the email 111 address is encoded in UTF-8 [STD63]. This makes the mailto URI 112 directly usable with EAI [RFC4952] and makes it compatible with 113 IRIs [RFC3987]. 115 "hname" is an encoding of an [RFC2822] header name. "hvalue" is an 116 encoding of a [RFCYYYY] header value. As with "to", all URI reserved 117 characters must be encoded. 119 Non-ASCII characters can be encoded in "hvalue" as follows: 121 1. Non-ASCII characters SHOULD be encoded by first encoing the 122 characters according to UTF-8 [STD63], and then encoding each 123 octet of the corresponding UTF-8 octet sequence using percent- 124 encoding, to result in URI characters. This makes the mailto URI 125 directly usable with EAI [RFC4952] and makes it compatible with 126 IRIs [RFC3987]. 128 2. MIME encoded words (as defined in [RFC2047]) MAY be used in 129 header values, but MUST NOT be used in an hvalue of a "body" 130 hname. 132 3. Deployment 134 For the forseeable future, URIs conforming to this memo should only 135 be used in contexts where it can be expected that the recipient can 136 create email messages conforming to the EAI framework [RFC4952]. 138 4. Examples 140 4.1. Examples Using UTF-8-Based Percent-Encoding 142 Sending a mail to the user "coffee" (in French, i.e. "cafe" where the 143 final e is an e-acute) at the mailhost "natto".example.org ("natto" 144 is Japanese, written with the two Unicode characters U+7D0D and 145 U+8C46). 147 mailto:%3Ccaf%C3%A9@%E7%B4%8D%E8%B1%86.example.org%3E 149 Please note that if the left-hand side of the mail address contains 150 non-ASCII characters, the less-than and greater-than sign (angle 151 brackets, escaped as %3C and %3E) are mandatory. 153 The above example, with an "alt-address" (see [RFCYYYY])added: 155 mailto:%3Ccaf%C3%A9@%E7%B4%8D%E8%B1%86.example.org%20%3Ccafe@ 156 natto.example.org%3E%3E 158 Please note that at least a space is needed before the "alt-address", 159 and that such a space also has to be percent-encoded. Also, please 160 note that the URI above is separated into two lines to conform to 161 formatting conventions, but that there is no line bleak in actual 162 use. 164 5. Security Considerations 166 The security considerations of [RFCXXXX], [RFCYYYY], and [RFC4952] 167 apply, please read them carefully. There are no known security 168 threats specific to this memo alone. 170 6. IANA Considerations 172 This document updates the definition of the mailto: URI scheme; in 173 the registry of URI schemes, a reference to this memo should be added 174 to the current reference. 176 7. Acknowledgments 178 This document is the product of the EAI WG of the IETF. We thank all 179 the members of this WG. 181 8. Normative References 183 [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for 184 Non-ASCII Text", RFC 2047, November 1996. 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, March 1997. 189 [RFC2822] Resnik, P., "Internet Message Format", RFC 2822, 190 April 2001. 192 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 193 Identifiers (IRIs)", RFC 3987, January 2005. 195 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 196 Internationalized Email", RFC 4952, July 2007. 198 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 199 Specifications: ABNF", STD 68, RFC 5234, November 1997. 201 [RFCXXXX] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 202 URI Scheme (work in progress)", January 2008. 204 [RFCYYYY] Abel, Y., "Internationalized Email Headers (work in 205 progress)", February 2008. 207 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 208 10646", STD 63, RFC 3629, November 2003. 210 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 211 Resource Identifier (URI): Generic Syntax", STD 66, 212 RFC 3986, April 2004. 214 Author's Address 216 Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever 217 possible, for example as "Dürst" in XML and HTML.) 218 Aoyama Gakuin University 219 5-10-1 Fuchinobe 220 Sagamihara, Kanagawa 229-8558 221 Japan 223 Phone: +81 42 759 6329 224 Fax: +81 42 759 6495 225 Email: mailto:duerst@it.aoyama.ac.jp 226 URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ 228 Full Copyright Statement 230 Copyright (C) The IETF Trust (2008). 232 This document is subject to the rights, licenses and restrictions 233 contained in BCP 78, and except as set forth therein, the authors 234 retain all their rights. 236 This document and the information contained herein are provided on an 237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 239 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 240 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 241 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 Intellectual Property 246 The IETF takes no position regarding the validity or scope of any 247 Intellectual Property Rights or other rights that might be claimed to 248 pertain to the implementation or use of the technology described in 249 this document or the extent to which any license under such rights 250 might or might not be available; nor does it represent that it has 251 made any independent effort to identify any such rights. Information 252 on the procedures with respect to rights in RFC documents can be 253 found in BCP 78 and BCP 79. 255 Copies of IPR disclosures made to the IETF Secretariat and any 256 assurances of licenses to be made available, or the result of an 257 attempt made to obtain a general license or permission for the use of 258 such proprietary rights by implementers or users of this 259 specification can be obtained from the IETF on-line IPR repository at 260 http://www.ietf.org/ipr. 262 The IETF invites any interested party to bring to its attention any 263 copyrights, patents or patent applications, or other proprietary 264 rights that may cover technology that may be required to implement 265 this standard. Please address the information to the IETF at 266 ietf-ipr@ietf.org. 268 Acknowledgment 270 Funding for the RFC Editor function is provided by the IETF 271 Administrative Support Activity (IASA).