specific cryptographic process depend on the details of the
cryptographic processing and should be understood before using
format=flowed in conjunction with signed and/or encrypted messages.
Note that [OpenPGP] specifies (in Section 7.1) that "any trailing
whitespace (spaces, and tabs, 0x09) at the end of any line is ignored
when the cleartext signature is calculated."
Thus it would be possible to add, in transit, a format=flowed header
to a regular, format=fixed vanilla PGP (not [OpenPGP-MIME]) signed
message and add arbitrary trailing space characters without this
addition being detected. This would change the rendering of the
article by a client which supported format=flowed.
Therefore, the use of [OpenPGP] with format=flowed messages is
strongly discouraged. [OpenPGP-MIME] is recommended instead.
4.7. Examples
The following example contains three paragraphs:
`Take some more tea,’ the March Hare said to Alice, very
earnestly.
`I’ve had nothing yet,’ Alice replied in an offended tone, `so I
can’t take more.’
`You mean you can’t take LESS,’ said the Hatter: `it’s very easy
to take MORE than nothing.’
This could be encoded as follows (using ’*’ to indicate a soft line
break, that is, SP CRLF sequence, and ’#’ to indicate a hard line
break, that is, CRLF):
`Take some more tea,’ the March Hare said to Alice, very*
earnestly.#
#
`I’ve had nothing yet,’ Alice replied in an offended tone, `so*
I can’t take more.’#
#
`You mean you can’t take LESS,’ said the Hatter: `it’s very*
easy to take MORE than nothing.’#
To show an example of quoting, here we have the same exchange,
presented as a series of direct quotes:
>>>Take some more tea.#
>>I’ve had nothing yet, so I can’t take more.#
>You mean you can’t take LESS, it’s very easy to take*
>MORE than nothing.#
5. Interoperability
Because flowed lines are all-but-indistinguishable from fixed lines,
software which does not recognize Format=Flowed treats flowed lines
as normal Text/Plain (which is what they are). Thus, Format=Flowed
interoperates with older clients, although flowed lines will have
trailing white space inserted.
If a space-stuffed message is received by an agent which handles
Format=Flowed, the space-stuffing is reversed and thus the message
appears unchanged. An agent which is not aware of Format=Flowed will
of course not undo any space-stuffing; thus Format=Flowed messages
may appear with a leading space on some lines (those which start with
a space, ">" which is not a quote indicator, or "From "). Since
lines which require space-stuffing rarely occur, and the aesthetic
consequences of unreversed space-stuffing are minimal, this is not
expected to be a significant problem.
If some lines begin with one or more spaces, the generating agent MAY
space-stuff all lines, to maintain the relative indentation of the
lines when viewed by clients which are not aware of Format=Flowed.
Messages generated with DelSp=yes and received by clients which are
aware of Format=Flowed but are not aware of the DelSp parameter will
have an extra space remaining after removal of soft line breaks.
Thus, when generating text in languages/coded character sets in which
spaces are common, the generating agent MAY always use the DelSp=no
method.
Hand-aligned text, such as ASCII tables or art, source code, etc.,
SHOULD be sent as fixed, not flowed lines.
6. ABNF
The constructs used in Text/Plain; Format=Flowed body parts are
described using Augmented Backus-Naur Form [ABNF], including the core
rules defined in Appendix A.
Note that the SP (space) and ">" characters are encoded according to
the charset parameter.
flowed-body = *( paragraph / fixed-line / sig-sep )
paragraph = 1*flowed-line fixed-line
; all lines in paragraph MUST be unquoted or
; have same quote depth
flowed-line = ( flowed-line-qt / flowed-line-unqt ) flow CRLF
flowed-line-qt = quote ( ( stuffing stuffed-flowed ) /
unstuffed-flowed )
flowed-line-unqt = ( stuffing stuffed-flowed ) / unstuffed-flowed
stuffed-flowed = *text-char
unstuffed-flowed = non-sp-quote *text-char
fixed-line = fixed-line-qt / fixed-line-unqt
fixed-line-qt = quote ( ( stuffing stuffed-fixed ) /
unstuffed-fixed ) CRLF
fixed-line-unqt = ( stuffed-fixed / unstuffed-fixed ) CRLF
stuffed-fixed = *text-char non-sp
unstuffed-fixed = non-sp-quote [ *text-char non-sp ]
sig-sep = [ quote [stuffing] ] "--" SP CRLF
quote-mark = ">"
quote = 1*quote-mark
stuffing = SP ; space-stuffed, added on generation if
; needed, deleted on reception
flow = SP ; space before CRLF indicates flowed line,
; if DelSp=yes, space was added on generation
; and is deleted on reception
non-sp-quote = < any character except NUL, CR, LF, SP, quote-mark >
non-sp = non-sp-quote / quote-mark
text-char = non-sp / SP
That is, a Format=Flowed message body consists of any number of
paragraphs and/or fixed lines and/or signature separator lines;
paragraphs need at least one flowed line and are terminated by a
fixed line; the fixed line terminating the paragraph is part of the
paragraph. (There are some exceptions to this described in the
text.)
Without at least one flowed line, there is a series of fixed lines,
each independent. There is no paragraph.
With at least one flowed line, there is a paragraph, and the received
lines can be reformed and flowed to fit the display window size.
This can only be done if the lines are part of a logical grouping,
the paragraph.
Note that the definitions of flowed-line and sig-sep are potentially
ambiguous: a signature separator line matches both, but is treated as
a signature separator line and not a flowed line.
7. Failure Modes
7.1. Trailing White Space Corruption
There are systems in existence which alter trailing whitespace on
messages which pass through them. Such systems may strip, or in
rarer cases, add trailing whitespace, in violation of RFC 2821 [SMTP]
Section 4.5.2.
Stripping trailing whitespace has the effect of converting flowed
lines to fixed lines, which results in a message no worse than if
Format=Flowed had not been used.
Adding trailing whitespace to a Format=Flowed message may result in a
malformed display or reply.
Since most systems which add trailing white space do so to create a
line which fills an internal record format, the result is almost
always a line which contains an even number of characters (counting
the added trailing white space).
One possible avoidance, therefore, would be to define Format=Flowed
lines to use either one or two trailing space characters to indicate
a flowed line, such that the total line length is odd. However,
considering the scarcity of such systems today, it is not worth the
added complexity.
8. Security Considerations
Any security considerations which apply to Text/Plain also apply to
Text/Plain with Format=Flowed.
Section 4.6 discusses the interaction between Format=Flowed and
digital signatures or encryption.
9. IANA Considerations
IANA has added a reference to this specification in the Text/Plain
Media Type registration.
10. Internationalization Considerations
The line wrap and quoting specifications of Format=Flowed may not be
suitable for certain charsets, such as for Arabic and Hebrew
characters that read from right to left. Care needs to be taken in
applying format=flowed in these cases, as format=fixed combined with
[quoted-printable] encoding may be more suitable.
The DelSp parameter was added specifically to permit Format=Flowed to
be used with languages/coded character sets in which the ASCII space
character is rarely used, or not used at all.
11. Acknowledgments
The DelSp parameter was developed during a series of discussions
among a number of people, including Harald Alvestrand, Grant Baillie,
Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed,
Alexey Melnikov, John Myers, and Pete Resnick.
Corrections and clarifications to RFC 2646 and early versions of this
document were pointed out by several people, including Adam Costello,
Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho
Mahalingam, Keith Moore, Greg Troxel, and Dan Wing.
I’m told that NeXT’s mail application used a very similar mechanism
(without support for non-Western languages) in 1992.
12. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234,
November 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part Two: Media
Types", RFC 2046, November 1996.
[Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, November
1996.
13. Informative References
[Annex-14] Unicode Standard Annex #14, "Line Breaking
Properties"
<URL:http://www.unicode.org/unicode/reports/tr14/>
[MSG-FMT] Resnick, P., Ed., "Internet Message Format", RFC
2822, April 2001.
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R.
Thayer, "OpenPGP Message Format", RFC 2440,
November 1998.
[OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good
Privacy (PGP)", RFC 2015, October 1996.
Elkins, M., Del Torto, D., Levien, R. and J.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
[Rich] Resnick, P. and A. Walker, "The text/enriched MIME
Content-type", RFC 1896, February 1996.
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
Appendix A: Changes from RFC 2646
Substantive:
o Added DelSp parameter to handle languages and coded character sets
in which space is less common or not used.
o Updated text on generating and interpreting to accommodate the
DelSp parameter.
o Changed the limits of 79 or 80 to be 78 in conformance with RFC
2822.
o Added text on generating to clarify that the 78-character limit
includes trailing white space and stuffing.
o Changed sig-sep in ABNF to allow stuffing.
o Changed fixed-line to allow empty lines in ABNF.
o Added explanatory text following ABNF.
o Moved text from Abstract to new Introduction; rewrote Abstract.
o Moved interoperability text to new section, and updated.
o Clarified Security Considerations.
o Text on digital signatures now discusses that OpenPGP ignores
trailing white space.
o Mention Unicode Annex 14.
o Added mention of quoting to Abstract and Introduction.
o Deleted line analysis table.
o Added recommendations for OpenPGP and OpenPGP-MIME.
o Rewrote ABNF rules to remove most ambiguity and note remaining
case.
o Added note that c-t-e is irrelevant to flowed text processing.
o Added text indicating that end of data terminates a paragraph.
o Moved sig-sep out of fixed-line ABNF.
o Changed some SHOULDs to MUSTs (space-stuffing, quoted paragraphs).
o Added note to ABNF that space and ">" are encoded according to
charset.
o Mentioned exceptions in section on interpreting.
o Clarified and made consistent treatment of signature separator
lines.
Editorial:
o Added mention of NeXT’s mail application to Acknowledgments.
o Updated Acknowledgments.
o Updated [SMTP] reference to 2821.
o Added Notices.
o Split References into Normative and Informative.
o Improved text wording in some areas.
o Standardize on "quote depth", not "quoting depth".
o Moved section on interpreting before section on generating.
o Reworded non-normative "should"s.
o Noted meaning of "paragraph".
The DelSp parameter was added specifically to permit Format=Flowed to
be used with languages/coded character sets in which the ASCII space
character is rarely used, or not used at all. The DelSp mechanism
was selected despite having been initially rejected as too much of a
kludge, because among the many different techniques proposed, it
allows for maximum interoperability among clients which support
neither this specification nor RFC 2646, those which do support RFC
2646 but not this specification, and those that do support this
specification; this set is multiplied by those that handle
languages/coded character sets in which spaces are common, and in
which they are uncommon or not used.
Author’s Address
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
USA
Phone: +1 858 651 5115
EMail: randy@qualcomm.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.