Internet Draft Laurence Lundblade QUALCOMM Inc. Expires: July 1997 November 1997 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 ds.internic.net (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. 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. Similarly the security multiparts explicitly list the hash algorithm before the hashed (signed) data so the correct hash algorithm can be used to calculate the hash on the data as it is processed. This is not the case with multipart/alternative MIME structures. 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 the second part or subsequent 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 by the multipart/alternative standard. If the processing is being done on a small device with limited memory it is most desirable to process the Laurence Lundblade Expires July 1997 [Page 1] Internet Draft One pass multipart/alternative processing November 1997 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 appropriate to reflow HTML to fit the display. Essentially, given some text that was composed with more than plain markup, (e.g., HTML), it is preferrable to format the text with knowledge of the display, than use generically formatted text (i.e., the text/plain part). This memo proposes a parameter addition to the multipart/alternative MIME type that lists the MIME types of its alternative components. This allows a one-pass processor of the multipart/alternative entity to pick which alternative to use before processing the entire entity. 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 Laurence Lundblade Expires July 1997 [Page 2] Internet Draft One pass multipart/alternative processing November 1997 ---separator- Content-type: text/html

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. ---separator--- 4. 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 `composite-type', `discrete-type' and `subtype' are defined by the MIME standard in RFC 2045. 5.References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Laurence Lundblade Expires July 1997 [Page 3] Internet Draft One pass multipart/alternative processing November 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, UDEL, August 1982. 6. 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 April 1997 [Page 4]