Internet Draft: The TEXT/PLAIN FORMAT Parameter R. Gellens, Editor Document: draft-gellens-format-00.txt Qualcomm Expires: 7 February 1999 7 August 1998 The TEXT/PLAIN FORMAT Parameter 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Comments A version of this draft document is intended for submission to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Private comments should be sent to the author. Public comments may be sent to the IETF 822 mailing list, <ietf-822@imc.org>. To subscribe, send a message to <ietf-822-request@imc.org> with the word SUBSCRIBE as the body of the message. Archives for the list are at <http://www.imc.org/ietf-822/>. Comments are especially desired on the problems mentioned in section 7, in particular where the text "[[[COMMENTS?]]]" appears. Copyright Notice Copyright (C) The Internet Society 1998. All Rights Reserved. Gellens [Page 1] Expires February 1999Internet Draft The FORMAT Parameter August 1998 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . . 3 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . . 3 4. The FORMAT Parameter to the TEXT/PLAIN Media Type . . . . . 4 5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Line Analysis Table . . . . . . . . . . . . . . . . . . . . 5 7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Trailing White Space Corruption . . . . . . . . . . . . 5 7.2. The Usenet Signature Convention . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 7 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7 1. Introduction Interoperability problems have been observed with erroneous labelling of paragraph text as TEXT/PLAIN, and with various forms of "embarrassing line wrap." (See section 3.) Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and TEXT/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end. What is desired is a format which is in all significant ways TEXT/PLAIN, and therefore is quite suitable for display as TEXT/PLAIN, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate. This memo proposes a new parameter to be used with TEXT/PLAIN, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal TEXT/PLAIN in older implementations, since it is in fact normal TEXT/PLAIN. 2. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Gellens [Page 2] Expires February 1999Internet Draft The FORMAT Parameter August 1998 3. The Problem The TEXT/PLAIN media type is the lowest common denominator of Internet email, with lines of no more than 998 characters (by convention usually no more than 80), and where the CRLF sequence represents a line break [MIME-IMT]. TEXT/PLAIN is usually displayed as preformatted text, often in a fixed font. That is, the characters start at the left margin of the display window, and advance to the right until a CRLF sequence is seen, at which point a new line is started, again at the left margin. When a line length exceeds the display window, some clients will wrap the line, while others invoke a horizontal scroll bar. Some interoperability problems have been observed with this media type: 3.1. Paragraph Text Many modern programs use a proportional-spaced font and CRLF to represent paragraph breaks. Line breaks are "soft", occurring as needed on display. That is, characters are grouped into a paragraph until a CRLF sequence is seen, at which point a new paragraph is started. Each paragraph is displayed, starting at the left margin (or paragraph indent), and continuing to the right until a word is encountered which does not fit in the remaining display width. The display shifts to the next line, starting with the word which would not fit on the previous line. This continues until the paragraph ends (a CRLF is seen). Extra vertical space is left between paragraphs. Numerous software products erroneously label this media type as TEXT/PLAIN, resulting in much user discomfort. 3.2. Embarrassing Line Wrap As TEXT/PLAIN messages get quoted in replies or forwarded, the length of each line gradually increases, resulting in "embarrassing line wrap." This results in text which is at best hard to read, and often confuses attributions. In addition, as devices with display widths smaller than 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text. 3.3. New Media Types Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and TEXT/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end. Gellens [Page 3] Expires February 1999Internet Draft The FORMAT Parameter August 1998 In particular, TEXT/ENRICHED requires that open angle brackets ("<") and hard line breaks be doubled, with resulting user unhappiness when viewed as TEXT/PLAIN. TEXT/HTML requires even more alteration of text, with a corresponding increase in user complaints. A proposal to define a new media type to explicitly represent the paragraph form suffered from a lack of interoperability with currently deployed software. Some programs treat unknown subtypes of TEXT as an attachment. What is desired is a format which is in all significant ways TEXT/PLAIN, and therefore is quite suitable for display as TEXT/PLAIN, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate. 4. The FORMAT Parameter to the TEXT/PLAIN Media Type This document defines a new MIME parameter for use with TEXT/PLAIN: Name: Format Value: Fixed-Lines, Flowed (Neither the parameter name nor its value are case sensitive.) If not specified, a value of Fixed-Lines is assumed. The semantics of the Fixed-Lines value are the usual associated with TEXT/PLAIN [MIME-IMT]. A value of Flowed indicates that any line which ends in exactly one space MAY be treated as a "flowed" line. A series of one or more such lines is considered a paragraph, and MAY be flowed (wrapped and unwrapped) as appropriate on display and in the construction of new messages (see section 5). A line consisting of exactly one space is considered a flowed line. Because flowed lines are all-but-indistinguishable from fixed lines, currently deployed software will treat flowed lines as normal TEXT/PLAIN (which is what they are). Thus, no interoperability problems are expected. 5. Quoting When Format=Flowed, the canonical quote indicator is an open angle bracket (">"), optionally followed by a space ("> "). Lines which start with one or more quote indicators are considered quoted. Flowed lines which are also quoted may require special handling on display and when copied to new messages. Gellens [Page 4] Expires February 1999Internet Draft The FORMAT Parameter August 1998 When creating quoted flowed lines, each such line MUST start with one or more quote indicators. If a receiving agent wishes to reformat flowed quoted lines (joining and/or wrapping them) on display or when generating new messages, the lines SHOULD be dequoted, reformatted, and then requoted. To dequote, the number of quote indicators at the start of each line is counted. Consecutive lines with the same quoting depth are considered one logical entity and are reformatted together. To requote after reformatting, the same number of quote indicators originally present are prefixed to each line. Either ">" or "> " MAY be used to requote, but the agent SHOULD be consistent. 6. Line Analysis Table Lines contained in a TEXT body part with Format=Flowed can be analyzed by examining the start and end of the line. If the line starts with one ore more quote indicators, it is quoted. If the line ends with exactly one space character, it is flowed. This is summarized by the following table: Starts Ends in with Exactly Line Quote One Space Type ------ --------- --------------- no no unquoted, fixed yes no quoted, fixed no yes unquoted, flowed yes yes quoted, flowed 7. Failure Modes 7.1. Trailing White Space Corruption There are systems in existence which alter trailing whitespace on messages which pass through them. Such systems may strip, or in rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP] section 4.5.2. Stripping trailing whitespace has the effect of converting flowed lines to fixed lines, which results in a message no worse than if the parameter had not been used. Adding trailing whitespace most often has no effect or merely converts flowed lines to fixed, but if exactly one trailing space is added to one or more lines of a message which uses the Format=Flowed parameter, the effect may be a corrupted display or reply. Since most systems which add trailing white space do so to create a line which fills an internal record format, the result is almost always a line which contains an even number of characters (counting the added Gellens [Page 5] Expires February 1999Internet Draft The FORMAT Parameter August 1998 trailing white space). One possible avoidance, therefore, would be to define Format=Flowed lines to use either one or two trailing space characters to indicate a flowed line, such that the total line length is odd. However, considering the scarcity of such systems today, it is not worth the added complexity. [[[COMMENTS?]]] 7.2. The Usenet Signature Convention There is a convention in Usenet news of using "-- " as the separator line between the body and the signature of a message. If such a line is present in a Format=Flowed message, a receiving system may erroneously flow the first line of the signature with the signature separator line on display or in the creation of new messages. This could be avoided by (a) treating "-- " as a special case, (b) advising user agents which create Format=Flowed messages to put the signature (and separator line) in an additional body part or use either zero or two spaces in the signature separator, or (c) define Format=Flowed lines to use two trailing space characters to indicate a flowed line (or either two or three, to also deal with trailing white space corruption). As the "-- " convention is not widely used on receipt, it is not considered worth extra complexity to avoid. [[[COMMENTS?]]] 8. Security Considerations This parameter introduces no security considerations beyond those which apply to text/plain. 9. Acknowledgments This proposal evolved from a discussion of Chris Newman's TEXT/PARAGRAPH draft, which took place on the IETF 822 mailing list. 10. References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RICH] Resnick, Walker, "The text/enriched MIME Content-type", RFC 1896, QUALCOMM, InterCon, February 1996. [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, November 1996. Gellens [Page 6] Expires February 1999Internet Draft The FORMAT Parameter August 1998 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, Information Sciences Institute, August 1982. 11. Editor's Address Randall Gellens +1 619 651 5115 QUALCOMM Incorporated randy@qualcomm.com 6455 Lusk Blvd. San Diego, CA 92121-2779 USA 12. Full Copyright Statement 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 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. Gellens [Page 7] Expires February 1999