Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-palme-multipart-choices-00.txt Sweden Category-to-be: Proposed standard Date: December 2000 Expires: June 2000 The multipart/choices Content-Type 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. Copyright (C) The Internet Society 1999, 2000. All Rights Reserved. 1.1 Abstract This memo specifies that the existing MIME content-type "multipart/alternative" should be restricted to cases where the alternatives differ in their content-type. When the alternatives differ in other properties than content-type, a new "multipart/choices" content-type is to be used instead. This is necessary, because the present specification gives extremely bad downgrading for mailers not supporting use of "multipart/alternative" for other differences than content-type. This memo also specifies a mandatory parameter to multipart/choices. This mandatory parameter will hopefully avoid the same problem occuring again in the future. This memo upgrades RFC 2046 MIME Media Types [5] and RFC 1766 Language tags [6]. 1.2 Mailing list To write Further discussion of this memo can take place in the mailing list WG- LANGTRANS@SU.SE. Comments on less important details may also be sent to the editor, Jacob Palme <jpalme@dsv.su.se>. To subscribe To subscribe to this mailing list, send a message to LISTSERV@SU.SE which contains the text SUB[SCRIBE] LANGTRANS <your name (not your email address)> To unsubscribe To unsubscribe from this list, send a message to LISTSERV@SU.SE which contains the text UNS[UBSCRIBE] LANGTRANS To access mailing list archives The archives are available for browsing from http://salut.nu/forum/uno/6/1/ Use the browsing command "All messages" to get everything written on a single web page. Table of Contents 2 Overview 3 The multipart/choices MIME Content Type 3.1 Syntax 3.2 Semantics 3.2.1 The Selector Attribute 3.2.2 Receipt of multipart/choices 3.2.3 Body parts within multipart/choices 4 Example 5 For Further Study 6 IANA Registry Issues 7 Security Considerations 8 Copyright and Disclaimer 9 Acknowledgments 10 References 11 Author's Address 2 Overview The MIME Standard for e-mail media types, RFC 2046 specifies the following usage of the Conten-Type "multipart/alternative": Systems should recognize that the content of the various parts are interchangeable. Systems should choose the "best" type based on the local environment and references, in some cases even through user interaction. Unfortunately, existing implementation experience shows that this works disastrously bad, when the difference between the alternatives is another difference than a different Content-Type. A test of some common mail clients in the fall of the year 2000 gave the following result when handling incoming e-mail using multipart/alternative, and where the difference betweeen the body types was different value in the Content-Language heading: Eudora 5 Macintosh, Outlook Express 5 Macintosh, KOM 2000 and Hotmail ALWAYS showed the first alternative, independently of the value of the Content-Language heading. They did in no way give the user any option at all of seeing any of the other alternatives. Pine 4.21 only showed the last body part, but provided a command to see the other alternatives. First Class 5.611 traited multipart/alternative as multipart/mixed, which actually was better than any of the other mailers in this case. Apparently, most of the implemetations does understand that it should only show one of the alternative body parts, but does not understand how to choose which part to show in an acceptable way. The correct way, for a mailer which does not understand "Content-Language" would be to ask the user, but none of the mailers did this. Actually, to decide which is the best alternative to show to a user is a rather complex task in the general case. A mailer must compare all the different features which differ between the body parts, decide which is most important, then make a choice, or decide that it cannot make a choice, and then ask the user. This may be too complex to require from mailers, so the solution in this memo tries to make this task easier for the mailers. This memo solves the problem in the following way: (1) The existing content-type multipart/alternative is restricted to only be used when the difference between the alternatives is that they have different content-type. (2) For all other differences between the alternatives, a new content- type multipart/choices is proposed. (3) To avoid similar problems with multipart/choices in the future, which multipart/alternative has today, a mandatory attribute "selector" is specified for multipart/choices. This mandatory attribute specifies what is the main difference between the alternatives, for example: Content-Type: multipart/choices; selector=Content-Language A mailer which does not understand how to handle the value specified in the selector attribute, MUST either handle multipart/choices as multipart/mixed, or let the user choose which choice to read. Such a mailer MUST NOT arbitrarily select one of the choices and display only that choice to the user. The value of the selector attribute SHOULD be a "Content-"heading or some other distinguishing factor. At present, only Content-Language is specified, but other differentiating factors may be added as needed. 3 The multipart/choices MIME Content Type 3.1 Syntax The syntax for multipart/choices is the same as the syntax for "content" as defined in RFC 2045 [4] and RFC 2046 [5], and thus, the boundary parameter is mandatory as specified in RFC 2046 [5]. The Content-Type multipart/choices has an additional "parameter" as defined in RFC 2045 section 5.1 [4]. The "token" (as defined in RFC 2045 [4] section 5.1) for this additional parameter is "selector" and the "value" (as defined in RFC 2045 [4] section 5.1) has the syntax: value = "Content-Language" | "Content-Type" | "charset" other-values-to-be-defined The matching of values to the "selector" attribute is case-insensitive. 3.2 Semantics The multipart/choices content-type is to be used when the different body parts contain the same information but differ in some other property than different than their content-types. multipart/choices has a mandatory parameter "selector" with a value which indicates how the choices differ. In this first version of this standard, the only specified values for "selector" is "Content-Language", "Content-Type" and "charset", but other selectors may be added as needed in the future. The semantics of multipart/choices is similar to the semantics of multipart/alternative as specified in RFC 2046 [5] section 5.1.4 with the following differences: 3.2.1 The Selector Attribute The "selector" attribute is mandatory for multipart/choices and it SHOULD indicate in what way the sender intends the body parts to differ. The following values of the selector attributes are defined here; additional values may be added in future standards. selector=Content-Language The body parts differ in the value of their Content-Language header as defined in RFC 1766 [6]. selector=Content-Type The body parts differ in the value of their Content-Type header as defined in RFC 2045 [4]. selector=charset The body parts differ in the "charset" attribute to the Content-Type header as defined in RFC 2046 [5] section 4.1.2. 3.2.2 Receipt of multipart/choices A mailer receiving a multipart/choices message, SHOULD select a body part to display to the user based on the SELECTOR, or let the user manually select a body part to display, after informing the user of the SELECTOR value. A mailer which cannot handle multipart/choices SHOULD handle it as multipart/mixed. A mailer SHOULD NOT (without manual permission for this particularm essage by theu ser) choose a body part to display based on other differences than those indicated by the SELECTOR value. 3.2.3 Body parts within multipart/choices The included body parts must be different in the way specified by the selector attribute, and this difference must be visible on the outermost level of each included body part. Thus, in the following example, both Content-Language headers are required, and not only the second of them: Content-Type: multipart/choices; selector=Content-Language; boundary="boundary-1" --boundary-1 Content-Type Multipart/related; boundary="boundary-2" Content-Language: en -- boundary-2 Content-Type text/html; charset=iso-8859-1 Content-Language: en English HTML-formatted text -- boundary-2 Content-Type: image/gif Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... 4 Example In this example, the Content-Type of the included body parts is Message/rfc822, in order to allow also the subject to be provided in more than one language. Note that the Content-Language header must be repeated twice in each body part, once in the RFC822-header and once in the content-header. Message-ID: Z@foo.bar.net From: John Smith <jsmit@foo.bar.net> Content-Type: multipart/choices; boundary="boundary 1"; selector="Content-Language" To: Tropical Flowers Mailing List <tropflow@foo.bar.net> Subject: (en) Orchids --boundary 1 Content-Language: en Content-Type: Message/rfc822 Message-ID: Z-en@foo.bar.net From: John Smith <jsmit@foo.bar.net> To: Tropical Flowers Mailing List <tropflow@foo.bar.net> Content-Type: Text/plain; charset=iso-8859-1 Content-Language: en Subject: (en) Orchids Orchids are beautiful. --boundary 1 Content-Language: de Content-Type: Message/rfc822 Message-ID: Z-de@foo.bar.net From: John Smith <jsmit@foo.bar.net> Content-Type: Text/plain; charset=iso-8859-1 Content-Language: de Subject: (de) Orchideen Orchideen sind sch÷n. --boundary 1 Content-Language: fr Content-Type: Message/rfc822 Message-ID: Z-fr@foo.bar.net Content-Type: Text/plain; charset=iso-8859-1 Content-Language: fr Subject: (fr) Orchide Orchide sont beau. --boundary 1-- 5 For Further Study The following is not yet resolved in this draft: - Is there a need for an IANA registry of values for the selector attribuge? - Does this proposal require any changes to POP and/or IMAP. 6 IANA Registry Issues Your name: Jacob Palme Your e-mail address: jpalme@dsv.su.se Mime Media Type Name: multipart Mime subtype name: choices Required parameters: selector Optional parameters: None Encoding considerations: None Security considerations: None known Interoperability considerations: Will interoperate with older mailers much better than multipart/alternative. Published specifications: This memo. Applications which use this media type: E-mail user agents. Magic number(s): ot specified. File extension(s): ot specified. Macintosh File type Code(s): ot specified. Object Identifier(s): Not specified. Person to contact for further information: Jacob Palme <jpalme@dsv.su.se> Change controller: IETF. 7 Security Considerations The present way in which multipart/alternative is handled by major mailers is an obvious security risk - people will be shown a message they cannot understand or in an otherwise unsuitable language. Arbritrarily selecting one of several of the alternatives is obviously and hiding all the other alternatives from the user is obviously not good. No new security problems are caused by this standard, if implemented correctly. 8 Copyright and Disclaimer 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. Copyright (C) The Internet Society (2000). 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 assigns. 9 Acknowledgments Suggestions during the development of this memo has been given by Harald Alvestrand, John Clews, Steve Goldstein, Bill Jansson, Larry Masinter, Keith Moore, Chris Newman and Henry Spencer. 10 References Ref. Author, title IETF status (July 1996) ----- --------------------------------------------- ----------- [1] J. Postel: "Simple Mail Transfer Protocol", Standard, STD 10, RFC 821, August 1982. Recommended [2] D. Crocker: "Standard for the format of ARPA Standard, Internet text messages." STD 11, RFC 822, Recommended August 1982. [3] M.R. Horton, R. Adams: "Standard for Not an interchange of USENET messages", RFC 1036, official December 1987. IETF standard, but in reality a de- facto standard for Usenet News [4] N. Freed & N. Borenstein: "Multipurpose Draft Internet Mail Extensions (MIME) Part One: Standard, Format of Internet Message Bodies." RFC 2045. elective November 1996. [5] N. Freed & N. Borenstein: "Multipurpose Draft Internet Mail Extensions (MIME) Part Two: Standard, Media Types." RFC 2046. November 1996. elective [6] H. Alvestrand: "Tags for the Identification Proposed of Languages", RFC 1766, February 1995. standard, elective [7] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, Draft T. Berners-Lee: Hypertext Transfer Protocol - standard - HTTP/1.1, RFC 2616, June 1999. [8] J. Palme: The Auto-Submitted, Supersedes and Work in Expires Headers in E-mail and Netnews, draft- progress ietf-mailext-new-fields-14.txt, November 1998. 11 Author's Address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Skeppargatan 73 E-mail: jpalme@dsv.su.se S-115 30 Stockholm, Sweden