Internet Draft Laurence Lundblade draft-lundblade-1pass-mult-alt-01.txt QUALCOMM Inc. Expires: February 1999 August 1998 One Pass Multipart/Alternative Processing Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before July 1997. Distribution of the draft is unlimited. Note: This draft may be discussed on the 822 mailing list at ietf-822@imc.org. Copyright Notice Copyright (c) The Internet Society 1998. All rights reserved. 1. Introduction Most MIME syntax and semantics can usually be processed in a single pass through the data. For example, the MIME boundary parameter always appears before it is used. This is not the case with multipart/alternative MIME entities. The processor of the data cannot know the MIME types of the altnernatives present until all alternatives have been processed. Thus, it is not possible for a one pass processor to consider more than the first and most limited representation, because a subsequent part may be something that cannot be handled. A particular case of this occurs with alternative representations of types text/plain and text/html or text/enriched formats. The text/plain representation must come first as required for multipart/alternative entities. If the processing is being done on a small device with Laurence Lundblade Expires February 1999 [Page 1]
Internet Draft One pass multipart/alternative processing August 1998 limited memory it is most desirable to process the structure in one pass. If the display is also small, for example 40 colums rather than 80, it is desirable to use the text/html alternative because it is appropriate to reflow HTML to fit the display. This memo proposes a parameter addition for the multipart/alternative MIME type that lists the MIME types of its alternative components. This allows a one-pass processing of most multipart/alternative entities. 2. The "types" parameter The "types" parameter is a comma separated list of the MIME types of the parts that make up the multipart/altnertive MIME entity. The order of the listed types corresponds to the order of the parts. Note that this parameter must be quoted because MIME type identifiers always include the "/" character which must be quoted. Spaces are not permitted between the MIME types or adjacent to the separating commas. (Allowing spaces provides no advantages and would complicate parsing). 3. An Example The following is an example for how this might be used for HTML and plain text parts: Content-type: multipart/alternative; boundary="-separator-"; types="text/plain,text/html" ---separator- Content-type: text/plain This paragraph of text in its orginal form can be reflowed to fit nicely on screens of many different widths. However if you use the text/plain rendition of it the text has been formatted with fixed line lengths and adjusting it for a screen size that is not an integer fraction of fixed length will not look very good. ------------------------------------------------------------------------------------- In addition HTML constructs in the list below can be fomatted to look much nicer than the plain text version without implementing a full web browser. * Centered text can be correctly centered * Bulleted lists can use the local bullet character * Horizontal rules can be the correct width for the display * Special characters such currency symbols can be displayed correct. Note that often the plain text rendition is US-ASCII only. * Bold, italic and underlining ---separator- Content-type: text/html Laurence Lundblade Expires February 1999 [Page 2]
Internet Draft One pass multipart/alternative processing August 1998 <HTML> <BODY><P> This paragraph of text in its orginal form can be reflowed to fit nicely on screens of many different widths. However if you use the text/plain rendition of it the text has been formatted with fixed line lengths and adjusting it for a screen size that is not an integer fraction of fixed length will not look very good.</P> <hr> In addition HTML constructs in the list below can be fomatted to look much nicer than the plain text version without implementing a full web browser. <UL> <LI> Centered text can be correctly centered</LI> <LI> Bulleted lists can use the local bullet character</LI> <LI> Horizontal rules can be the correct width for the display</LI> <LI> Special characters such currency symbols can be displayed correct. Note that often the plain text rendition is US-ASCII only.</LI> <LI> Bold, italic and underlining</LI> </UL> </BODY> </HTML> ---separator--- 4. Use with multipart/related entities When multipart/alternative is used with multipart/related it may be nested inside the multipart/related entity or vice versa. There is no special handling for the types parameter in either case. However it is noted that the types parameter provides little useful information when the multipart/related entity is nested within the multipart/alternative entity. This is because it is not possible to know about the format of the content contained in the multipart/related alternative. When nested the opposite way the types parameter is useful. Example of header for the less useful multipart/alternative containing a multipart/related: Content-type: multipart/alternative; boundary="separator"; types="text/plain,multipart/related" 5. The Grammar This grammar does not allow RFC-822 comments, white space insertion, or line folding. types-parameter = "types" "=" <"> types-list <"> types-list = mime-type / mime-type "," types-list mime-type = composite-type / discrete-type "/" subtype Laurence Lundblade Expires February 1999 [Page 3]
Internet Draft One pass multipart/alternative processing August 1998 `composite-type', `discrete-type' and `subtype' are defined by the MIME standard in RFC 2045. 6. References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2045] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. [RFC 2046] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, December 1996. [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC 2837] Levinson, E., "The MIME Multipart/related Content-type" RFC 2112, August 1998 7. Full Copyright Copyright (C) The Internet Society (1998). 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. 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 Laurence Lundblade Expires February 1999 [Page 4]
Internet Draft One pass multipart/alternative processing August 1998 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Author's Address Laurence Lundblade QUALCOMM Inc. 6455 Lusk Blvd. San Diego, Ca, 92121 USA Phone: +1 619-658-3584 Email: lgl@qualcomm.com Laurence Lundblade Expires February 1999 [Page 5]