idnits 2.17.1 draft-klensin-email-i18n-message-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2, 2004) is 7382 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ASCII' is mentioned on line 93, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2442 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Klensin 2 Internet-Draft February 2, 2004 3 Expires: August 2, 2004 5 The MIME Message/i18n Media Type 6 draft-klensin-email-i18n-message-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on August 2, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 Efforts to design an internationalization model for electronic mail 37 frequently encounter situations in which an internationalized message 38 -- perhaps one containing some headers with characters coded in UTF-8 39 -- must be converted and transported over a traditional, 7-bit 40 infrastructure. This document provides a specification, building on 41 the design of message/rfc822, for encapsulating messages with 42 internationalized headers and/or body part content types. 44 This specification is one of a group intended to provide a modified 45 and extended email environment for fully internationalized email. 46 If approved, it is expected to update the discussion of "message/" 47 content types in RFC 2046. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 Mailing List . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol open questions . . . . . . . . . . . . . . . . . . . 4 56 4. Security considerations . . . . . . . . . . . . . . . . . . . 4 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 58 Normative References . . . . . . . . . . . . . . . . . . . . . 5 59 Informational References . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 61 Intellectual Property and Copyright Statements . . . . . . . . 6 63 1. Introduction 65 If a message is permitted to contain headers in UTF-8 (see, e.g., 66 [I-D.hoffman.utf-8] and the discussion in [I-D.klensin.email-i18n]), 67 the need will periodically arise to carry it over a traditional 7bit 68 (unextended SMTP or ESMTP) infrastructure. In general, there are 69 two ways to approach that problem. One is to specify and implement a 70 model for "downgrading", or otherwise encoding, all of the fields 71 that contain (or potentially content) non-ASCII information. That 72 approach is difficult to define properly, especially given the number 73 of variations in email header fields and the number of fields whose 74 precise syntax and semantics are not defined anywhere. The 75 alternative is to simply encapsulate the message and headers, using a 76 content-transfer-encoding to deal with the 8bit material if needed, 77 and retaining in the outermost headers only that information that can 78 be retained without ambiguity or is required by the message format 79 specification [RFC2822]. The general strategy for this type of 80 encapsulation was developed in the base MIME specification [RFC2046]; 81 this document extends that one to provide a specification for 82 encapsulation of internationalized messages. 84 1.1 Terminology 86 This document assumes a reasonable understanding of the protocols and 87 terminology of the most recent core email standards documented in RFC 88 2821 [RFC2821] and RFC 2822 [RFC2822] and of the MIME media type 89 structures described in [RFC2046]. 91 In this document, an address or header field is "all-ASCII" if every 92 character in the address or field is in the ASCII character 93 repertoire [ASCII]; an address, header field, or string is 94 "non-ASCII" if any character is not in the ASCII character 95 repertoire. 97 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 98 and "MAY" in this document are to be interpreted as described in RFC 99 2119 [RFC2119]. 101 1.2 Mailing List 103 This document is being discussed on the ietf-imaa mailing list. See 104 for information about subscribing and 105 the list's archive. 107 2. Proposal Overview 109 Two different models are possible for encapsulating an 110 internationalized message into a MIME body part. While they are 111 quite similar, the community should examine the tradeoffs and select 112 one of them. Even were the choice arbitrary, interoperability would 113 call for a single choice, without options. 114 Message Encapsulation In this model, the message body (including 115 headers) is encapsulated, identically to the model for "message/ 116 rfc822" but with the expectation that some or all headers may 117 contain UTF-8 data and therefore may require encoding. This may 118 raise issues with the multiple encoding rule, which will need to 119 be worked out if this option is chosen. 120 Mail Transaction Encapsulation In this model, the entire message 121 transmission, including the ESMTP envelope, is encapsulated and 122 incorporated into the message body. This model is identical to the 123 one outlined in [RFC2442]. That standard already provides for 124 header and envelope information potentially being in UTF-8 form, 125 not exclusively in ASCII. However, obviously, for this extension 126 to be permitted to be encapsulated, the list of permitted SMTP 127 extensions must be expanded to include this one. 129 3. Protocol open questions 131 1. As noted in Section 2, above, these encapsulations, especially 132 the simple one that does not include the Envelope, may cause 133 conflicts with the "no multiple encodings" rule in MIME. 134 Whichever option is chosen, that issue needs to be carefully 135 studied, the cases examined, and an appropriate solution defined. 137 4. Security considerations 139 Since the approach described here essentially tunnels mail traffic 140 through the mail system, some of the same issues raised in the 141 Security Considerations to RFC 2442 may apply. In particular, if the 142 mechanism is used other than as a encapsulation mechanism for 143 internationalized messages that could be delivered without 144 encapsulation if all relevant SMTP servers were fully upgraded, 145 tunnels may be used to bypass existing security and verification 146 restrictions. For example, as RFC 2442 points out, such a tunnel 147 might allow someone to bypass relay or source- or target-address 148 filtering restrictions imposed to block distribution or 149 redistribution of spam. 151 5. Acknowledgements 153 The encapsulation mechanism for internationalized messages proposed 154 here was first mentioned in passing in another draft 155 [I-D.klensin.email-i18n]. After a discussion with Paul Hoffman about 156 that draft and how it might relate to other work and proposals, it 157 because clear that it would be helpful to write the encapsulation 158 proposal up separately for further discussion. 160 Normative References 162 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 163 Extensions (MIME) Part Two: Media Types", RFC 2046, 164 November 1996. 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels'", RFC 2119, March 1997. 169 [RFC2442] Freed, N., Newman, D. and Hoy, M., "The Batch SMTP Media 170 Type", RFC 2442, November 1998. 172 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 173 April 2001. 175 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 176 2001. 178 Informational References 180 [I-D.hoffman.utf-8] 181 Hoffman, P., "SMTP Service Extensions for Transmission of 182 Headers in UTF-8 Encoding", draft-hoffman-utf8headers-00 183 (work in progress), December 2003. 185 [I-D.klensin.email-i18n] 186 Klensin, J., "Internationalization of Email Addresses", 187 draft-klensin-emailaddr-i18n-02.txt (work in progress), 188 January 2004. 190 Author's Address 192 John C Klensin 193 1770 Massachusetts Ave, #322 194 Cambridge, MA 02140 195 USA 197 Phone: +1 617 491 5735 198 EMail: john-ietf@jck.com 200 Intellectual Property Statement 202 The IETF takes no position regarding the validity or scope of any 203 intellectual property or other rights that might be claimed to 204 pertain to the implementation or use of the technology described in 205 this document or the extent to which any license under such rights 206 might or might not be available; neither does it represent that it 207 has made any effort to identify any such rights. Information on the 208 IETF's procedures with respect to rights in standards-track and 209 standards-related documentation can be found in BCP-11. Copies of 210 claims of rights made available for publication and any assurances of 211 licenses to be made available, or the result of an attempt made to 212 obtain a general license or permission for the use of such 213 proprietary rights by implementors or users of this specification can 214 be obtained from the IETF Secretariat. 216 The IETF invites any interested party to bring to its attention any 217 copyrights, patents or patent applications, or other proprietary 218 rights which may cover technology that may be required to practice 219 this standard. Please address the information to the IETF Executive 220 Director. 222 Full Copyright Statement 224 Copyright (C) The Internet Society (2004). All Rights Reserved. 226 This document and translations of it may be copied and furnished to 227 others, and derivative works that comment on or otherwise explain it 228 or assist in its implementation may be prepared, copied, published 229 and distributed, in whole or in part, without restriction of any 230 kind, provided that the above copyright notice and this paragraph are 231 included on all such copies and derivative works. However, this 232 document itself may not be modified in any way, such as by removing 233 the copyright notice or references to the Internet Society or other 234 Internet organizations, except as needed for the purpose of 235 developing Internet standards in which case the procedures for 236 copyrights defined in the Internet Standards process must be 237 followed, or as required to translate it into languages other than 238 English. 240 The limited permissions granted above are perpetual and will not be 241 revoked by the Internet Society or its successors or assignees. 243 This document and the information contained herein is provided on an 244 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 245 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 246 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 247 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 248 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 250 Acknowledgment 252 Funding for the RFC Editor function is currently provided by the 253 Internet Society.