idnits 2.17.1 draft-gellens-format-06.txt: ** The Abstract section seems to be numbered 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 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 35 instances of lines with control characters in the document. ** The abstract seems to contain references ([HTML], [RICH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 (7 May 1999) is 9118 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 180, but not defined == Missing Reference: 'SP' is mentioned on line 513, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 1896 (ref. 'RICH') ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 3 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, Editor 2 Document: draft-gellens-format-06.txt Qualcomm 3 Expires: 7 November 1999 7 May 1999 4 Updates: RFC 2046 6 The Text/Plain Format Parameter 8 Status of this Memo: 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 A version of this draft document is intended for submission to the 30 RFC editor as a Proposed Standard for the Internet Community. 31 Discussion and suggestions for improvement are requested. 33 Comments: 35 Private comments should be sent to the author. Public comments may 36 be sent to the IETF 822 mailing list, . To 37 subscribe, send a message to with the 38 word SUBSCRIBE as the body of the message. Archives for the list 39 are at . 41 Copyright Notice 43 Copyright (C) The Internet Society 1999. All Rights Reserved. 45 Table of Contents 47 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Conventions Used in this Document . . . . . . . . . . . . . 3 49 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3 51 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3 52 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4 53 4. The Format Parameter to the Text/Plain Media Type . . . . . 5 54 4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5 55 4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6 56 4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7 57 4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7 58 4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.6. Digital Signatures and Encryption . . . . . . . . . . . 9 60 4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 9 61 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11 64 6.1. Trailing White Space Corruption . . . . . . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . 11 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 67 9. Internationalization Considerations . . . . . . . . . . . . 11 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 12 71 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 73 1. Abstract 75 Interoperability problems have been observed with erroneous 76 labelling of paragraph text as Text/Plain, and with various forms of 77 "embarrassing line wrap." (See section 3.) 79 Attempts to deploy new media types, such as Text/Enriched [RICH] and 80 Text/HTML [HTML] have suffered from a lack of backwards 81 compatibility and an often hostile user reaction at the receiving 82 end. 84 What is required is a format which is in all significant ways 85 Text/Plain, and therefore is quite suitable for display as 86 Text/Plain, and yet allows the sender to express to the receiver 87 which lines can be considered a logical paragraph, and thus flowed 88 (wrapped and joined) as appropriate. 90 This memo proposes a new parameter to be used with Text/Plain, and, 91 in the presence of this parameter, the use of trailing whitespace to 92 indicate flowed lines. This results in an encoding which appears as 93 normal Text/Plain in older implementations, since it is in fact 94 normal Text/Plain. 96 2. Conventions Used in this Document 98 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 99 NOT", and "MAY" in this document are to be interpreted as described 100 in "Key words for use in RFCs to Indicate Requirement Levels" 101 [KEYWORDS]. 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 997 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 Text which meets this description is defined by this memo as 118 "fixed". 120 Some interoperability problems have been observed with this media 121 type: 123 3.1. Paragraph Text 125 Many modern programs use a proportional-spaced font and CRLF to 126 represent paragraph breaks. Line breaks are "soft", occurring as 127 needed on display. That is, characters are grouped into a paragraph 128 until a CRLF sequence is seen, at which point a new paragraph is 129 started. Each paragraph is displayed, starting at the left margin 130 (or paragraph indent), and continuing to the right until a word is 131 encountered which does not fit in the remaining display width. This 132 word is displayed at the left margin of the next line. This 133 continues until the paragraph ends (a CRLF is seen). Extra vertical 134 space is left between paragraphs. 136 Text which meets this description is defined by this memo as 137 "flowed". 139 Numerous software products erroneously label this media type as 140 Text/Plain, resulting in much user discomfort. 142 3.2. Embarrassing Line Wrap 144 As Text/Plain messages get quoted in replies or forwarded messages, 145 the length of each line gradually increases, resulting in 146 "embarrassing line wrap." This results in text which is at best hard 147 to read, and often confuses attributions. 149 Example: 151 >>>>>>This is a comment from the first message to show a 152 >quoting example. 153 >>>>>This is a comment from the second message to show a 154 >quoting example. 155 >>>>This is a comment from the third message. 156 >>>This is a comment from the fourth message. 158 It can be confusing to assign attribution to lines 2 and 4 above. 160 In addition, as devices with display widths smaller than 80 161 characters become more popular, embarrassing line wrap has become 162 even more prevalent, even with unquoted text. 164 Example: 166 This is paragraph text that is 167 meant to be flowed across 168 several lines. 169 However, the sending mailer is 170 converting it to fixed text at 171 a width of 72 172 characters, which causes it to 173 look like this when shown on a 174 PDA with only 175 30 character lines. 177 3.3. New Media Types 179 Attempts to deploy new media types, such as Text/Enriched [RICH] and 180 Text/HTML [HTML] have suffered from a lack of backwards 181 compatibility and an often hostile user reaction at the receiving 182 end. 184 In particular, Text/Enriched requires that open angle brackets ("<") 185 and hard line breaks be doubled, with resulting user unhappiness 186 when viewed as Text/Plain. Text/HTML requires even more alteration 187 of text, with a corresponding increase in user complaints. 189 A proposal to define a new media type to explicitly represent the 190 paragraph form suffered from a lack of interoperability with 191 currently deployed software. Some programs treat unknown subtypes 192 of TEXT as an attachment. 194 What is desired is a format which is in all significant ways 195 Text/Plain, and therefore is quite suitable for display as 196 Text/Plain, and yet allows the sender to express to the receiver 197 which lines can be considered a logical paragraph, and thus flowed 198 (wrapped and joined) as appropriate. 200 4. The Format Parameter to the Text/Plain Media Type 202 This document defines a new MIME parameter for use with Text/Plain: 204 Name: Format 205 Value: Fixed, Flowed 207 (Neither the parameter name nor its value are case sensitive.) 209 If not specified, a value of Fixed is assumed. The semantics of the 210 Fixed value are the usual associated with Text/Plain [MIME-IMT]. 212 A value of Flowed indicates that the definition of flowed text (as 213 specified in this memo) was used on generation, and MAY be used on 214 reception. 216 This section discusses flowed text; section 5 provides a formal 217 definition. 219 Because flowed lines are all-but-indistinguishable from fixed lines, 220 currently deployed software treats flowed lines as normal Text/Plain 221 (which is what they are). Thus, no interoperability problems are 222 expected. 224 Note that this memo describes an on-the-wire format. It does not 225 address formats for local file storage. 227 4.1. Generating Format=Flowed 229 When generating Format=Flowed text, lines SHOULD be shorter than 80 230 characters. As suggested values, any paragraph longer than 79 231 characters in total length could be wrapped using lines of 72 or 232 fewer characters. While the specific line length used is a matter 233 of aesthetics and preference, longer lines are more likely to 234 require rewrapping and to encounter difficulties with older mailers. 235 It has been suggested that 66 character lines are the most readable. 237 (The reason for the restriction to 79 or fewer characters between 238 CRLFs on the wire is to ensure that all lines, even when displayed 239 by a non-flowed-aware program, will fit in a standard 80-column 240 screen without having to be wrapped. The limit is 79, not 80, 241 because while 80 fit on a line, the last column is often reserved 242 for a line-wrap indicator.) 244 When creating flowed text, the generating agent wraps, that is, 245 inserts 'soft' line breaks as needed. Soft line breaks are added 246 between words. Because a soft line break is a SP CRLF sequence, the 247 generating agent creates one by inserting a CRLF after the occurance 248 of a space. 250 A generating agent SHOULD NOT insert white space into a word (a 251 sequence of printable characters not containing spaces). If faced 252 with a word which exceeds 79 characters (but less than 998 253 characters, the SMTP limit on line length), the agent SHOULD send 254 the word as is and exceed the 79-character limit on line length. 256 A generating agent SHOULD: 257 1. Ensure all lines (fixed and flowed) are 79 characters or 258 less in length, counting the trailing space but not 259 counting the CRLF, unless a word by itself exceeds 79 260 characters. 261 2. Trim spaces before user-inserted hard line breaks. 262 3. Space-stuff lines which start with a space, "From ", or 263 ">". 265 In order to create messages which do not require space-stuffing, and 266 are thus more aesthetically pleasing when viewed as Format=Fixed, a 267 generating agent MAY avoid wrapping immediately before ">", "From ", 268 or space. 270 (See sections 4.4 and 4.5 for more information on space-stuffing and 271 quoting, respectively.) 273 A Format=Flowed message consists of zero or more paragraphs, each 274 containing one or more flowed lines followed by one fixed line. The 275 usual case is a series of flowed text lines with blank (empty) fixed 276 lines between them. 278 Any number of fixed lines can appear between paragraphs. 280 [Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed 281 unless absolutely necessary (for example, non-US-ASCII (8-bit) 282 characters over a strictly 7-bit transport such as unextended SMTP). 283 In particular, a message SHOULD NOT be encoded in Quoted-Printable 284 for the sole purpose of protecting the trailing space on flowed 285 lines unless the body part is cryptographically signed or encrypted 286 (see Section 4.6). 288 The intent of Format=Flowed is to allow user agents to generate 289 flowed text which is non-obnoxious when viewed as pure, raw 290 Text/Plain (without any decoding); use of Quoted-Printable hinders 291 this and may cause Format=Flowed to be rejected by end users. 293 4.2. Interpreting Format=Flowed 295 If the first character of a line is a quote mark (">"), the line is 296 considered to be quoted (see section 4.5). Logically, all quote 297 marks are counted and deleted, resulting in a line with a non-zero 298 quote depth, and content. (The agent is of course free to display 299 the content with quote marks or excerpt bars or anything else.) 300 Logically, this test for quoted lines is done before any other tests 301 (that is, before checking for space-stuffed and flowed). 303 If the first character of a line is a space, the line has been 304 space-stuffed (see section 4.4). Logically, this leading space is 305 deleted before examining the line further (that is, before checking 306 for flowed). 308 If the line ends in one or more spaces, the line is flowed. 309 Otherwise it is fixed. Trailing spaces are part of the line's 310 content, but the CRLF of a soft line break is not. 312 A series of one or more flowed lines followed by one fixed line is 313 considered a paragraph, and MAY be flowed (wrapped and unwrapped) as 314 appropriate on display and in the construction of new messages (see 315 section 4.5). 317 A line consisting of one or more spaces (after deleting a stuffed 318 space) is considered a flowed line. 320 4.3. Usenet Signature Convention 322 There is a convention in Usenet news of using "-- " as the separator 323 line between the body and the signature of a message. When 324 generating a Format=Flowed message containing a Usenet-style 325 separator before the signature, the separator line is sent as-is. 326 This is a special case; an (optionally quoted) line consisting of 327 DASH DASH SP is not considered flowed. 329 4.4. Space-Stuffing 331 In order to allow for unquoted lines which start with ">", and to 332 protect against systems which "From-munge" in-transit messages 333 (modifying any line which starts with "From " to ">From "), 334 Format=Flowed provides for space-stuffing. 336 Space-stuffing adds a single space to the start of any line which 337 needs protection when the message is generated. On reception, if 338 the first character of a line is a space, it is logically deleted. 339 This occurs after the test for a quoted line, and before the test 340 for a flowed line. 342 On generation, any unquoted lines which start with ">", and any 343 lines which start with a space or "From " SHOULD be space-stuffed. 344 Other lines MAY be space-stuffed as desired. 346 (Note that space-stuffing is similar to dot-stuffing as specified in 347 [SMTP].) 349 If a space-stuffed message is received by an agent which handles 350 Format=Flowed, the space-stuffing is reversed and thus the message 351 appears unchanged. An agent which is not aware of Format=Flowed 352 will of course not undo any space-stuffing, thus Format=Flowed 353 messages may appear with a leading space on some lines (those which 354 start with a space, ">" which is not a quote indicator, or "From "). 356 Since lines which require space-stuffing rarely occur, and the 357 aesthetic consequences of unreversed space-stuffing are minimal, 358 this is not expected to be a significant problem. 360 4.5. Quoting 362 In Format=Flowed, the canonical quote indicator (or quote mark) is 363 one or more close angle bracket (">") characters. Lines which start 364 with the quote indicator are considered quoted. The number of ">" 365 characters at the start of the line specifies the quote depth. 366 Flowed lines which are also quoted may require special handling on 367 display and when copied to new messages. 369 When creating quoted flowed lines, each such line starts with the 370 quote indicator. 372 Note that because of space-stuffing, the lines 373 >> Exit, Stage Left 374 and 375 >>Exit, Stage Left 376 are semantically identical; both have a quote-depth of two, and a 377 content of "Exit, Stage Left". 379 However, the line 380 > > Exit, Stage Left 381 is different. It has a quote-depth of one, and a content of 382 "> Exit, Stage Left". 384 When generating quoted flowed lines, an agent needs to pay attention 385 to changes in quote depth. A sequence of quoted lines of the same 386 quote depth SHOULD be encoded as a paragraph, with the last line 387 generated as fixed and prior lines generated as flowed. 389 If a receiving agent wishes to reformat flowed quoted lines (joining 390 and/or wrapping them) on display or when generating new messages, 391 the lines SHOULD be de-quoted, reformatted, and then re-quoted. To 392 de-quote, the number of close angle brackets in the quote indicator 393 at the start of each line is counted. Consecutive lines with the 394 same quoting depth are considered one paragraph and are reformatted 395 together. To re-quote after reformatting, a quote indicator 396 containing the same number of close angle brackets originally 397 present are prefixed to each line. 399 On reception, if a change in quoting depth occurs on a flowed line, 400 this is an improperly formatted message. The receiver SHOULD handle 401 this error by using the 'quote-depth-wins' rule, which is to ignore 402 the flowed indicator and treat the line as fixed. That is, the 403 change in quote depth ends the paragraph. 405 For example, consider the following sequence of lines (using '*' to 406 indicate a soft line break, i.e., SP CRLF, and '#' to indicate a 407 hard line break, i.e., CRLF): 409 > Thou villainous ill-breeding spongy dizzy-eyed* 410 > reeky elf-skinned pigeon-egg!* <--- problem ---< 411 >> Thou artless swag-bellied milk-livered* 412 >> dismal-dreaming idle-headed scut!# 413 >>> Thou errant folly-fallen spleeny reeling-ripe* 414 >>> unmuzzled ratsbane!# 415 >>>> Henceforth, the coding style is to be strictly* 416 >>>> enforced, including the use of only upper case.# 417 >>>>> I've noticed a lack of adherence to the coding* 418 >>>>> styles, of late.# 419 >>>>>> Any complaints?# 421 The second line ends in a soft line break, even though it is the 422 last line of the one-deep quote block. The question then arises as 423 to how this line should be interpreted, considering that the next 424 line is the first line of the two-deep quote block. 426 The example text above, when processed according to quote-depth 427 wins, results in the first two lines being considered as one quoted, 428 flowed section, with a quote depth of 1; the third and fourth lines 429 become a quoted, flowed section, with a quote depth of 2. 431 A generating agent SHOULD NOT create this situation; a receiving 432 agent SHOULD handle it using quote-depth wins. 434 4.6. Digital Signatures and Encryption 436 If a message is digitally signed or encrypted it is important that 437 cryptographic processing use the on-the-wire Format=Flowed format. 438 That is, during generation the message SHOULD be prepared for 439 transmission, including addition of soft line breaks, 440 space-stuffing, and [Quoted-Printable] encoding (to protect soft 441 line breaks) before being digitally signed or encrypted; similarly, 442 on receipt the message SHOULD have the signature verified or be 443 decrypted before [Quoted-Printable] decoding and removal of stuffed 444 spaces, soft line breaks and quote marks, and reflowing. 446 4.7. Line Analysis Table 448 Lines contained in a Text/Plain body part with Format=Flowed can be 449 analyzed by examining the start and end of the line. If the line 450 starts with the quote indicator, it is quoted. If the line ends 451 with one or more space characters, it is flowed. This is summarized 452 by the following table: 454 Starts Ends in 455 with One or Line 456 Quote More Spaces Type 457 ------ ----------- --------------- 458 no no unquoted, fixed 459 yes no quoted, fixed 460 no yes unquoted, flowed 461 yes yes quoted, flowed 463 4.8. Examples 465 The following example contains three paragraphs: 467 `Take some more tea,' the March Hare said to Alice, very 468 earnestly. 470 `I've had nothing yet,' Alice replied in an offended tone, `so I 471 can't take more.' 473 `You mean you can't take LESS,' said the Hatter: `it's very easy 474 to take MORE than nothing.' 476 This could be encoded as follows (using '*' to indicate a soft line 477 break, that is, SP CRLF sequence, and '#' to indicate a hard line 478 break, that is, CRLF): 480 `Take some more tea,' the March Hare said to Alice, very* 481 earnestly.# 482 # 483 `I've had nothing yet,' Alice replied in an offended tone, `so* 484 I can't take more.'# 485 # 486 `You mean you can't take LESS,' said the Hatter: `it's very* 487 easy to take MORE than nothing.'# 489 Here we have the same exchange, in quoted form: 491 >>>Take some more tea.# 492 >>I've had nothing yet, so I can't take more.# 493 >You mean you can't take LESS, it's very easy to take* 494 >MORE than nothing.# 496 5. ABNF 498 The constructs used in Text/Plain; Format=Flowed body parts are 499 described using [ABNF], including the Core Rules: 501 paragraph = 1*flowed-line fixed-line 502 fixed-line = fixed / sig-sep 503 fixed = [quote] [stuffing] *text-char non-sp CRLF 504 flowed-line = flow-qt / flow-unqt 505 flow-qt = quote [stuffing] *text-char 1*SP CRLF 506 flow-unqt = [stuffing] *text-char 1*SP CRLF 507 non-empty = *text-char non-sp 508 non-sp = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F 509 ; any 7-bit US-ASCII character, excluding 510 ; NUL, CR, LF, and SP 511 quote = 1*">" 512 sig-sep = [quote] "--" SP CRLF 513 stuffing = [SP] ; space-stuffed, added on generation if 514 ; needed, deleted on reception 515 text-char = non-sp / SP 517 6. Failure Modes 519 6.1. Trailing White Space Corruption 521 There are systems in existence which alter trailing whitespace on 522 messages which pass through them. Such systems may strip, or in 523 rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP] 524 section 4.5.2. 526 Stripping trailing whitespace has the effect of converting flowed 527 lines to fixed lines, which results in a message no worse than if 528 Format=Flowed had not been used. 530 Adding trailing whitespace to a Format=Flowed message may result in 531 a malformed display or reply. 533 Since most systems which add trailing white space do so to create a 534 line which fills an internal record format, the result is almost 535 always a line which contains an even number of characters (counting 536 the added trailing white space). 538 One possible avoidance, therefore, would be to define Format=Flowed 539 lines to use either one or two trailing space characters to indicate 540 a flowed line, such that the total line length is odd. However, 541 considering the scarcity of such systems today, it is not worth the 542 added complexity. 544 7. Security Considerations 546 This parameter introduces no security considerations beyond those 547 which apply to Text/Plain. 549 Section 4.6 discusses the interaction between Format=Flowed and 550 digital signatures or encryption. 552 8. IANA Considerations 554 IANA is requested to add a reference to this specification in the 555 Text/Plain Media Type registration. 557 9. Internationalization Considerations 558 The line wrap and quoting specifications of Format=Flowed may not be 559 suitable for certain charsets, such as for Arabic and Hebrew 560 characters that read from right to left. Care should be taken in 561 applying format=flowed in these cases, as format=fixed combined with 562 quoted-printable encoding may be more suitable. 564 10. Acknowledgments 566 This proposal evolved from a discussion of Chris Newman's 567 Text/Paragraph draft which took place on the IETF 822 mailing list. 568 Special thanks to Ian Bell, Steve Dorner, Brian Kelley, Dan Kohn, 569 Laurence Lundblade, and Dan Wing for their reviews, comments, 570 suggestions, and discussions. 572 11. References 574 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 575 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 576 November 1997. 578 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 579 Requirement Levels", RFC 2119, Harvard University, March 1997. 581 [RICH] Resnick, Walker, "The text/enriched MIME Content-type", RFC 582 1896, QUALCOMM, InterCon, February 1996. 584 [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail Extensions 585 (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, 586 November 1996. 588 [Quoted-Printable] Freed, Borenstein, "Multipurpose Internet Mail 589 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 590 2045, Innosoft, First Virtual, November 1996. 592 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, Information 593 Sciences Institute, August 1982. 595 12. Editor's Address 597 Randall Gellens +1 619 651 5115 598 QUALCOMM Incorporated randy@qualcomm.com 599 6455 Lusk Blvd. 600 San Diego, CA 92121-2779 601 USA 603 13. Full Copyright Statement 604 Copyright (C) The Internet Society 1999. All Rights Reserved. 606 This document and translations of it may be copied and furnished to 607 others, and derivative works that comment on or otherwise explain it 608 or assist in its implementation may be prepared, copied, published 609 and distributed, in whole or in part, without restriction of any 610 kind, provided that the above copyright notice and this paragraph 611 are included on all such copies and derivative works. However, this 612 document itself may not be modified in any way, such as by removing 613 the copyright notice or references to the Internet Society or other 614 Internet organizations, except as needed for the purpose of 615 developing Internet standards in which case the procedures for 616 copyrights defined in the Internet Standards process must be 617 followed, or as required to translate it into languages other than 618 English. 620 The limited permissions granted above are perpetual and will not be 621 revoked by the Internet Society or its successors or assigns. 623 This document and the information contained herein is provided on an 624 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 625 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 626 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 627 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 628 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Gellens [Page 13] Expires November 1999