1124 lines
41 KiB
Plaintext
1124 lines
41 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group R. Gellens
|
||
Request for Comments: 3676 Qualcomm
|
||
Obsoletes: 2646 February 2004
|
||
Category: Standards Track
|
||
|
||
|
||
The Text/Plain Format and DelSp Parameters
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This specification establishes two parameters (Format and DelSP) to
|
||
be used with the Text/Plain media type. In the presence of these
|
||
parameters, trailing whitespace is used to indicate flowed lines and
|
||
a canonical quote indicator is used to indicate quoted lines. This
|
||
results in an encoding which appears as normal Text/Plain in older
|
||
implementations, since it is in fact normal Text/Plain, yet provides
|
||
for superior wrapping/flowing, and quoting.
|
||
|
||
This document supersedes the one specified in RFC 2646, "The
|
||
Text/Plain Format Parameter", and adds the DelSp parameter to
|
||
accommodate languages/coded character sets in which ASCII spaces are
|
||
not used or appear rarely.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
|
||
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
|
||
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
|
||
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
|
||
4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
|
||
4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
|
||
4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
|
||
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
|
||
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 9
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 1]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||
4.6. Digital Signatures and Encryption . . . . . . . . . . . 11
|
||
4.7. Examples. . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
5. Interoperability. . . . . . . . . . . . . . . . . . . . . . . 12
|
||
6. ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||
7.1. Trailing White Space Corruption . . . . . . . . . . . . 14
|
||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
|
||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
|
||
10. Internationalization Considerations . . . . . . . . . . . . . 15
|
||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
|
||
12. Normative References. . . . . . . . . . . . . . . . . . . . . 16
|
||
13. Informative References. . . . . . . . . . . . . . . . . . . . 16
|
||
Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . . . 18
|
||
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 20
|
||
|
||
1. Introduction
|
||
|
||
Interoperability problems have been observed with erroneous labelling
|
||
of paragraph text as Text/Plain, and with various forms of
|
||
"embarrassing line wrap". (See Section 3.)
|
||
|
||
Attempts to deploy new media types, such as Text/Enriched [Rich] and
|
||
Text/HTML [HTML] have suffered from a lack of backwards compatibility
|
||
and an often hostile user reaction at the receiving end.
|
||
|
||
What is required is a format which is in all significant ways
|
||
Text/Plain, and therefore is quite suitable for display as
|
||
Text/Plain, and yet allows the sender to express to the receiver
|
||
which lines are quoted and which lines are considered a logical
|
||
paragraph, and thus eligible to be flowed (wrapped and joined) as
|
||
appropriate.
|
||
|
||
2. Conventions Used in this Document
|
||
|
||
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
|
||
and "MAY" in this document are to be interpreted as described in "Key
|
||
words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
|
||
|
||
The term "paragraph" is used here to mean a series of lines which are
|
||
logically to be treated as a unit for display purposes and eligible
|
||
to be flowed (wrapped and joined) as appropriate to fit in the
|
||
display window and when creating text for replies, forwarding, etc.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 2]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
3. The Problem
|
||
|
||
The Text/Plain media type is the lowest common denominator of
|
||
Internet email, with lines of no more than 998 characters (by
|
||
convention usually no more than 78), and where the carriage-return
|
||
and line-feed (CRLF) sequence represents a line break (see [MIME-IMT]
|
||
and [MSG-FMT]).
|
||
|
||
Text/Plain is usually displayed as preformatted text, often in a
|
||
fixed font. That is, the characters start at the left margin of the
|
||
display window, and advance to the right until a CRLF sequence is
|
||
seen, at which point a new line is started, again at the left margin.
|
||
When a line length exceeds the display window, some clients will wrap
|
||
the line, while others invoke a horizontal scroll bar.
|
||
|
||
Text which meets this description is defined by this memo as "fixed".
|
||
|
||
Some interoperability problems have been observed with this format:
|
||
|
||
3.1. Paragraph Text
|
||
|
||
Many modern programs use a proportional-spaced font, and use CRLF to
|
||
represent paragraph breaks. Line breaks are "soft", occurring as
|
||
needed on display. That is, characters are grouped into a paragraph
|
||
until a CRLF sequence is seen, at which point a new paragraph is
|
||
started. Each paragraph is displayed, starting at the left margin
|
||
(or paragraph indent), and continuing to the right until a word is
|
||
encountered which does not fit in the remaining display width. This
|
||
word is displayed at the left margin of the next line. This
|
||
continues until the paragraph ends (a CRLF is seen). Extra vertical
|
||
space is left between paragraphs.
|
||
|
||
Text which meets this description is defined by this memo as
|
||
"flowed".
|
||
|
||
Numerous software products erroneously label this format as
|
||
Text/Plain, resulting in much user discomfort.
|
||
|
||
3.2. Embarrassing Line Wrap
|
||
|
||
As Text/Plain messages are quoted in replies or forwarded messages,
|
||
each line gradually increases in length, eventually being arbitrarily
|
||
hard wrapped, resulting in "embarrassing line wrap". This produces
|
||
text which is, at best, hard to read, and often confuses
|
||
attributions.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 3]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
Example:
|
||
|
||
>>>>>>This is a comment from the first message to show a
|
||
>quoting example.
|
||
>>>>>This is a comment from the second message to show a
|
||
>quoting example.
|
||
>>>>This is a comment from the third message.
|
||
>>>This is a comment from the fourth message.
|
||
|
||
It can be confusing to assign attribution to lines 2 and 4 above.
|
||
|
||
In addition, as devices with display widths smaller than 79 or 80
|
||
characters become more popular, embarrassing line wrap has become
|
||
even more prevalent, even with unquoted text.
|
||
|
||
Example:
|
||
|
||
This is paragraph text that is
|
||
meant to be flowed across
|
||
several lines.
|
||
However, the sending mailer is
|
||
converting it to fixed text at
|
||
a width of 72
|
||
characters, which causes it to
|
||
look like this when shown on a
|
||
PDA with only
|
||
30 character lines.
|
||
|
||
3.3. New Media Types
|
||
|
||
Attempts to deploy new media types, such as Text/Enriched [Rich] and
|
||
Text/HTML [HTML] have suffered from a lack of backwards compatibility
|
||
and an often hostile user reaction at the receiving end.
|
||
|
||
In particular, Text/Enriched requires that open angle brackets ("<")
|
||
and hard line breaks be doubled, with resulting user unhappiness when
|
||
viewed as Text/Plain. Text/HTML requires even more alteration of
|
||
text, with a corresponding increase in user complaints.
|
||
|
||
A proposal to define a new media type to explicitly represent the
|
||
paragraph form suffered from a lack of interoperability with
|
||
currently deployed software. Some programs treat unknown subtypes of
|
||
TEXT as an attachment.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 4]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
What is desired is a format which is in all significant ways
|
||
Text/Plain, and therefore is quite suitable for display as
|
||
Text/Plain, and yet allows the sender to express to the receiver
|
||
which lines can be considered a logical paragraph, and thus flowed
|
||
(wrapped and joined) as appropriate.
|
||
|
||
4. The Format and DelSp Parameters
|
||
|
||
This specification defines two MIME parameters for use with
|
||
Text/Plain:
|
||
|
||
Name: Format
|
||
Value: Fixed, Flowed
|
||
|
||
Name: DelSp
|
||
Value: Yes, No
|
||
|
||
(Neither the parameter names nor values are case sensitive.)
|
||
|
||
If Format is not specified, or if the value is not recognized, a
|
||
value of Fixed is assumed. The semantics of the Fixed value are the
|
||
usual associated with Text/Plain [MIME-IMT].
|
||
|
||
A Format value of Flowed indicates that the definition of flowed text
|
||
(as specified in this memo) was used on generation, and MAY be used
|
||
on reception.
|
||
|
||
Note that because Format is a parameter of the Text/Plain content-
|
||
type, any content-transfer-encoding used is irrelevant to the
|
||
processing of flowed text.
|
||
|
||
If DelSp is not specified, or if its value is not recognized, a value
|
||
of No is assumed. The use of DelSp without a Format value of Flowed
|
||
is undefined. When creating messages, DelSp SHOULD NOT be specified
|
||
in Text content types other than Text/Plain with Format = Flowed.
|
||
When receiving messages, DelSp SHOULD be ignored if used in a Text
|
||
content type other than Text/Plain with Format = Flowed.
|
||
|
||
This section discusses flowed text; section 6 provides a formal
|
||
definition.
|
||
|
||
Section 5 discusses interoperability.
|
||
|
||
Note that this memo describes an on-the-wire format. It does not
|
||
address formats for local file storage.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 5]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
4.1. Interpreting Format=Flowed
|
||
|
||
If the first character of a line is a quote mark (">"), the line is
|
||
considered to be quoted (see Section 4.5). Logically, all quote
|
||
marks are counted and deleted, resulting in a line with a non-zero
|
||
quote depth, and content. (The agent is of course free to display
|
||
the content with quote marks or excerpt bars or anything else.)
|
||
Logically, this test for quoted lines is done before any other tests
|
||
(that is, before checking for space-stuffed and flowed).
|
||
|
||
If the first character of a line is a space, the line has been
|
||
space-stuffed (see Section 4.4). Logically, this leading space is
|
||
deleted before examining the line further (that is, before checking
|
||
for flowed).
|
||
|
||
If the line ends in a space, the line is flowed. Otherwise it is
|
||
fixed. The exception to this rule is a signature separator line,
|
||
described in Section 4.3. Such lines end in a space but are neither
|
||
flowed nor fixed.
|
||
|
||
If the line is flowed and DelSp is "yes", the trailing space
|
||
immediately prior to the line's CRLF is logically deleted. If the
|
||
DelSp parameter is "no" (or not specified, or set to an unrecognized
|
||
value), the trailing space is not deleted.
|
||
|
||
Any remaining trailing spaces are part of the line's content, but the
|
||
CRLF of a soft line break is not.
|
||
|
||
A series of one or more flowed lines followed by one fixed line is
|
||
considered a paragraph, and MAY be flowed (wrapped and unwrapped) as
|
||
appropriate on display and in the construction of new messages (see
|
||
Section 4.5).
|
||
|
||
An interpreting agent SHOULD allow for three exceptions to the rule
|
||
that paragraphs end with a fixed line. These exceptions are
|
||
improperly constructed messages: a flowed line SHOULD be considered
|
||
to end the paragraph if it is followed by a line of a different quote
|
||
depth (see 4.5) or by a signature separator (see 4.3); the end of the
|
||
body also ends the paragraph.
|
||
|
||
A line consisting of one or more spaces (after deleting a space
|
||
acting as stuffing) is considered a flowed line.
|
||
|
||
An empty line (just a CRLF) is a fixed line.
|
||
|
||
Note that, for Unicode text, [Annex-14] provides guidance for
|
||
choosing at which characters to wrap a line.
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 6]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
4.2. Generating Format=Flowed
|
||
|
||
When generating Format=Flowed text, lines SHOULD be 78 characters or
|
||
shorter, including any trailing white space and also including any
|
||
space added as part of stuffing (see Section 4.4). As suggested
|
||
values, any paragraph longer than 78 characters in total length could
|
||
be wrapped using lines of 72 or fewer characters. While the specific
|
||
line length used is a matter of aesthetics and preference, longer
|
||
lines are more likely to require rewrapping and to encounter
|
||
difficulties with older mailers. (It has been suggested that 66
|
||
character lines are the most readable.)
|
||
|
||
The restriction to 78 or fewer characters between CRLFs on the wire
|
||
is to conform to [MSG-FMT].
|
||
|
||
(In addition to conformance to [MSG-FMT], there is a historical need
|
||
that all lines, even when displayed by a non-flowed-aware program,
|
||
will fit in a standard 79- or 80-column screen without having to be
|
||
wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit
|
||
on a line, the last column is often reserved for a line-wrap
|
||
indicator.)
|
||
|
||
When creating flowed text, the generating agent wraps, that is,
|
||
inserts 'soft' line breaks as needed. Soft line breaks are added at
|
||
natural wrapping points, such as between words. A soft line break is
|
||
a SP CRLF sequence.
|
||
|
||
There are two techniques for inserting soft line breaks. The older
|
||
technique, established by RFC 2646, creates a soft line break by
|
||
inserting a CRLF after the occurrence of a space. With this
|
||
technique, soft line breaks are only possible where spaces already
|
||
occur. When this technique is used, the DelSp parameter SHOULD be
|
||
used; if used it MUST be set to "no".
|
||
|
||
The newer technique, suitable for use even with languages/coded
|
||
character sets in which the ASCII space character is rare or not
|
||
used, creates a soft line break by inserting a SP CRLF sequence.
|
||
When this technique is used, the DelSp parameter MUST be used and
|
||
MUST be set to "yes". Note that because of space-stuffing (see
|
||
Section 4.4), when this technique is used and a soft line break is
|
||
inserted at a point where a SP already exists (such as between
|
||
words), if the SP CRLF sequence is added immediately before the SP,
|
||
the pre-existing SP becomes leading and thus requires stuffing. It
|
||
is RECOMMENDED that agents avoid this by inserting the SP CRLF
|
||
sequence following the existing SP.
|
||
|
||
Generating agents MAY use either method within each Text/Plain body
|
||
part.
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 7]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
Regardless of which technique is used, a generating agent SHOULD NOT
|
||
insert a space in an unnatural location, such as into a word (a
|
||
sequence of printable characters, not containing spaces, in a
|
||
language/coded character set in which spaces are common). If faced
|
||
with such a word which exceeds 78 characters (but less than 998
|
||
characters, the [SMTP] limit on line length), the agent SHOULD send
|
||
the word as is and exceed the 78-character limit on line length.
|
||
|
||
A generating agent SHOULD:
|
||
|
||
o Ensure all lines (fixed and flowed) are 78 characters or fewer in
|
||
length, counting any trailing space as well as a space added as
|
||
stuffing, but not counting the CRLF, unless a word by itself
|
||
exceeds 78 characters.
|
||
|
||
o Trim spaces before user-inserted hard line breaks.
|
||
|
||
A generating agent MUST:
|
||
|
||
o Space-stuff lines which start with a space, "From ", or ">".
|
||
|
||
In order to create messages which do not require space-stuffing, and
|
||
are thus more aesthetically pleasing when viewed as Format=Fixed, a
|
||
generating agent MAY avoid wrapping immediately before ">", "From ",
|
||
or space.
|
||
|
||
(See Sections 4.4 and 4.5 for more information on space-stuffing and
|
||
quoting, respectively.)
|
||
|
||
A Format=Flowed message consists of zero or more paragraphs, each
|
||
containing one or more flowed lines followed by one fixed line. The
|
||
usual case is a series of flowed text lines with blank (empty) fixed
|
||
lines between them.
|
||
|
||
Any number of fixed lines can appear between paragraphs.
|
||
|
||
When placing soft line breaks in a paragraph, generating agents MUST
|
||
NOT place them in a way that causes any line of the paragraph to be a
|
||
signature separator line, because paragraphs cannot contain signature
|
||
separator lines (see Sections 4.3 and 6).
|
||
|
||
[Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed
|
||
unless absolutely necessary (for example, non-US-ASCII (8-bit)
|
||
characters over a strictly 7-bit transport such as unextended
|
||
[SMTP]). In particular, a message SHOULD NOT be encoded in Quoted-
|
||
Printable for the sole purpose of protecting the trailing space on
|
||
flowed lines unless the body part is cryptographically signed or
|
||
encrypted (see Section 4.6).
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 8]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
The intent of Format=Flowed is to allow user agents to generate
|
||
flowed text which is non-obnoxious when viewed as pure, raw
|
||
Text/Plain (without any decoding); use of Quoted-Printable hinders
|
||
this and may cause Format=Flowed to be rejected by end users.
|
||
|
||
4.3. Usenet Signature Convention
|
||
|
||
There is a long-standing convention in Usenet news which also
|
||
commonly appears in Internet mail of using "-- " as the separator
|
||
line between the body and the signature of a message. When
|
||
generating a Format=Flowed message containing a Usenet-style
|
||
separator before the signature, the separator line is sent as-is.
|
||
This is a special case; an (optionally quoted or quoted and stuffed)
|
||
line consisting of DASH DASH SP is neither fixed nor flowed.
|
||
|
||
Generating agents MUST NOT end a paragraph with such a signature
|
||
line.
|
||
|
||
A receiving agent needs to test for a signature line both before the
|
||
test for a quoted line (see Section 4.5) and also after logically
|
||
counting and deleting quote marks and stuffing (see Section 4.4) from
|
||
a quoted line.
|
||
|
||
4.4. Space-Stuffing
|
||
|
||
In order to allow for unquoted lines which start with ">", and to
|
||
protect against systems which "From-munge" in-transit messages
|
||
(modifying any line which starts with "From " to ">From "),
|
||
Format=Flowed provides for space-stuffing.
|
||
|
||
Space-stuffing adds a single space to the start of any line which
|
||
needs protection when the message is generated. On reception, if the
|
||
first character of a line is a space, it is logically deleted. This
|
||
occurs after the test for a quoted line (which logically counts and
|
||
deletes any quote marks), and before the test for a flowed line.
|
||
|
||
On generation, any unquoted lines which start with ">", and any lines
|
||
which start with a space or "From " MUST be space-stuffed. Other
|
||
lines MAY be space-stuffed as desired.
|
||
|
||
(Note that space-stuffing is conceptually similar to dot-stuffing as
|
||
specified in [SMTP].)
|
||
|
||
4.5. Quoting
|
||
|
||
In Format=Flowed, the canonical quote indicator (or quote mark) is
|
||
one or more close angle bracket (">") characters. Lines which start
|
||
with the quote indicator are considered quoted. The number of ">"
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 9]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
characters at the start of the line specifies the quote depth.
|
||
Flowed lines which are also quoted may require special handling on
|
||
display and when copied to new messages.
|
||
|
||
When creating quoted flowed lines, each such line starts with the
|
||
quote indicator.
|
||
|
||
Note that because of space-stuffing, the lines
|
||
>> Exit, Stage Left
|
||
and
|
||
>>Exit, Stage Left
|
||
are semantically identical; both have a quote-depth of two, and a
|
||
content of "Exit, Stage Left".
|
||
|
||
However, the line
|
||
> > Exit, Stage Left
|
||
is different. It has a quote-depth of one, and a content of
|
||
"> Exit, Stage Left".
|
||
|
||
When generating quoted flowed lines, an agent needs to pay attention
|
||
to changes in quote depth. All lines of a paragraph MUST be
|
||
unquoted, or else they MUST all be quoted and have the same quote
|
||
depth. Therefore, whenever there is a change in quote depth, or a
|
||
change from quoted to unquoted, or change from unquoted to quoted,
|
||
the line immediately preceding the change MUST NOT be a flowed line.
|
||
|
||
If a receiving agent wishes to reformat flowed quoted lines (joining
|
||
and/or wrapping them) on display or when generating new messages, the
|
||
lines SHOULD be de-quoted, reformatted, and then re-quoted. To de-
|
||
quote, the number of close angle brackets in the quote indicator at
|
||
the start of each line is counted. To re-quote after reformatting, a
|
||
quote indicator containing the same number of close angle brackets
|
||
originally present are prefixed to each line.
|
||
|
||
On reception, if a change in quote depth occurs on a flowed line,
|
||
this is an improperly formatted message. The receiver SHOULD handle
|
||
this error by using the 'quote-depth-wins' rule, which is to consider
|
||
the paragraph to end with the flowed line immediately preceding the
|
||
change in quote depth.
|
||
|
||
In other words, whenever two adjacent lines have different quote
|
||
depths, senders MUST ensure that the earlier line is not flowed (does
|
||
not end in a space), and receivers finding a flowed line there SHOULD
|
||
treat it as the last line of a paragraph.
|
||
|
||
For example, consider the following sequence of lines (using '*' to
|
||
indicate a soft line break, i.e., SP CRLF, and '#' to indicate a hard
|
||
line break, i.e., CRLF):
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 10]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
> Thou villainous ill-breeding spongy dizzy-eyed*
|
||
> reeky elf-skinned pigeon-egg!* <--- problem ---<
|
||
>> Thou artless swag-bellied milk-livered*
|
||
>> dismal-dreaming idle-headed scut!#
|
||
>>> Thou errant folly-fallen spleeny reeling-ripe*
|
||
>>> unmuzzled ratsbane!#
|
||
>>>> Henceforth, the coding style is to be strictly*
|
||
>>>> enforced, including the use of only upper case.#
|
||
>>>>> I've noticed a lack of adherence to the coding*
|
||
>>>>> styles, of late.#
|
||
>>>>>> Any complaints?#
|
||
|
||
The second line ends in a soft line break, even though it is the last
|
||
line of the one-deep quote block. The question then arises as to how
|
||
this line is to be interpreted, considering that the next line is the
|
||
first line of the two-deep quote block.
|
||
|
||
The example text above, when processed according to quote-depth wins,
|
||
results in the first two lines being considered as one quoted, flowed
|
||
section, with a quote depth of 1; the third and fourth lines become a
|
||
quoted, flowed section, with a quote depth of 2.
|
||
|
||
A generating agent MUST NOT create this situation; a receiving agent
|
||
SHOULD handle it by giving preference to the quote depth.
|
||
|
||
4.6. Digital Signatures and Encryption
|
||
|
||
If a message is digitally signed or encrypted it is important that
|
||
cryptographic processing use the same text for signature verification
|
||
and/or decryption as was used for signature generation and/or
|
||
encryption. Since the use of format=flowed allows text to be altered
|
||
(by adding or removing line breaks and trailing spaces) between
|
||
composition and transmission, and between reception and display,
|
||
interoperability problems or security vulnerabilities may arise if
|
||
originator and recipient do not both use the on-the-wire format for
|
||
cryptographic processing.
|
||
|
||
The implications of the interaction between format=flowed and any
|
||
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."
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 11]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 12]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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 ) /
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 13]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 14]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 15]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 16]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
[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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 17]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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".
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 18]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 19]
|
||
|
||
RFC 3676 Text/Plain Format and DelSp Parameters February 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gellens Standards Track [Page 20]
|
||
|