Network Working Group J. Klensin Internet-Draft February 2, 2004 Expires: August 2, 2004 The MIME Message/i18n Media Type draft-klensin-email-i18n-message-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 2, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Efforts to design an internationalization model for electronic mail frequently encounter situations in which an internationalized message -- perhaps one containing some headers with characters coded in UTF-8 -- must be converted and transported over a traditional, 7-bit infrastructure. This document provides a specification, building on the design of message/rfc822, for encapsulating messages with internationalized headers and/or body part content types. This specification is one of a group intended to provide a modified and extended email environment for fully internationalized email. If approved, it is expected to update the discussion of "message/" content types in RFC 2046. Klensin Expires August 2, 2004 [Page 1] Internet-Draft The MIME Message/i18n Media Type February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Mailing List . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol open questions . . . . . . . . . . . . . . . . . . . 4 4. Security considerations . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 Normative References . . . . . . . . . . . . . . . . . . . . . 5 Informational References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 6 Klensin Expires August 2, 2004 [Page 2] Internet-Draft The MIME Message/i18n Media Type February 2004 1. Introduction If a message is permitted to contain headers in UTF-8 (see, e.g., [I-D.hoffman.utf-8] and the discussion in [I-D.klensin.email-i18n]), the need will periodically arise to carry it over a traditional 7bit (unextended SMTP or ESMTP) infrastructure. In general, there are two ways to approach that problem. One is to specify and implement a model for "downgrading", or otherwise encoding, all of the fields that contain (or potentially content) non-ASCII information. That approach is difficult to define properly, especially given the number of variations in email header fields and the number of fields whose precise syntax and semantics are not defined anywhere. The alternative is to simply encapsulate the message and headers, using a content-transfer-encoding to deal with the 8bit material if needed, and retaining in the outermost headers only that information that can be retained without ambiguity or is required by the message format specification [RFC2822]. The general strategy for this type of encapsulation was developed in the base MIME specification [RFC2046]; this document extends that one to provide a specification for encapsulation of internationalized messages. 1.1 Terminology This document assumes a reasonable understanding of the protocols and terminology of the most recent core email standards documented in RFC 2821 [RFC2821] and RFC 2822 [RFC2822] and of the MIME media type structures described in [RFC2046]. In this document, an address or header field is "all-ASCII" if every character in the address or field is in the ASCII character repertoire [ASCII]; an address, header field, or string is "non-ASCII" if any character is not in the ASCII character repertoire. The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Mailing List This document is being discussed on the ietf-imaa mailing list. See for information about subscribing and the list's archive. 2. Proposal Overview Two different models are possible for encapsulating an internationalized message into a MIME body part. While they are Klensin Expires August 2, 2004 [Page 3] Internet-Draft The MIME Message/i18n Media Type February 2004 quite similar, the community should examine the tradeoffs and select one of them. Even were the choice arbitrary, interoperability would call for a single choice, without options. Message Encapsulation In this model, the message body (including headers) is encapsulated, identically to the model for "message/ rfc822" but with the expectation that some or all headers may contain UTF-8 data and therefore may require encoding. This may raise issues with the multiple encoding rule, which will need to be worked out if this option is chosen. Mail Transaction Encapsulation In this model, the entire message transmission, including the ESMTP envelope, is encapsulated and incorporated into the message body. This model is identical to the one outlined in [RFC2442]. That standard already provides for header and envelope information potentially being in UTF-8 form, not exclusively in ASCII. However, obviously, for this extension to be permitted to be encapsulated, the list of permitted SMTP extensions must be expanded to include this one. 3. Protocol open questions 1. As noted in Section 2, above, these encapsulations, especially the simple one that does not include the Envelope, may cause conflicts with the "no multiple encodings" rule in MIME. Whichever option is chosen, that issue needs to be carefully studied, the cases examined, and an appropriate solution defined. 4. Security considerations Since the approach described here essentially tunnels mail traffic through the mail system, some of the same issues raised in the Security Considerations to RFC 2442 may apply. In particular, if the mechanism is used other than as a encapsulation mechanism for internationalized messages that could be delivered without encapsulation if all relevant SMTP servers were fully upgraded, tunnels may be used to bypass existing security and verification restrictions. For example, as RFC 2442 points out, such a tunnel might allow someone to bypass relay or source- or target-address filtering restrictions imposed to block distribution or redistribution of spam. 5. Acknowledgements The encapsulation mechanism for internationalized messages proposed here was first mentioned in passing in another draft [I-D.klensin.email-i18n]. After a discussion with Paul Hoffman about that draft and how it might relate to other work and proposals, it because clear that it would be helpful to write the encapsulation proposal up separately for further discussion. Klensin Expires August 2, 2004 [Page 4] Internet-Draft The MIME Message/i18n Media Type February 2004 Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels'", RFC 2119, March 1997. [RFC2442] Freed, N., Newman, D. and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Informational References [I-D.hoffman.utf-8] Hoffman, P., "SMTP Service Extensions for Transmission of Headers in UTF-8 Encoding", draft-hoffman-utf8headers-00 (work in progress), December 2003. [I-D.klensin.email-i18n] Klensin, J., "Internationalization of Email Addresses", draft-klensin-emailaddr-i18n-02.txt (work in progress), January 2004. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires August 2, 2004 [Page 5] Internet-Draft The MIME Message/i18n Media Type February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Klensin Expires August 2, 2004 [Page 6] Internet-Draft The MIME Message/i18n Media Type February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires August 2, 2004 [Page 7]