7Network Working Group R. Gellens
8Request for Comments: 3676 Qualcomm
9Obsoletes: 2646 February 2004
10Category: Standards Track
13 The Text/Plain Format and DelSp Parameters
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2004). All Rights Reserved.
29 This specification establishes two parameters (Format and DelSP) to
30 be used with the Text/Plain media type. In the presence of these
31 parameters, trailing whitespace is used to indicate flowed lines and
32 a canonical quote indicator is used to indicate quoted lines. This
33 results in an encoding which appears as normal Text/Plain in older
34 implementations, since it is in fact normal Text/Plain, yet provides
35 for superior wrapping/flowing, and quoting.
37 This document supersedes the one specified in RFC 2646, "The
38 Text/Plain Format Parameter", and adds the DelSp parameter to
39 accommodate languages/coded character sets in which ASCII spaces are
40 not used or appear rarely.
44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
45 2. Conventions Used in this Document . . . . . . . . . . . . . . 2
46 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
47 3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
48 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
49 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
50 4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
51 4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
52 4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
53 4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
54 4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 9
58Gellens Standards Track [Page 1]
60RFC 3676 Text/Plain Format and DelSp Parameters February 2004
63 4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 9
64 4.6. Digital Signatures and Encryption . . . . . . . . . . . 11
65 4.7. Examples. . . . . . . . . . . . . . . . . . . . . . . . 12
66 5. Interoperability. . . . . . . . . . . . . . . . . . . . . . . 12
67 6. ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
68 7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 14
69 7.1. Trailing White Space Corruption . . . . . . . . . . . . 14
70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
72 10. Internationalization Considerations . . . . . . . . . . . . . 15
73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
74 12. Normative References. . . . . . . . . . . . . . . . . . . . . 16
75 13. Informative References. . . . . . . . . . . . . . . . . . . . 16
76 Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . . . 18
77 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 19
78 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 20
82 Interoperability problems have been observed with erroneous labelling
83 of paragraph text as Text/Plain, and with various forms of
84 "embarrassing line wrap". (See Section 3.)
86 Attempts to deploy new media types, such as Text/Enriched [Rich] and
87 Text/HTML [HTML] have suffered from a lack of backwards compatibility
88 and an often hostile user reaction at the receiving end.
90 What is required is a format which is in all significant ways
91 Text/Plain, and therefore is quite suitable for display as
92 Text/Plain, and yet allows the sender to express to the receiver
93 which lines are quoted and which lines are considered a logical
94 paragraph, and thus eligible to be flowed (wrapped and joined) as
972. Conventions Used in this Document
99 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
100 and "MAY" in this document are to be interpreted as described in "Key
101 words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
103 The term "paragraph" is used here to mean a series of lines which are
104 logically to be treated as a unit for display purposes and eligible
105 to be flowed (wrapped and joined) as appropriate to fit in the
106 display window and when creating text for replies, forwarding, etc.
114Gellens Standards Track [Page 2]
116RFC 3676 Text/Plain Format and DelSp Parameters February 2004
121 The Text/Plain media type is the lowest common denominator of
122 Internet email, with lines of no more than 998 characters (by
123 convention usually no more than 78), and where the carriage-return
124 and line-feed (CRLF) sequence represents a line break (see [MIME-IMT]
127 Text/Plain is usually displayed as preformatted text, often in a
128 fixed font. That is, the characters start at the left margin of the
129 display window, and advance to the right until a CRLF sequence is
130 seen, at which point a new line is started, again at the left margin.
131 When a line length exceeds the display window, some clients will wrap
132 the line, while others invoke a horizontal scroll bar.
134 Text which meets this description is defined by this memo as "fixed".
136 Some interoperability problems have been observed with this format:
140 Many modern programs use a proportional-spaced font, and use CRLF to
141 represent paragraph breaks. Line breaks are "soft", occurring as
142 needed on display. That is, characters are grouped into a paragraph
143 until a CRLF sequence is seen, at which point a new paragraph is
144 started. Each paragraph is displayed, starting at the left margin
145 (or paragraph indent), and continuing to the right until a word is
146 encountered which does not fit in the remaining display width. This
147 word is displayed at the left margin of the next line. This
148 continues until the paragraph ends (a CRLF is seen). Extra vertical
149 space is left between paragraphs.
151 Text which meets this description is defined by this memo as
154 Numerous software products erroneously label this format as
155 Text/Plain, resulting in much user discomfort.
1573.2. Embarrassing Line Wrap
159 As Text/Plain messages are quoted in replies or forwarded messages,
160 each line gradually increases in length, eventually being arbitrarily
161 hard wrapped, resulting in "embarrassing line wrap". This produces
162 text which is, at best, hard to read, and often confuses
170Gellens Standards Track [Page 3]
172RFC 3676 Text/Plain Format and DelSp Parameters February 2004
177 >>>>>>This is a comment from the first message to show a
179 >>>>>This is a comment from the second message to show a
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.
192 This is paragraph text that is
193 meant to be flowed across
195 However, the sending mailer is
196 converting it to fixed text at
198 characters, which causes it to
199 look like this when shown on a
205 Attempts to deploy new media types, such as Text/Enriched [Rich] and
206 Text/HTML [HTML] have suffered from a lack of backwards compatibility
207 and an often hostile user reaction at the receiving end.
209 In particular, Text/Enriched requires that open angle brackets ("<")
210 and hard line breaks be doubled, with resulting user unhappiness when
211 viewed as Text/Plain. Text/HTML requires even more alteration of
212 text, with a corresponding increase in user complaints.
214 A proposal to define a new media type to explicitly represent the
215 paragraph form suffered from a lack of interoperability with
216 currently deployed software. Some programs treat unknown subtypes of
217 TEXT as an attachment.
226Gellens Standards Track [Page 4]
228RFC 3676 Text/Plain Format and DelSp Parameters February 2004
231 What is desired is a format which is in all significant ways
232 Text/Plain, and therefore is quite suitable for display as
233 Text/Plain, and yet allows the sender to express to the receiver
234 which lines can be considered a logical paragraph, and thus flowed
235 (wrapped and joined) as appropriate.
2374. The Format and DelSp Parameters
239 This specification defines two MIME parameters for use with
248 (Neither the parameter names nor values are case sensitive.)
250 If Format is not specified, or if the value is not recognized, a
251 value of Fixed is assumed. The semantics of the Fixed value are the
252 usual associated with Text/Plain [MIME-IMT].
254 A Format value of Flowed indicates that the definition of flowed text
255 (as specified in this memo) was used on generation, and MAY be used
258 Note that because Format is a parameter of the Text/Plain content-
259 type, any content-transfer-encoding used is irrelevant to the
260 processing of flowed text.
262 If DelSp is not specified, or if its value is not recognized, a value
263 of No is assumed. The use of DelSp without a Format value of Flowed
264 is undefined. When creating messages, DelSp SHOULD NOT be specified
265 in Text content types other than Text/Plain with Format = Flowed.
266 When receiving messages, DelSp SHOULD be ignored if used in a Text
267 content type other than Text/Plain with Format = Flowed.
269 This section discusses flowed text; section 6 provides a formal
272 Section 5 discusses interoperability.
274 Note that this memo describes an on-the-wire format. It does not
275 address formats for local file storage.
282Gellens Standards Track [Page 5]
284RFC 3676 Text/Plain Format and DelSp Parameters February 2004
2874.1. Interpreting Format=Flowed
289 If the first character of a line is a quote mark (">"), the line is
290 considered to be quoted (see Section 4.5). Logically, all quote
291 marks are counted and deleted, resulting in a line with a non-zero
292 quote depth, and content. (The agent is of course free to display
293 the content with quote marks or excerpt bars or anything else.)
294 Logically, this test for quoted lines is done before any other tests
295 (that is, before checking for space-stuffed and flowed).
297 If the first character of a line is a space, the line has been
298 space-stuffed (see Section 4.4). Logically, this leading space is
299 deleted before examining the line further (that is, before checking
302 If the line ends in a space, the line is flowed. Otherwise it is
303 fixed. The exception to this rule is a signature separator line,
304 described in Section 4.3. Such lines end in a space but are neither
307 If the line is flowed and DelSp is "yes", the trailing space
308 immediately prior to the line's CRLF is logically deleted. If the
309 DelSp parameter is "no" (or not specified, or set to an unrecognized
310 value), the trailing space is not deleted.
312 Any remaining trailing spaces are part of the line's content, but the
313 CRLF of a soft line break is not.
315 A series of one or more flowed lines followed by one fixed line is
316 considered a paragraph, and MAY be flowed (wrapped and unwrapped) as
317 appropriate on display and in the construction of new messages (see
320 An interpreting agent SHOULD allow for three exceptions to the rule
321 that paragraphs end with a fixed line. These exceptions are
322 improperly constructed messages: a flowed line SHOULD be considered
323 to end the paragraph if it is followed by a line of a different quote
324 depth (see 4.5) or by a signature separator (see 4.3); the end of the
325 body also ends the paragraph.
327 A line consisting of one or more spaces (after deleting a space
328 acting as stuffing) is considered a flowed line.
330 An empty line (just a CRLF) is a fixed line.
332 Note that, for Unicode text, [Annex-14] provides guidance for
333 choosing at which characters to wrap a line.
338Gellens Standards Track [Page 6]
340RFC 3676 Text/Plain Format and DelSp Parameters February 2004
3434.2. Generating Format=Flowed
345 When generating Format=Flowed text, lines SHOULD be 78 characters or
346 shorter, including any trailing white space and also including any
347 space added as part of stuffing (see Section 4.4). As suggested
348 values, any paragraph longer than 78 characters in total length could
349 be wrapped using lines of 72 or fewer characters. While the specific
350 line length used is a matter of aesthetics and preference, longer
351 lines are more likely to require rewrapping and to encounter
352 difficulties with older mailers. (It has been suggested that 66
353 character lines are the most readable.)
355 The restriction to 78 or fewer characters between CRLFs on the wire
356 is to conform to [MSG-FMT].
358 (In addition to conformance to [MSG-FMT], there is a historical need
359 that all lines, even when displayed by a non-flowed-aware program,
360 will fit in a standard 79- or 80-column screen without having to be
361 wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit
362 on a line, the last column is often reserved for a line-wrap
365 When creating flowed text, the generating agent wraps, that is,
366 inserts 'soft' line breaks as needed. Soft line breaks are added at
367 natural wrapping points, such as between words. A soft line break is
370 There are two techniques for inserting soft line breaks. The older
371 technique, established by RFC 2646, creates a soft line break by
372 inserting a CRLF after the occurrence of a space. With this
373 technique, soft line breaks are only possible where spaces already
374 occur. When this technique is used, the DelSp parameter SHOULD be
375 used; if used it MUST be set to "no".
377 The newer technique, suitable for use even with languages/coded
378 character sets in which the ASCII space character is rare or not
379 used, creates a soft line break by inserting a SP CRLF sequence.
380 When this technique is used, the DelSp parameter MUST be used and
381 MUST be set to "yes". Note that because of space-stuffing (see
382 Section 4.4), when this technique is used and a soft line break is
383 inserted at a point where a SP already exists (such as between
384 words), if the SP CRLF sequence is added immediately before the SP,
385 the pre-existing SP becomes leading and thus requires stuffing. It
386 is RECOMMENDED that agents avoid this by inserting the SP CRLF
387 sequence following the existing SP.
389 Generating agents MAY use either method within each Text/Plain body
394Gellens Standards Track [Page 7]
396RFC 3676 Text/Plain Format and DelSp Parameters February 2004
399 Regardless of which technique is used, a generating agent SHOULD NOT
400 insert a space in an unnatural location, such as into a word (a
401 sequence of printable characters, not containing spaces, in a
402 language/coded character set in which spaces are common). If faced
403 with such a word which exceeds 78 characters (but less than 998
404 characters, the [SMTP] limit on line length), the agent SHOULD send
405 the word as is and exceed the 78-character limit on line length.
407 A generating agent SHOULD:
409 o Ensure all lines (fixed and flowed) are 78 characters or fewer in
410 length, counting any trailing space as well as a space added as
411 stuffing, but not counting the CRLF, unless a word by itself
412 exceeds 78 characters.
414 o Trim spaces before user-inserted hard line breaks.
416 A generating agent MUST:
418 o Space-stuff lines which start with a space, "From ", or ">".
420 In order to create messages which do not require space-stuffing, and
421 are thus more aesthetically pleasing when viewed as Format=Fixed, a
422 generating agent MAY avoid wrapping immediately before ">", "From ",
425 (See Sections 4.4 and 4.5 for more information on space-stuffing and
426 quoting, respectively.)
428 A Format=Flowed message consists of zero or more paragraphs, each
429 containing one or more flowed lines followed by one fixed line. The
430 usual case is a series of flowed text lines with blank (empty) fixed
433 Any number of fixed lines can appear between paragraphs.
435 When placing soft line breaks in a paragraph, generating agents MUST
436 NOT place them in a way that causes any line of the paragraph to be a
437 signature separator line, because paragraphs cannot contain signature
438 separator lines (see Sections 4.3 and 6).
440 [Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed
441 unless absolutely necessary (for example, non-US-ASCII (8-bit)
442 characters over a strictly 7-bit transport such as unextended
443 [SMTP]). In particular, a message SHOULD NOT be encoded in Quoted-
444 Printable for the sole purpose of protecting the trailing space on
445 flowed lines unless the body part is cryptographically signed or
446 encrypted (see Section 4.6).
450Gellens Standards Track [Page 8]
452RFC 3676 Text/Plain Format and DelSp Parameters February 2004
455 The intent of Format=Flowed is to allow user agents to generate
456 flowed text which is non-obnoxious when viewed as pure, raw
457 Text/Plain (without any decoding); use of Quoted-Printable hinders
458 this and may cause Format=Flowed to be rejected by end users.
4604.3. Usenet Signature Convention
462 There is a long-standing convention in Usenet news which also
463 commonly appears in Internet mail of using "-- " as the separator
464 line between the body and the signature of a message. When
465 generating a Format=Flowed message containing a Usenet-style
466 separator before the signature, the separator line is sent as-is.
467 This is a special case; an (optionally quoted or quoted and stuffed)
468 line consisting of DASH DASH SP is neither fixed nor flowed.
470 Generating agents MUST NOT end a paragraph with such a signature
473 A receiving agent needs to test for a signature line both before the
474 test for a quoted line (see Section 4.5) and also after logically
475 counting and deleting quote marks and stuffing (see Section 4.4) from
480 In order to allow for unquoted lines which start with ">", and to
481 protect against systems which "From-munge" in-transit messages
482 (modifying any line which starts with "From " to ">From "),
483 Format=Flowed provides for space-stuffing.
485 Space-stuffing adds a single space to the start of any line which
486 needs protection when the message is generated. On reception, if the
487 first character of a line is a space, it is logically deleted. This
488 occurs after the test for a quoted line (which logically counts and
489 deletes any quote marks), and before the test for a flowed line.
491 On generation, any unquoted lines which start with ">", and any lines
492 which start with a space or "From " MUST be space-stuffed. Other
493 lines MAY be space-stuffed as desired.
495 (Note that space-stuffing is conceptually similar to dot-stuffing as
496 specified in [SMTP].)
500 In Format=Flowed, the canonical quote indicator (or quote mark) is
501 one or more close angle bracket (">") characters. Lines which start
502 with the quote indicator are considered quoted. The number of ">"
506Gellens Standards Track [Page 9]
508RFC 3676 Text/Plain Format and DelSp Parameters February 2004
511 characters at the start of the line specifies the quote depth.
512 Flowed lines which are also quoted may require special handling on
513 display and when copied to new messages.
515 When creating quoted flowed lines, each such line starts with the
518 Note that because of space-stuffing, the lines
522 are semantically identical; both have a quote-depth of two, and a
523 content of "Exit, Stage Left".
527 is different. It has a quote-depth of one, and a content of
528 "> Exit, Stage Left".
530 When generating quoted flowed lines, an agent needs to pay attention
531 to changes in quote depth. All lines of a paragraph MUST be
532 unquoted, or else they MUST all be quoted and have the same quote
533 depth. Therefore, whenever there is a change in quote depth, or a
534 change from quoted to unquoted, or change from unquoted to quoted,
535 the line immediately preceding the change MUST NOT be a flowed line.
537 If a receiving agent wishes to reformat flowed quoted lines (joining
538 and/or wrapping them) on display or when generating new messages, the
539 lines SHOULD be de-quoted, reformatted, and then re-quoted. To de-
540 quote, the number of close angle brackets in the quote indicator at
541 the start of each line is counted. To re-quote after reformatting, a
542 quote indicator containing the same number of close angle brackets
543 originally present are prefixed to each line.
545 On reception, if a change in quote depth occurs on a flowed line,
546 this is an improperly formatted message. The receiver SHOULD handle
547 this error by using the 'quote-depth-wins' rule, which is to consider
548 the paragraph to end with the flowed line immediately preceding the
549 change in quote depth.
551 In other words, whenever two adjacent lines have different quote
552 depths, senders MUST ensure that the earlier line is not flowed (does
553 not end in a space), and receivers finding a flowed line there SHOULD
554 treat it as the last line of a paragraph.
556 For example, consider the following sequence of lines (using '*' to
557 indicate a soft line break, i.e., SP CRLF, and '#' to indicate a hard
558 line break, i.e., CRLF):
562Gellens Standards Track [Page 10]
564RFC 3676 Text/Plain Format and DelSp Parameters February 2004
567 > Thou villainous ill-breeding spongy dizzy-eyed*
568 > reeky elf-skinned pigeon-egg!* <--- problem ---<
569 >> Thou artless swag-bellied milk-livered*
570 >> dismal-dreaming idle-headed scut!#
571 >>> Thou errant folly-fallen spleeny reeling-ripe*
572 >>> unmuzzled ratsbane!#
573 >>>> Henceforth, the coding style is to be strictly*
574 >>>> enforced, including the use of only upper case.#
575 >>>>> I've noticed a lack of adherence to the coding*
576 >>>>> styles, of late.#
577 >>>>>> Any complaints?#
579 The second line ends in a soft line break, even though it is the last
580 line of the one-deep quote block. The question then arises as to how
581 this line is to be interpreted, considering that the next line is the
582 first line of the two-deep quote block.
584 The example text above, when processed according to quote-depth wins,
585 results in the first two lines being considered as one quoted, flowed
586 section, with a quote depth of 1; the third and fourth lines become a
587 quoted, flowed section, with a quote depth of 2.
589 A generating agent MUST NOT create this situation; a receiving agent
590 SHOULD handle it by giving preference to the quote depth.
5924.6. Digital Signatures and Encryption
594 If a message is digitally signed or encrypted it is important that
595 cryptographic processing use the same text for signature verification
596 and/or decryption as was used for signature generation and/or
597 encryption. Since the use of format=flowed allows text to be altered
598 (by adding or removing line breaks and trailing spaces) between
599 composition and transmission, and between reception and display,
600 interoperability problems or security vulnerabilities may arise if
601 originator and recipient do not both use the on-the-wire format for
602 cryptographic processing.
604 The implications of the interaction between format=flowed and any
605 specific cryptographic process depend on the details of the
606 cryptographic processing and should be understood before using
607 format=flowed in conjunction with signed and/or encrypted messages.
609 Note that [OpenPGP] specifies (in Section 7.1) that "any trailing
610 whitespace (spaces, and tabs, 0x09) at the end of any line is ignored
611 when the cleartext signature is calculated."
618Gellens Standards Track [Page 11]
620RFC 3676 Text/Plain Format and DelSp Parameters February 2004
623 Thus it would be possible to add, in transit, a format=flowed header
624 to a regular, format=fixed vanilla PGP (not [OpenPGP-MIME]) signed
625 message and add arbitrary trailing space characters without this
626 addition being detected. This would change the rendering of the
627 article by a client which supported format=flowed.
629 Therefore, the use of [OpenPGP] with format=flowed messages is
630 strongly discouraged. [OpenPGP-MIME] is recommended instead.
634 The following example contains three paragraphs:
636 `Take some more tea,' the March Hare said to Alice, very
639 `I've had nothing yet,' Alice replied in an offended tone, `so I
642 `You mean you can't take LESS,' said the Hatter: `it's very easy
643 to take MORE than nothing.'
645 This could be encoded as follows (using '*' to indicate a soft line
646 break, that is, SP CRLF sequence, and '#' to indicate a hard line
647 break, that is, CRLF):
649 `Take some more tea,' the March Hare said to Alice, very*
652 `I've had nothing yet,' Alice replied in an offended tone, `so*
655 `You mean you can't take LESS,' said the Hatter: `it's very*
656 easy to take MORE than nothing.'#
658 To show an example of quoting, here we have the same exchange,
659 presented as a series of direct quotes:
661 >>>Take some more tea.#
662 >>I've had nothing yet, so I can't take more.#
663 >You mean you can't take LESS, it's very easy to take*
668 Because flowed lines are all-but-indistinguishable from fixed lines,
669 software which does not recognize Format=Flowed treats flowed lines
670 as normal Text/Plain (which is what they are). Thus, Format=Flowed
674Gellens Standards Track [Page 12]
676RFC 3676 Text/Plain Format and DelSp Parameters February 2004
679 interoperates with older clients, although flowed lines will have
680 trailing white space inserted.
682 If a space-stuffed message is received by an agent which handles
683 Format=Flowed, the space-stuffing is reversed and thus the message
684 appears unchanged. An agent which is not aware of Format=Flowed will
685 of course not undo any space-stuffing; thus Format=Flowed messages
686 may appear with a leading space on some lines (those which start with
687 a space, ">" which is not a quote indicator, or "From "). Since
688 lines which require space-stuffing rarely occur, and the aesthetic
689 consequences of unreversed space-stuffing are minimal, this is not
690 expected to be a significant problem.
692 If some lines begin with one or more spaces, the generating agent MAY
693 space-stuff all lines, to maintain the relative indentation of the
694 lines when viewed by clients which are not aware of Format=Flowed.
696 Messages generated with DelSp=yes and received by clients which are
697 aware of Format=Flowed but are not aware of the DelSp parameter will
698 have an extra space remaining after removal of soft line breaks.
699 Thus, when generating text in languages/coded character sets in which
700 spaces are common, the generating agent MAY always use the DelSp=no
703 Hand-aligned text, such as ASCII tables or art, source code, etc.,
704 SHOULD be sent as fixed, not flowed lines.
708 The constructs used in Text/Plain; Format=Flowed body parts are
709 described using Augmented Backus-Naur Form [ABNF], including the core
710 rules defined in Appendix A.
712 Note that the SP (space) and ">" characters are encoded according to
713 the charset parameter.
715flowed-body = *( paragraph / fixed-line / sig-sep )
716paragraph = 1*flowed-line fixed-line
717 ; all lines in paragraph MUST be unquoted or
718 ; have same quote depth
719flowed-line = ( flowed-line-qt / flowed-line-unqt ) flow CRLF
720flowed-line-qt = quote ( ( stuffing stuffed-flowed ) /
722flowed-line-unqt = ( stuffing stuffed-flowed ) / unstuffed-flowed
723stuffed-flowed = *text-char
724unstuffed-flowed = non-sp-quote *text-char
725fixed-line = fixed-line-qt / fixed-line-unqt
726fixed-line-qt = quote ( ( stuffing stuffed-fixed ) /
730Gellens Standards Track [Page 13]
732RFC 3676 Text/Plain Format and DelSp Parameters February 2004
735 unstuffed-fixed ) CRLF
736fixed-line-unqt = ( stuffed-fixed / unstuffed-fixed ) CRLF
737stuffed-fixed = *text-char non-sp
738unstuffed-fixed = non-sp-quote [ *text-char non-sp ]
739sig-sep = [ quote [stuffing] ] "--" SP CRLF
742stuffing = SP ; space-stuffed, added on generation if
743 ; needed, deleted on reception
744flow = SP ; space before CRLF indicates flowed line,
745 ; if DelSp=yes, space was added on generation
746 ; and is deleted on reception
747non-sp-quote = < any character except NUL, CR, LF, SP, quote-mark >
748non-sp = non-sp-quote / quote-mark
749text-char = non-sp / SP
751 That is, a Format=Flowed message body consists of any number of
752 paragraphs and/or fixed lines and/or signature separator lines;
753 paragraphs need at least one flowed line and are terminated by a
754 fixed line; the fixed line terminating the paragraph is part of the
755 paragraph. (There are some exceptions to this described in the
758 Without at least one flowed line, there is a series of fixed lines,
759 each independent. There is no paragraph.
761 With at least one flowed line, there is a paragraph, and the received
762 lines can be reformed and flowed to fit the display window size.
763 This can only be done if the lines are part of a logical grouping,
766 Note that the definitions of flowed-line and sig-sep are potentially
767 ambiguous: a signature separator line matches both, but is treated as
768 a signature separator line and not a flowed line.
7727.1. Trailing White Space Corruption
774 There are systems in existence which alter trailing whitespace on
775 messages which pass through them. Such systems may strip, or in
776 rarer cases, add trailing whitespace, in violation of RFC 2821 [SMTP]
779 Stripping trailing whitespace has the effect of converting flowed
780 lines to fixed lines, which results in a message no worse than if
781 Format=Flowed had not been used.
786Gellens Standards Track [Page 14]
788RFC 3676 Text/Plain Format and DelSp Parameters February 2004
791 Adding trailing whitespace to a Format=Flowed message may result in a
792 malformed display or reply.
794 Since most systems which add trailing white space do so to create a
795 line which fills an internal record format, the result is almost
796 always a line which contains an even number of characters (counting
797 the added trailing white space).
799 One possible avoidance, therefore, would be to define Format=Flowed
800 lines to use either one or two trailing space characters to indicate
801 a flowed line, such that the total line length is odd. However,
802 considering the scarcity of such systems today, it is not worth the
8058. Security Considerations
807 Any security considerations which apply to Text/Plain also apply to
808 Text/Plain with Format=Flowed.
810 Section 4.6 discusses the interaction between Format=Flowed and
811 digital signatures or encryption.
8139. IANA Considerations
815 IANA has added a reference to this specification in the Text/Plain
816 Media Type registration.
81810. Internationalization Considerations
820 The line wrap and quoting specifications of Format=Flowed may not be
821 suitable for certain charsets, such as for Arabic and Hebrew
822 characters that read from right to left. Care needs to be taken in
823 applying format=flowed in these cases, as format=fixed combined with
824 [quoted-printable] encoding may be more suitable.
826 The DelSp parameter was added specifically to permit Format=Flowed to
827 be used with languages/coded character sets in which the ASCII space
828 character is rarely used, or not used at all.
832 The DelSp parameter was developed during a series of discussions
833 among a number of people, including Harald Alvestrand, Grant Baillie,
834 Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed,
835 Alexey Melnikov, John Myers, and Pete Resnick.
842Gellens Standards Track [Page 15]
844RFC 3676 Text/Plain Format and DelSp Parameters February 2004
847 Corrections and clarifications to RFC 2646 and early versions of this
848 document were pointed out by several people, including Adam Costello,
849 Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho
850 Mahalingam, Keith Moore, Greg Troxel, and Dan Wing.
852 I'm told that NeXT's mail application used a very similar mechanism
853 (without support for non-Western languages) in 1992.
85512. Normative References
857 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
858 for Syntax Specifications: ABNF", RFC 2234,
861 [KEYWORDS] Bradner, S., "Key words for use in RFCs to
862 Indicate Requirement Levels", BCP 14, RFC 2119,
865 [MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose
866 Internet Mail Extensions (MIME) Part Two: Media
867 Types", RFC 2046, November 1996.
869 [Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose
870 Internet Mail Extensions (MIME) Part One: Format
871 of Internet Message Bodies", RFC 2045, November
87413. Informative References
876 [Annex-14] Unicode Standard Annex #14, "Line Breaking
878 <URL:http://www.unicode.org/unicode/reports/tr14/>
880 [MSG-FMT] Resnick, P., Ed., "Internet Message Format", RFC
883 [OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R.
884 Thayer, "OpenPGP Message Format", RFC 2440,
887 [OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good
888 Privacy (PGP)", RFC 2015, October 1996.
890 Elkins, M., Del Torto, D., Levien, R. and J.
891 Roessler, "MIME Security with OpenPGP", RFC 3156,
898Gellens Standards Track [Page 16]
900RFC 3676 Text/Plain Format and DelSp Parameters February 2004
903 [Rich] Resnick, P. and A. Walker, "The text/enriched MIME
904 Content-type", RFC 1896, February 1996.
906 [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
907 RFC 2821, April 2001.
954Gellens Standards Track [Page 17]
956RFC 3676 Text/Plain Format and DelSp Parameters February 2004
959Appendix A: Changes from RFC 2646
963 o Added DelSp parameter to handle languages and coded character sets
964 in which space is less common or not used.
965 o Updated text on generating and interpreting to accommodate the
967 o Changed the limits of 79 or 80 to be 78 in conformance with RFC
969 o Added text on generating to clarify that the 78-character limit
970 includes trailing white space and stuffing.
971 o Changed sig-sep in ABNF to allow stuffing.
972 o Changed fixed-line to allow empty lines in ABNF.
973 o Added explanatory text following ABNF.
974 o Moved text from Abstract to new Introduction; rewrote Abstract.
975 o Moved interoperability text to new section, and updated.
976 o Clarified Security Considerations.
977 o Text on digital signatures now discusses that OpenPGP ignores
978 trailing white space.
979 o Mention Unicode Annex 14.
980 o Added mention of quoting to Abstract and Introduction.
981 o Deleted line analysis table.
982 o Added recommendations for OpenPGP and OpenPGP-MIME.
983 o Rewrote ABNF rules to remove most ambiguity and note remaining
985 o Added note that c-t-e is irrelevant to flowed text processing.
986 o Added text indicating that end of data terminates a paragraph.
987 o Moved sig-sep out of fixed-line ABNF.
988 o Changed some SHOULDs to MUSTs (space-stuffing, quoted paragraphs).
989 o Added note to ABNF that space and ">" are encoded according to
991 o Mentioned exceptions in section on interpreting.
992 o Clarified and made consistent treatment of signature separator
997 o Added mention of NeXT's mail application to Acknowledgments.
998 o Updated Acknowledgments.
999 o Updated [SMTP] reference to 2821.
1001 o Split References into Normative and Informative.
1002 o Improved text wording in some areas.
1003 o Standardize on "quote depth", not "quoting depth".
1004 o Moved section on interpreting before section on generating.
1005 o Reworded non-normative "should"s.
1006 o Noted meaning of "paragraph".
1010Gellens Standards Track [Page 18]
1012RFC 3676 Text/Plain Format and DelSp Parameters February 2004
1015 The DelSp parameter was added specifically to permit Format=Flowed to
1016 be used with languages/coded character sets in which the ASCII space
1017 character is rarely used, or not used at all. The DelSp mechanism
1018 was selected despite having been initially rejected as too much of a
1019 kludge, because among the many different techniques proposed, it
1020 allows for maximum interoperability among clients which support
1021 neither this specification nor RFC 2646, those which do support RFC
1022 2646 but not this specification, and those that do support this
1023 specification; this set is multiplied by those that handle
1024 languages/coded character sets in which spaces are common, and in
1025 which they are uncommon or not used.
1030 QUALCOMM Incorporated
1031 5775 Morehouse Drive
1035 Phone: +1 858 651 5115
1036 EMail: randy@qualcomm.com
1066Gellens Standards Track [Page 19]
1068RFC 3676 Text/Plain Format and DelSp Parameters February 2004
1071Full Copyright Statement
1073 Copyright (C) The Internet Society (2004). This document is subject
1074 to the rights, licenses and restrictions contained in BCP 78 and
1075 except as set forth therein, the authors retain all their rights.
1077 This document and the information contained herein are provided on an
1078 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1079 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
1080 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
1081 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1082 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1085Intellectual Property
1087 The IETF takes no position regarding the validity or scope of any
1088 Intellectual Property Rights or other rights that might be claimed
1089 to pertain to the implementation or use of the technology
1090 described in this document or the extent to which any license
1091 under such rights might or might not be available; nor does it
1092 represent that it has made any independent effort to identify any
1093 such rights. Information on the procedures with respect to
1094 rights in RFC documents can be found in BCP 78 and BCP 79.
1096 Copies of IPR disclosures made to the IETF Secretariat and any
1097 assurances of licenses to be made available, or the result of an
1098 attempt made to obtain a general license or permission for the use
1099 of such proprietary rights by implementers or users of this
1100 specification can be obtained from the IETF on-line IPR repository
1101 at http://www.ietf.org/ipr.
1103 The IETF invites any interested party to bring to its attention
1104 any copyrights, patents or patent applications, or other
1105 proprietary rights that may cover technology that may be required
1106 to implement this standard. Please address the information to the
1107 IETF at ietf-ipr@ietf.org.
1111 Funding for the RFC Editor function is currently provided by the
1122Gellens Standards Track [Page 20]