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
<http://www.imc.org/ietf-imaa/> 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]