idnits 2.17.1 draft-gellens-format-bis-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of lines with control characters in the document. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. 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.) -- The document date (November 2003) is 7466 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 208, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. 'MSG-FMT') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. 'OpenPGP') (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: The Text/Plain Format Parameter R. Gellens 2 Document: draft-gellens-format-bis-04.txt Qualcomm 3 Expires: May 2004 November 2003 4 Updates: RFC 2046 5 Obsoletes: RFC 2646 7 The Text/Plain Format and DelSp Parameters 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 27 The list of Internet-Draft Shadow Directories can be accessed at 28 . 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 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This specification establishes two parameters (Format and DelSP) to 41 be used with the Text/Plain media type. In the presence of these 42 parameters, trailing whitespace is used to indicate flowed lines and 43 a canonical quote indicator is used to indicate quoted lines. This 44 results in an encoding which appears as normal Text/Plain in older 45 implementations, since it is in fact normal Text/Plain, yet provides 46 for superior wrapping/flowing, and quoting. 48 Gellens [Page 1] Expires May 2004 49 This standard supersedes the one specified in RFC 2646, "The 50 Text/Plain Format Parameter", and adds the DelSp parameter to 51 accommodate languages/coded character sets in which ASCII spaces are 52 not used or appear rarely. 54 Gellens [Page 2] Expires May 2004 55 Table of Contents 57 1. Comments on this Document . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in this Document . . . . . . . . . . . . . 3 59 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 5 63 4.3. New Media Types . . . . . . . . . . . . . . . . . . . . 6 64 5. The Format and DelSp Parameters . . . . . . . . . . . . . . 6 65 5.1. Interpreting Format=Flowed . . . . . . . . . . . . . . . 7 66 5.2. Generating Format=Flowed . . . . . . . . . . . . . . . 8 67 5.3. Usenet Signature Convention . . . . . . . . . . . . . . 10 68 5.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 10 69 5.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.6. Digital Signatures and Encryption . . . . . . . . . . . 13 71 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6. Interoperability . . . . . . . . . . . . . . . . . . . . . 14 73 7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 16 75 8.1. Trailing White Space Corruption . . . . . . . . . . . . 16 76 9. Security Considerations . . . . . . . . . . . . . . . . . . 16 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 78 11. Internationalization Considerations . . . . . . . . . . . . 17 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 80 13. Normative References . . . . . . . . . . . . . . . . . . . 17 81 14. Informative References . . . . . . . . . . . . . . . . . . . 18 82 15. Author's Address . . . . . . . . . . . . . . . . . . . . . 18 83 Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . 18 84 Intellectual Property Statement . . . . . . . . . . . . . . . 20 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 87 1. Comments on this Document 89 Private comments should be sent to the author. Public comments may 90 be sent to the IETF 822 mailing list, . To 91 subscribe, send a message to with the 92 word SUBSCRIBE as the body of the message. Archives for the list 93 are at . 95 2. Conventions Used in this Document 97 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 98 NOT", and "MAY" in this document are to be interpreted as described 99 in "Key words for use in RFCs to Indicate Requirement Levels" 100 [KEYWORDS]. 102 Gellens [Page 3] Expires May 2004 103 The term "paragraph" is used here to mean a series of lines which 104 are logically to be treated as a unit for display purposes and 105 eligible to be flowed (wrapped and joined) as appropriate to fit in 106 the display window and when creating text for replies, forwarding, 107 etc. 109 3. Introduction 111 Interoperability problems have been observed with erroneous 112 labelling of paragraph text as Text/Plain, and with various forms of 113 "embarrassing line wrap." (See section 4.) 115 Attempts to deploy new media types, such as Text/Enriched [Rich] and 116 Text/HTML [HTML] have suffered from a lack of backwards 117 compatibility and an often hostile user reaction at the receiving 118 end. 120 What is required is a format which is in all significant ways 121 Text/Plain, and therefore is quite suitable for display as 122 Text/Plain, and yet allows the sender to express to the receiver 123 which lines which lines are quoted and which lines are considered a 124 logical paragraph, and thus eligible to be flowed (wrapped and 125 joined) as appropriate. 127 4. The Problem 129 The Text/Plain media type is the lowest common denominator of 130 Internet email, with lines of no more than 998 characters (by 131 convention usually no more than 78), and where the carriage-return 132 and line-feed (CRLF) sequence represents a line break (see 133 [MIME-IMT] and [MSG-FMT]). 135 Text/Plain is usually displayed as preformatted text, often in a 136 fixed font. That is, the characters start at the left margin of the 137 display window, and advance to the right until a CRLF sequence is 138 seen, at which point a new line is started, again at the left 139 margin. When a line length exceeds the display window, some clients 140 will wrap the line, while others invoke a horizontal scroll bar. 142 Text which meets this description is defined by this memo as 143 "fixed". 145 Some interoperability problems have been observed with this format: 147 Gellens [Page 4] Expires May 2004 148 4.1. Paragraph Text 150 Many modern programs use a proportional-spaced font, and use CRLF to 151 represent paragraph breaks. Line breaks are "soft", occurring as 152 needed on display. That is, characters are grouped into a paragraph 153 until a CRLF sequence is seen, at which point a new paragraph is 154 started. Each paragraph is displayed, starting at the left margin 155 (or paragraph indent), and continuing to the right until a word is 156 encountered which does not fit in the remaining display width. This 157 word is displayed at the left margin of the next line. This 158 continues until the paragraph ends (a CRLF is seen). Extra vertical 159 space is left between paragraphs. 161 Text which meets this description is defined by this memo as 162 "flowed". 164 Numerous software products erroneously label this format as 165 Text/Plain, resulting in much user discomfort. 167 4.2. Embarrassing Line Wrap 169 As Text/Plain messages are quoted in replies or forwarded messages, 170 each line gradually increases in length, eventually being 171 arbitrarily hard wrapped, resulting in "embarrassing line wrap". 172 This produces text which is at best hard to read, and often confuses 173 attributions. 175 Example: 177 >>>>>>This is a comment from the first message to show a 178 >quoting example. 179 >>>>>This is a comment from the second message to show a 180 >quoting example. 181 >>>>This is a comment from the third message. 182 >>>This is a comment from the fourth message. 184 It can be confusing to assign attribution to lines 2 and 4 above. 186 In addition, as devices with display widths smaller than 79 or 80 187 characters become more popular, embarrassing line wrap has become 188 even more prevalent, even with unquoted text. 190 Example: 192 This is paragraph text that is 193 meant to be flowed across 194 several lines. 195 However, the sending mailer is 196 converting it to fixed text at 198 Gellens [Page 5] Expires May 2004 199 a width of 72 200 characters, which causes it to 201 look like this when shown on a 202 PDA with only 203 30 character lines. 205 4.3. New Media Types 207 Attempts to deploy new media types, such as Text/Enriched [Rich] and 208 Text/HTML [HTML] have suffered from a lack of backwards 209 compatibility and an often hostile user reaction at the receiving 210 end. 212 In particular, Text/Enriched requires that open angle brackets ("<") 213 and hard line breaks be doubled, with resulting user unhappiness 214 when viewed as Text/Plain. Text/HTML requires even more alteration 215 of text, with a corresponding increase in user complaints. 217 A proposal to define a new media type to explicitly represent the 218 paragraph form suffered from a lack of interoperability with 219 currently deployed software. Some programs treat unknown subtypes 220 of TEXT as an attachment. 222 What is desired is a format which is in all significant ways 223 Text/Plain, and therefore is quite suitable for display as 224 Text/Plain, and yet allows the sender to express to the receiver 225 which lines can be considered a logical paragraph, and thus flowed 226 (wrapped and joined) as appropriate. 228 5. The Format and DelSp Parameters 230 This specification defines two MIME parameters for use with 231 Text/Plain: 233 Name: Format 234 Value: Fixed, Flowed 236 Name: DelSp 237 Value: Yes, No 239 (Neither the parameter names nor values are case sensitive.) 241 If Format is not specified, or if the value is not recognized, a 242 value of Fixed is assumed. The semantics of the Fixed value are the 243 usual associated with Text/Plain [MIME-IMT]. 245 Gellens [Page 6] Expires May 2004 246 A Format value of Flowed indicates that the definition of flowed 247 text (as specified in this memo) was used on generation, and MAY be 248 used on reception. 250 Note that because Format is a parameter of the Text/Plain 251 content-type, any content-transfer-encoding used is irrelevant to 252 the processing of flowed text. 254 If DelSp is not specified, or if its value is not recognized, a 255 value of No is assumed. The use of DelSp without a Format value of 256 Flowed is undefined. When creating messages, DelSp SHOULD NOT be 257 specified in Text content types other than Text/Plain with Format = 258 Flowed. When receiving messages, DelSp SHOULD be ignored if used in 259 a Text content type other than Text/Plain with Format = Flowed. 261 This section discusses flowed text; section 7 provides a formal 262 definition. 264 Section 6 discusses interoperability. 266 Note that this memo describes an on-the-wire format. It does not 267 address formats for local file storage. 269 5.1. Interpreting Format=Flowed 271 If the first character of a line is a quote mark (">"), the line is 272 considered to be quoted (see section 5.5). Logically, all quote 273 marks are counted and deleted, resulting in a line with a non-zero 274 quote depth, and content. (The agent is of course free to display 275 the content with quote marks or excerpt bars or anything else.) 276 Logically, this test for quoted lines is done before any other tests 277 (that is, before checking for space-stuffed and flowed). 279 If the first character of a line is a space, the line has been 280 space-stuffed (see section 5.4). Logically, this leading space is 281 deleted before examining the line further (that is, before checking 282 for flowed). 284 If the line ends in a space, the line is flowed. Otherwise it is 285 fixed. The exception to this rule is a signature separator line, 286 described in Section 5.3. Such lines end in a space but are neither 287 flowed nor fixed. 289 If the line is flowed and DelSp is "yes", the trailing space 290 immediately prior to the line's CRLF is logically deleted. If the 291 DelSp parameter is "no" (or not specified, or set to an unrecognized 292 value), the trailing space is not deleted. 294 Gellens [Page 7] Expires May 2004 295 Any remaining trailing spaces are part of the line's content, but 296 the CRLF of a soft line break is not. 298 A series of one or more flowed lines followed by one fixed line is 299 considered a paragraph, and MAY be flowed (wrapped and unwrapped) as 300 appropriate on display and in the construction of new messages (see 301 section 5.5). 303 An interpreting agent SHOULD allow for three exceptions to the rule 304 that paragraphs end with a fixed line. These exceptions are 305 improperly constructed messages: a flowed line SHOULD be considered 306 to end the paragraph if it is followed by a line of a different 307 quote depth (see 5.5) or by a signature separator (see 5.3); the end 308 of the body also ends the paragraph. 310 A line consisting of one or more spaces (after deleting a space 311 acting as stuffing) is considered a flowed line. 313 An empty line (just a CRLF) is a fixed line. 315 Note that, for Unicode text, [Annex-14] provides guidance choosing 316 at which characters to wrap a line. 318 5.2. Generating Format=Flowed 320 When generating Format=Flowed text, lines SHOULD be 78 characters or 321 shorter, including any trailing white space and also including any 322 space added as part of stuffing (see section 5.4). As suggested 323 values, any paragraph longer than 78 characters in total length 324 could be wrapped using lines of 72 or fewer characters. While the 325 specific line length used is a matter of aesthetics and preference, 326 longer lines are more likely to require rewrapping and to encounter 327 difficulties with older mailers. (It has been suggested that 66 328 character lines are the most readable.) 330 The restriction to 78 or fewer characters between CRLFs on the wire 331 is to conform to [MSG-FMT]. 333 (In addition to conformance to [MSG-FMT], there is a historical need 334 that all lines, even when displayed by a non-flowed-aware program, 335 will fit in a standard 79- or 80-column screen without having to be 336 wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit 337 on a line, the last column is often reserved for a line-wrap 338 indicator.) 340 Gellens [Page 8] Expires May 2004 341 When creating flowed text, the generating agent wraps, that is, 342 inserts 'soft' line breaks as needed. Soft line breaks are added at 343 natural wrapping points, such as between words. A soft line break 344 is a SP CRLF sequence. 346 There are two techniques for inserting soft line breaks. The older 347 technique, established by RFC 2646, created a soft line break by 348 inserting a CRLF after the occurrence of a space. With this 349 technique, soft line breaks are only possible where spaces already 350 occur. When this technique is used, the DelSp parameter SHOULD be 351 used; if used it MUST be set to "no". 353 The newer technique, suitable for use even with languages/coded 354 character sets in which the ASCII space character is rare or not 355 used, creates a soft line break by inserting a SP CRLF sequence. 356 When this technique is used, the DelSp parameter MUST be used and 357 MUST be set to "yes". Note that because of space-stuffing (see 358 section 5.4), when this technique is used and a soft line break is 359 inserted at a point where a SP already exists (such as between 360 words), if the SP CRLF sequence is added immediately before the SP, 361 the pre-existing SP becomes leading and thus requires stuffing. It 362 is RECOMMENDED that agents avoid this by inserting the SP CRLF 363 sequence following the existing SP. 365 Generating agents MAY use either method within each Text/Plain body 366 part. 368 Regardless of which technique is used, a generating agent SHOULD NOT 369 insert a space in an unnatural location, such as into a word (a 370 sequence of printable characters, not containing spaces, in a 371 language/coded character set in which spaces are common). If faced 372 with such a word which exceeds 78 characters (but less than 998 373 characters, the [SMTP] limit on line length), the agent SHOULD send 374 the word as is and exceed the 78-character limit on line length. 376 A generating agent SHOULD: 377 o Ensure all lines (fixed and flowed) are 78 characters or fewer 378 in length, counting any trailing space as well as a space added 379 as stuffing, but not counting the CRLF, unless a word by itself 380 exceeds 78 characters. 381 o Trim spaces before user-inserted hard line breaks. 383 A generating agent MUST: 384 o Space-stuff lines which start with a space, "From ", or ">". 386 In order to create messages which do not require space-stuffing, and 387 are thus more aesthetically pleasing when viewed as Format=Fixed, a 388 generating agent MAY avoid wrapping immediately before ">", "From ", 389 or space. 391 Gellens [Page 9] Expires May 2004 392 (See sections 5.4 and 5.5 for more information on space-stuffing and 393 quoting, respectively.) 395 A Format=Flowed message consists of zero or more paragraphs, each 396 containing one or more flowed lines followed by one fixed line. The 397 usual case is a series of flowed text lines with blank (empty) fixed 398 lines between them. 400 Any number of fixed lines can appear between paragraphs. 402 When placing soft line breaks in a paragraph, generating agents MUST 403 NOT place them in a way that causes any line of the paragraph to be 404 a signature separator line, because paragraphs cannot contain 405 signature separator lines (see Sections 5.3 and 7). 407 [Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed 408 unless absolutely necessary (for example, non-US-ASCII (8-bit) 409 characters over a strictly 7-bit transport such as unextended 410 [SMTP]). In particular, a message SHOULD NOT be encoded in 411 Quoted-Printable for the sole purpose of protecting the trailing 412 space on flowed lines unless the body part is cryptographically 413 signed or encrypted (see Section 5.6). 415 The intent of Format=Flowed is to allow user agents to generate 416 flowed text which is non-obnoxious when viewed as pure, raw 417 Text/Plain (without any decoding); use of Quoted-Printable hinders 418 this and may cause Format=Flowed to be rejected by end users. 420 5.3. Usenet Signature Convention 422 There is a long-standing convention in Usenet news which also 423 commonly appears in Internet mail of using "-- " as the separator 424 line between the body and the signature of a message. When 425 generating a Format=Flowed message containing a Usenet-style 426 separator before the signature, the separator line is sent as-is. 427 This is a special case; an (optionally quoted or quoted and stuffed) 428 line consisting of DASH DASH SP is neither fixed nor flowed. 430 Generating agents MUST NOT end a paragraph with such a signature 431 line. 433 A receiving agent needs to test for a signature line both before the 434 test for a quoted line (see Section 5.5) and also after logically 435 counting and deleting quote marks and stuffing (see Section 5.4) 436 from a quoted line. 438 Gellens [Page 10] Expires May 2004 439 5.4. Space-Stuffing 441 In order to allow for unquoted lines which start with ">", and to 442 protect against systems which "From-munge" in-transit messages 443 (modifying any line which starts with "From " to ">From "), 444 Format=Flowed provides for space-stuffing. 446 Space-stuffing adds a single space to the start of any line which 447 needs protection when the message is generated. On reception, if 448 the first character of a line is a space, it is logically deleted. 449 This occurs after the test for a quoted line (which logically counts 450 and deletes any quote marks), and before the test for a flowed line. 452 On generation, any unquoted lines which start with ">", and any 453 lines which start with a space or "From " MUST be space-stuffed. 454 Other lines MAY be space-stuffed as desired. 456 (Note that space-stuffing is conceptually similar to dot-stuffing as 457 specified in [SMTP].) 459 5.5. Quoting 461 In Format=Flowed, the canonical quote indicator (or quote mark) is 462 one or more close angle bracket (">") characters. Lines which start 463 with the quote indicator are considered quoted. The number of ">" 464 characters at the start of the line specifies the quote depth. 465 Flowed lines which are also quoted may require special handling on 466 display and when copied to new messages. 468 When creating quoted flowed lines, each such line starts with the 469 quote indicator. 471 Note that because of space-stuffing, the lines 472 >> Exit, Stage Left 473 and 474 >>Exit, Stage Left 475 are semantically identical; both have a quote-depth of two, and a 476 content of "Exit, Stage Left". 478 However, the line 479 > > Exit, Stage Left 480 is different. It has a quote-depth of one, and a content of 481 "> Exit, Stage Left". 483 When generating quoted flowed lines, an agent needs to pay attention 484 to changes in quote depth. All lines of a paragraph MUST be 485 unquoted, or else they MUST all be quoted and have the same quote 486 depth. Therefore, whenever there is a change in quote depth, or a 487 change from quoted to unquoted, or change from unquoted to quoted, 489 Gellens [Page 11] Expires May 2004 490 the line immediately preceeding the change MUST NOT be a flowed 491 line. 493 If a receiving agent wishes to reformat flowed quoted lines (joining 494 and/or wrapping them) on display or when generating new messages, 495 the lines SHOULD be de-quoted, reformatted, and then re-quoted. To 496 de-quote, the number of close angle brackets in the quote indicator 497 at the start of each line is counted. To re-quote after 498 reformatting, a quote indicator containing the same number of close 499 angle brackets originally present are prefixed to each line. 501 On reception, if a change in quote depth occurs on a flowed line, 502 this is an improperly formatted message. The receiver SHOULD handle 503 this error by using the 'quote-depth-wins' rule, which is to 504 consider the paragraph to end with the flowed line immediately 505 preceeding the change in quote depth. 507 In other words, whenever two adjacent lines have different quote 508 depths, senders MUST ensure that the earlier line is not flowed 509 (does not end in a space), and receivers finding a flowed line there 510 SHOULD treat it as the last line of a paragraph. 512 For example, consider the following sequence of lines (using '*' to 513 indicate a soft line break, i.e., SP CRLF, and '#' to indicate a 514 hard line break, i.e., CRLF): 516 > Thou villainous ill-breeding spongy dizzy-eyed* 517 > reeky elf-skinned pigeon-egg!* <--- problem ---< 518 >> Thou artless swag-bellied milk-livered* 519 >> dismal-dreaming idle-headed scut!# 520 >>> Thou errant folly-fallen spleeny reeling-ripe* 521 >>> unmuzzled ratsbane!# 522 >>>> Henceforth, the coding style is to be strictly* 523 >>>> enforced, including the use of only upper case.# 524 >>>>> I've noticed a lack of adherence to the coding* 525 >>>>> styles, of late.# 526 >>>>>> Any complaints?# 528 The second line ends in a soft line break, even though it is the 529 last line of the one-deep quote block. The question then arises as 530 to how this line is to be interpreted, considering that the next 531 line is the first line of the two-deep quote block. 533 The example text above, when processed according to quote-depth 534 wins, results in the first two lines being considered as one quoted, 535 flowed section, with a quote depth of 1; the third and fourth lines 536 become a quoted, flowed section, with a quote depth of 2. 538 Gellens [Page 12] Expires May 2004 539 A generating agent MUST NOT create this situation; a receiving agent 540 SHOULD handle it by giving preference to the quote depth. 542 5.6. Digital Signatures and Encryption 544 If a message is digitally signed or encrypted it is important that 545 cryptographic processing use the same text for signature 546 verification and/or decryption as was used for signature generation 547 and/or encryption. Since the use of format=flowed allows text to be 548 altered (by adding or removing line breaks and trailing spaces) 549 between composition and transmission, and between reception and 550 display, interoperability problems or security vulnerabilities may 551 arise if originator and recipient do not both use the on-the-wire 552 format for cryptographic processing. 554 The implications of the interaction between format=flowed and any 555 specific cryptographic process depend on the details of the 556 cryptographic processing and should be understood before using 557 format=flowed in conjunction with signed and/or encrypted messages. 559 Note that [OpenPGP] specifies (in section 7.1) that "any trailing 560 whitespace (spaces, and tabs, 0x09) at the end of any line is 561 ignored when the cleartext signature is calculated." 563 Thus it would be possible to add, in transit, a format=flowed header 564 to a regular, format=fixed vanilla PGP (not [OpenPGP-MIME]) signed 565 message and add arbitrary trailing space characters without this 566 addition being detected. This would change the rendering of the 567 article by a client which supported format=flowed. 569 Therefore, the use of [OpenPGP] with format=flowed messages is 570 strongly discouraged. [OpenPGP-MIME] is recommended instead. 572 5.7. Examples 574 The following example contains three paragraphs: 576 `Take some more tea,' the March Hare said to Alice, very 577 earnestly. 579 `I've had nothing yet,' Alice replied in an offended tone, `so I 580 can't take more.' 582 `You mean you can't take LESS,' said the Hatter: `it's very easy 583 to take MORE than nothing.' 585 Gellens [Page 13] Expires May 2004 586 This could be encoded as follows (using '*' to indicate a soft line 587 break, that is, SP CRLF sequence, and '#' to indicate a hard line 588 break, that is, CRLF): 590 `Take some more tea,' the March Hare said to Alice, very* 591 earnestly.# 592 # 593 `I've had nothing yet,' Alice replied in an offended tone, `so* 594 I can't take more.'# 595 # 596 `You mean you can't take LESS,' said the Hatter: `it's very* 597 easy to take MORE than nothing.'# 599 To show an example of quoting, here we have the same exchange, 600 presented as a series of direct quotes: 602 >>>Take some more tea.# 603 >>I've had nothing yet, so I can't take more.# 604 >You mean you can't take LESS, it's very easy to take* 605 >MORE than nothing.# 607 6. Interoperability 609 Because flowed lines are all-but-indistinguishable from fixed lines, 610 software which does not recognize Format=Flowed treats flowed lines 611 as normal Text/Plain (which is what they are). Thus, Format=Flowed 612 interoperates with older clients, although flowed lines will have 613 trailing white space inserted. 615 If a space-stuffed message is received by an agent which handles 616 Format=Flowed, the space-stuffing is reversed and thus the message 617 appears unchanged. An agent which is not aware of Format=Flowed 618 will of course not undo any space-stuffing; thus Format=Flowed 619 messages may appear with a leading space on some lines (those which 620 start with a space, ">" which is not a quote indicator, or "From "). 621 Since lines which require space-stuffing rarely occur, and the 622 aesthetic consequences of unreversed space-stuffing are minimal, 623 this is not expected to be a significant problem. 625 If some lines begin with one or more spaces, the generating agent 626 MAY space-stuff all lines, to maintain the relative indentation of 627 the lines when viewed by clients which are not aware of 628 Format=Flowed. 630 Messages generated with DelSp=yes and received by clients which are 631 aware of Format=Flowed but are not aware of the DelSp parameter will 632 have an extra space remaining after removal of soft line breaks. 633 Thus, when generating text in languages/coded character sets in 635 Gellens [Page 14] Expires May 2004 636 which spaces are common, the generating agent MAY always use the 637 DelSp=no method. 639 Hand-aligned text, such as ASCII tables or art, source code, etc., 640 SHOULD be sent as fixed, not flowed lines. 642 7. ABNF 644 The constructs used in Text/Plain; Format=Flowed body parts are 645 described using Augmented Backus-Naur Form [ABNF], including the 646 core rules defined in Appendix A. 648 Note that the SP (space) and ">" characters are encoded according to 649 the charset parameter. 651 flowed-body = * ( paragraph / fixed-line / sig-sep ) 652 paragraph = ( 1*flowed-line ) fixed-line 653 ; all lines in paragraph MUST be unquoted or 654 ; have same quote depth 655 flowed-line = ( flowed-line-qt / flowed-line-unqt ) flow CRLF 656 flowed-line-qt = quote ( ( stuffing stuffed-flowed ) / 657 unstuffed-flowed ) 658 flowed-line-unqt = ( stuffing stuffed-flowed ) / unstuffed-flowed 659 stuffed-flowed = *text-char 660 unstuffed-flowed = non-sp-quote *text-char 661 fixed-line = fixed-line-qt / fixed-line-unqt 662 fixed-line-qt = quote ( ( stuffing stuffed-fixed ) / 663 unstuffed-fixed ) CRLF 664 fixed-line-unqt = ( stuffed-fixed / unstuffed-fixed ) CRLF 665 stuffed-fixed = *text-char non-sp 666 unstuffed-fixed = non-sp-quote [ *text-char non-sp ] 667 sig-sep = [ quote [stuffing] ] "--" SP CRLF 668 quote = 1*">" 669 stuffing = SP ; space-stuffed, added on generation if 670 ; needed, deleted on reception 671 flow = SP ; space before CRLF indicates flowed line, 672 ; if DelSp=yes, space was added on generation 673 ; and is deleted on reception 674 non-sp-quote = < any character except NUL, CR, LF, SP, ">" > 675 non-sp = non-sp-quote / ">" 676 text-char = non-sp / SP 678 That is, a Format=Flowed message body consists of any number of 679 paragraphs and/or fixed lines and/or signature separator lines; 680 paragraphs need at least one flowed line and are terminated by a 681 fixed line; the fixed line terminating the paragraph is part of the 682 paragraph. (There are some exceptions to this described in the 683 text.) 685 Gellens [Page 15] Expires May 2004 686 Without at least one flowed line, there is a series of fixed lines, 687 each independent. There is no paragraph. 689 With at least one flowed line, there is a paragraph, and the 690 received lines can be reformed and flowed to fit the display window 691 size. This can only be done if the lines are part of a logical 692 grouping, the paragraph. 694 Note that the definitions of flowed-line and sig-sep are potentially 695 ambiguous: a signature separator line matches both, but is treated 696 as a signature separator line and not a flowed line. 698 8. Failure Modes 700 8.1. Trailing White Space Corruption 702 There are systems in existence which alter trailing whitespace on 703 messages which pass through them. Such systems may strip, or in 704 rarer cases, add trailing whitespace, in violation of RFC 2821 705 [SMTP] section 4.5.2. 707 Stripping trailing whitespace has the effect of converting flowed 708 lines to fixed lines, which results in a message no worse than if 709 Format=Flowed had not been used. 711 Adding trailing whitespace to a Format=Flowed message may result in 712 a malformed display or reply. 714 Since most systems which add trailing white space do so to create a 715 line which fills an internal record format, the result is almost 716 always a line which contains an even number of characters (counting 717 the added trailing white space). 719 One possible avoidance, therefore, would be to define Format=Flowed 720 lines to use either one or two trailing space characters to indicate 721 a flowed line, such that the total line length is odd. However, 722 considering the scarcity of such systems today, it is not worth the 723 added complexity. 725 9. Security Considerations 727 Any security considerations which apply to Text/Plain also apply to 728 Text/Plain with Format=Flowed. 730 Gellens [Page 16] Expires May 2004 731 Section 5.6 discusses the interaction between Format=Flowed and 732 digital signatures or encryption. 734 10. IANA Considerations 736 IANA is requested to add a reference to this specification in the 737 Text/Plain Media Type registration. 739 11. Internationalization Considerations 741 The line wrap and quoting specifications of Format=Flowed may not be 742 suitable for certain charsets, such as for Arabic and Hebrew 743 characters that read from right to left. Care needs to be taken in 744 applying format=flowed in these cases, as format=fixed combined with 745 [quoted-printable] encoding may be more suitable. 747 The DelSp parameter was added specifically to permit Format=Flowed 748 to be used with languages/coded character sets in which the ASCII 749 space character is rarely used, or not used at all. 751 12. Acknowledgments 753 The DelSp parameter was developed during a series of discussions 754 among a number of people, including Harald Alvestrand, Grant 755 Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned 756 Freed, Alexey Melnikov, John Myers, and Pete Resnick. 758 Corrections and clarifications to RFC 2646 and early versions of 759 this draft were pointed out by several people, including Adam 760 Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, 761 Ragho Mahalingam, Keith Moore, Greg Troxel, and Dan Wing. 763 I'm told that NeXT's mail application used a very similar mechanism 764 (without support for non-Western languages) in 1992. 766 13. Normative References 768 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 769 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 770 November 1997. 772 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 773 Requirement Levels", RFC 2119, Harvard University, March 1997. 775 Gellens [Page 17] Expires May 2004 777 [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail Extensions 778 (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, 779 November 1996. 781 [Quoted-Printable] Freed, Borenstein, "Multipurpose Internet Mail 782 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 783 2045, Innosoft, First Virtual, November 1996. 785 14. Informative References 787 [Annex-14] Unicode Standard Annex #14, "Line Breaking Properties" 788 790 [MSG-FMT] Resnick, "Internet Message Format", RFC 2822, Qualcomm, 791 April 2001. 793 [OpenPGP] Callas, Donnerhacke, Finney, Thayer, "OpenPGP Message 794 Format", RFC 2440, Network Associates, IN-Root-CA Individual Network 795 e.V., EIS Corporation, November 1998. 797 [OpenPGP-MIME] Elkins, "MIME Security with Pretty Good Privacy 798 (PGP)", RFC 2015, October 1996; also "MIME Security with OpenPGP", 799 Elkins, Del Torto, Levien, Roessler, RFC 3156, August 2001 801 [Rich] Resnick, Walker, "The text/enriched MIME Content-type", RFC 802 1896, QUALCOMM, InterCon, February 1996. 804 [SMTP] Klensin, "Simple Mail Transfer Protocol", RFC 2821, AT&T 805 Laboratories, April 2001. 807 15. Author's Address 809 Randall Gellens +1 858 651 5115 810 QUALCOMM Incorporated randy@qualcomm.com 811 5775 Morehouse Drive 812 San Diego, CA 92121 813 USA 815 Appendix A: Changes from RFC 2646 817 Substantive: 818 o Added DelSp parameter to handle languages and coded character 819 sets in which space is less common or not used. 820 o Updated text on generating and interpreting to accommodate the 821 DelSp parameter. 822 o Changed the limits of 79 or 80 to be 78 in conformance with RFC 823 2822. 825 Gellens [Page 18] Expires May 2004 826 o Added text on generating to clarify that the 78-character limit 827 includes trailing white space and stuffing. 828 o Changed sig-sep in ABNF to allow stuffing. 829 o Changed fixed-line to allow empty lines in ABNF. 830 o Added explanatory text following ABNF. 831 o Moved text from Abstract to new Introduction; rewrote Abstract. 832 o Moved interoperability text to new section, and updated. 833 o Clarified Security Considerations. 834 o Text on digital signatures now discusses that OpenPGP ignores 835 trailing white space. 836 o Mention Unicode Annex 14. 837 o Added mention of quoting to Abstract and Introduction. 838 o Deleted line analysis table. 839 o Added recommendations for OpenPGP and OpenPGP-MIME. 840 o Rewrote ABNF rules to remove most ambiguity and note remaining 841 case. 842 o Added note that c-t-e is irrelevant to flowed text processing. 843 o Added text indicating that end of data terminates a paragraph. 844 o Moved sig-sep out of fixed-line ABNF. 845 o Changed some SHOULDs to MUSTs (space-stuffing, quoted 846 paragraphs). 847 o Added note to ABNF that space and ">" are encoded according to 848 charset. 849 o Mentioned exceptions in section on interpreting. 850 o Clarified and made consistent treatment of signature separator 851 lines. 853 Editorial: 854 o Added mention of NeXT's mail application to Acknowledgments. 855 o Updated Acknowledgments. 856 o Updated [SMTP] reference to 2821. 857 o Added Notices. 858 o Split References into Normative and Informative. 859 o Improved text wording in some areas. 860 o Standardize on "quote depth", not "quoting depth". 861 o Moved section on interpreting before section on generating. 862 o Reworded non-normative "should"s. 863 o Noted meaning of "paragraph". 865 The DelSp parameter was added specifically to permit Format=Flowed 866 to be used with languages/coded character sets in which the ASCII 867 space character is rarely used, or not used at all. The DelSp 868 mechanism was selected despite having been initially rejected as too 869 much of a kludge, because among the many different techniques 870 proposed, it allows for maximum interoperability among clients which 871 support neither this specification nor RFC 2646, those which do 872 support RFC 2646 but not this specification, and those that do 873 support this specification; this set is multiplied by those that 874 handle languages/coded character sets in which spaces are common, 876 Gellens [Page 19] Expires May 2004 877 and in which they are uncommon or not used. 879 Intellectual Property Statement 881 The IETF takes no position regarding the validity or scope of any 882 intellectual property or other rights that might be claimed to 883 pertain to the implementation or use of the technology described in 884 this document or the extent to which any license under such rights 885 might or might not be available; neither does it represent that it 886 has made any effort to identify any such rights. Information on the 887 IETF's procedures with respect to rights in standards-track and 888 standards-related documentation can be found in BCP-11. Copies of 889 claims of rights made available for publication and any assurances 890 of licenses to be made available, or the result of an attempt made 891 to obtain a general license or permission for the use of such 892 proprietary rights by implementors or users of this specification 893 can be obtained from the IETF Secretariat. 895 The IETF invites any interested party to bring to its attention any 896 copyrights, patents or patent applications, or other proprietary 897 rights which may cover technology that may be required to practice 898 this standard. Please address the information to the IETF Executive 899 Director. 901 Full Copyright Statement 903 Copyright (C) The Internet Society 2003. All Rights Reserved. 905 This document and translations of it may be copied and furnished to 906 others, and derivative works that comment on or otherwise explain it 907 or assist in its implementation may be prepared, copied, published 908 and distributed, in whole or in part, without restriction of any 909 kind, provided that the above copyright notice and this paragraph 910 are included on all such copies and derivative works. However, this 911 document itself may not be modified in any way, such as by removing 912 the copyright notice or references to the Internet Society or other 913 Internet organizations, except as needed for the purpose of 914 developing Internet standards in which case the procedures for 915 copyrights defined in the Internet Standards process must be 916 followed, or as required to translate it into languages other than 917 English. 919 The limited permissions granted above are perpetual and will not be 920 revoked by the Internet Society or its successors or assigns. 922 Gellens [Page 20] Expires May 2004 923 This document and the information contained herein is provided on an 924 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 925 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 926 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 927 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 928 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 930 Gellens [Page 21] Expires May 2004