idnits 2.17.1 draft-gellens-format-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HTML' is mentioned on line 151, but not defined ** Downref: Normative reference to an Informational RFC: RFC 1896 (ref. 'RICH') ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: The TEXT/PLAIN FORMAT Parameter R. Gellens, Editor 3 Document: draft-gellens-format-00.txt Qualcomm 4 Expires: 7 February 1999 7 August 5 1998 7 The TEXT/PLAIN FORMAT Parameter 9 Status of this Memo: 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress." 22 To learn the current status of any Internet Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet Drafts shadow 24 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Comments 30 A version of this draft document is intended for submission to the 31 RFC editor as a Proposed Standard for the Internet Community. 32 Discussion and suggestions for improvement are requested. 34 Private comments should be sent to the author. Public comments may 35 be sent to the IETF 822 mailing list, . To 36 subscribe, send a message to with the 37 word SUBSCRIBE as the body of the message. Archives for the list 38 are at . 40 Comments are especially desired on the problems mentioned in section 41 7, in particular where the text "[[[COMMENTS?]]]" appears. 43 Copyright Notice 45 Copyright (C) The Internet Society 1998. All Rights Reserved. 47 Gellens [Page 1] Expires February 48 1998 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 54 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3 57 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . . 3 58 4. The FORMAT Parameter to the TEXT/PLAIN Media Type . . . . . 4 59 5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Line Analysis Table . . . . . . . . . . . . . . . . . . . . 5 61 7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Trailing White Space Corruption . . . . . . . . . . . . 5 63 7.2. The Usenet Signature Convention . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 7 68 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Interoperability problems have been observed with erroneous 73 labelling of paragraph text as TEXT/PLAIN, and with various forms of 74 "embarrassing line wrap." (See section 3.) 76 Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and 77 TEXT/HTML [HTML] have suffered from a lack of backwards 78 compatibility and an often hostile user reaction at the receiving 79 end. 81 What is desired is a format which is in all significant ways 82 TEXT/PLAIN, and therefore is quite suitable for display as 83 TEXT/PLAIN, and yet allows the sender to express to the receiver 84 which lines can be considered a logical paragraph, and thus flowed 85 (wrapped and joined) as appropriate. 87 This memo proposes a new parameter to be used with TEXT/PLAIN, and, 88 in the presence of this parameter, the use of trailing whitespace to 89 indicate flowed lines. This results in an encoding which appears as 90 normal TEXT/PLAIN in older implementations, since it is in fact 91 normal TEXT/PLAIN. 93 2. Conventions Used in this Document 95 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 96 NOT", and "MAY" in this document are to be interpreted as described 97 in "Key words for use in RFCs to Indicate Requirement Levels" 98 [KEYWORDS]. 100 Gellens [Page 2] Expires February 101 1998 103 3. The Problem 105 The TEXT/PLAIN media type is the lowest common denominator of 106 Internet email, with lines of no more than 998 characters (by 107 convention usually no more than 80), and where the CRLF sequence 108 represents a line break [MIME-IMT]. 110 TEXT/PLAIN is usually displayed as preformatted text, often in a 111 fixed font. That is, the characters start at the left margin of the 112 display window, and advance to the right until a CRLF sequence is 113 seen, at which point a new line is started, again at the left 114 margin. When a line length exceeds the display window, some clients 115 will wrap the line, while others invoke a horizontal scroll bar. 117 Some interoperability problems have been observed with this media 118 type: 120 3.1. Paragraph Text 122 Many modern programs use a proportional-spaced font and CRLF to 123 represent paragraph breaks. Line breaks are "soft", occurring as 124 needed on display. That is, characters are grouped into a paragraph 125 until a CRLF sequence is seen, at which point a new paragraph is 126 started. Each paragraph is displayed, starting at the left margin 127 (or paragraph indent), and continuing to the right until a word is 128 encountered which does not fit in the remaining display width. The 129 display shifts to the next line, starting with the word which would 130 not fit on the previous line. This continues until the paragraph 131 ends (a CRLF is seen). Extra vertical space is left between 132 paragraphs. 134 Numerous software products erroneously label this media type as 135 TEXT/PLAIN, resulting in much user discomfort. 137 3.2. Embarrassing Line Wrap 139 As TEXT/PLAIN messages get quoted in replies or forwarded, the 140 length of each line gradually increases, resulting in "embarrassing 141 line wrap." This results in text which is at best hard to read, and 142 often confuses attributions. 144 In addition, as devices with display widths smaller than 80 145 characters become more popular, embarrassing line wrap has become 146 even more prevalent, even with unquoted text. 148 3.3. New Media Types 150 Attempts to deploy new media types, such as TEXT/ENRICHED [RICH] and 151 TEXT/HTML [HTML] have suffered from a lack of backwards 152 compatibility and an often hostile user reaction at the receiving 153 end. 155 Gellens [Page 3] Expires February 156 1998 158 In particular, TEXT/ENRICHED requires that open angle brackets ("<") 159 and hard line breaks be doubled, with resulting user unhappiness 160 when viewed as TEXT/PLAIN. TEXT/HTML requires even more alteration 161 of text, with a corresponding increase in user complaints. 163 A proposal to define a new media type to explicitly represent the 164 paragraph form suffered from a lack of interoperability with 165 currently deployed software. Some programs treat unknown subtypes 166 of TEXT as an attachment. 168 What is desired is a format which is in all significant ways 169 TEXT/PLAIN, and therefore is quite suitable for display as 170 TEXT/PLAIN, and yet allows the sender to express to the receiver 171 which lines can be considered a logical paragraph, and thus flowed 172 (wrapped and joined) as appropriate. 174 4. The FORMAT Parameter to the TEXT/PLAIN Media Type 176 This document defines a new MIME parameter for use with TEXT/PLAIN: 178 Name: Format 179 Value: Fixed-Lines, Flowed 181 (Neither the parameter name nor its value are case sensitive.) 183 If not specified, a value of Fixed-Lines is assumed. The semantics 184 of the Fixed-Lines value are the usual associated with TEXT/PLAIN 185 [MIME-IMT]. 187 A value of Flowed indicates that any line which ends in exactly one 188 space MAY be treated as a "flowed" line. A series of one or more 189 such lines is considered a paragraph, and MAY be flowed (wrapped and 190 unwrapped) as appropriate on display and in the construction of new 191 messages (see section 5). 193 A line consisting of exactly one space is considered a flowed line. 195 Because flowed lines are all-but-indistinguishable from fixed lines, 196 currently deployed software will treat flowed lines as normal 197 TEXT/PLAIN (which is what they are). Thus, no interoperability 198 problems are expected. 200 5. Quoting 202 When Format=Flowed, the canonical quote indicator is an open angle 203 bracket (">"), optionally followed by a space ("> "). Lines which 204 start with one or more quote indicators are considered quoted. 205 Flowed lines which are also quoted may require special handling on 206 display and when copied to new messages. 208 Gellens [Page 4] Expires February 209 1998 211 When creating quoted flowed lines, each such line MUST start with 212 one or more quote indicators. 214 If a receiving agent wishes to reformat flowed quoted lines (joining 215 and/or wrapping them) on display or when generating new messages, 216 the lines SHOULD be dequoted, reformatted, and then requoted. To 217 dequote, the number of quote indicators at the start of each line is 218 counted. Consecutive lines with the same quoting depth are 219 considered one logical entity and are reformatted together. To 220 requote after reformatting, the same number of quote indicators 221 originally present are prefixed to each line. Either ">" or "> " 222 MAY be used to requote, but the agent SHOULD be consistent. 224 6. Line Analysis Table 226 Lines contained in a TEXT body part with Format=Flowed can be 227 analyzed by examining the start and end of the line. If the line 228 starts with one ore more quote indicators, it is quoted. If the 229 line ends with exactly one space character, it is flowed. This is 230 summarized by the following table: 232 Starts Ends in 233 with Exactly Line 234 Quote One Space Type 235 ------ --------- --------------- 236 no no unquoted, fixed 237 yes no quoted, fixed 238 no yes unquoted, flowed 239 yes yes quoted, flowed 241 7. Failure Modes 243 7.1. Trailing White Space Corruption 245 There are systems in existence which alter trailing whitespace on 246 messages which pass through them. Such systems may strip, or in 247 rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP] 248 section 4.5.2. 250 Stripping trailing whitespace has the effect of converting flowed 251 lines to fixed lines, which results in a message no worse than if 252 the parameter had not been used. 254 Adding trailing whitespace most often has no effect or merely 255 converts flowed lines to fixed, but if exactly one trailing space is 256 added to one or more lines of a message which uses the Format=Flowed 257 parameter, the effect may be a corrupted display or reply. Since 258 most systems which add trailing white space do so to create a line 259 which fills an internal record format, the result is almost always a 260 line which contains an even number of characters (counting the added 262 Gellens [Page 5] Expires February 263 1998 265 trailing white space). 267 One possible avoidance, therefore, would be to define Format=Flowed 268 lines to use either one or two trailing space characters to indicate 269 a flowed line, such that the total line length is odd. However, 270 considering the scarcity of such systems today, it is not worth the 271 added complexity. [[[COMMENTS?]]] 273 7.2. The Usenet Signature Convention 275 There is a convention in Usenet news of using "-- " as the separator 276 line between the body and the signature of a message. If such a 277 line is present in a Format=Flowed message, a receiving system may 278 erroneously flow the first line of the signature with the signature 279 separator line on display or in the creation of new messages. 281 This could be avoided by (a) treating "-- " as a special case, (b) 282 advising user agents which create Format=Flowed messages to put the 283 signature (and separator line) in an additional body part or use 284 either zero or two spaces in the signature separator, or (c) define 285 Format=Flowed lines to use two trailing space characters to indicate 286 a flowed line (or either two or three, to also deal with trailing 287 white space corruption). 289 As the "-- " convention is not widely used on receipt, it is not 290 considered worth extra complexity to avoid. [[[COMMENTS?]]] 292 8. Security Considerations 294 This parameter introduces no security considerations beyond those 295 which apply to text/plain. 297 9. Acknowledgments 299 This proposal evolved from a discussion of Chris Newman's 300 TEXT/PARAGRAPH draft, which took place on the IETF 822 mailing list. 302 10. References 304 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 305 Requirement Levels", RFC 2119, Harvard University, March 1997. 307 [RICH] Resnick, Walker, "The text/enriched MIME Content-type", RFC 308 1896, QUALCOMM, InterCon, February 1996. 310 [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail Extensions 311 (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, 312 November 1996. 314 Gellens [Page 6] Expires February 315 1998 317 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, Information 318 Sciences Institute, August 1982. 320 11. Editor's Address 322 Randall Gellens +1 619 651 5115 323 QUALCOMM Incorporated randy@qualcomm.com 324 6455 Lusk Blvd. 325 San Diego, CA 92121-2779 326 USA 328 12. Full Copyright Statement 330 Copyright (C) The Internet Society 1998. All Rights Reserved. 332 This document and translations of it may be copied and furnished to 333 others, and derivative works that comment on or otherwise explain it 334 or assist in its implementation may be prepared, copied, published 335 and distributed, in whole or in part, without restriction of any 336 kind, provided that the above copyright notice and this paragraph 337 are included on all such copies and derivative works. However, this 338 document itself may not be modified in any way, such as by removing 339 the copyright notice or references to the Internet Society or other 340 Internet organizations, except as needed for the purpose of 341 developing Internet standards in which case the procedures for 342 copyrights defined in the Internet Standards process must be 343 followed, or as required to translate it into languages other than 344 English. 346 The limited permissions granted above are perpetual and will not be 347 revoked by the Internet Society or its successors or assigns. 349 This document and the information contained herein is provided on an 350 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 351 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 352 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 353 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 354 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Gellens [Page 7] Expires February 1999