ietf-corpus

rfc-2646

The Text/Plain Format Parameter

R. Gellens (Editor)
date1999-08 streamLegacy statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc2646 doi10.17487/RFC2646
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]

obsoleted by

updates

Extracted elements (24)

design-rationale §6.1

A proposal to define odd total line length (using one or two trailing spaces) as an anti-corruption measure was rejected because systems that add trailing whitespace are sufficiently rare today that the added complexity is not warranted.

email

design-rationale §4.4

Space-stuffing was chosen (analogous to SMTP dot-stuffing) rather than defining a new media type subtype, because some programs treat unknown Text subtypes as attachments, creating interoperability problems.

email

design-rationale §4.1

The line-length limit is 79, not 80, because while 80 characters fit on a standard screen, the last column is often reserved for a line-wrap indicator. Staying at 79 ensures non-flowed-aware displays do not need to wrap.

email

design-rationale §3.3

Trailing whitespace was chosen as the flowed-line indicator because it makes Format=Flowed messages appear as normal Text/Plain to legacy clients, avoiding the backwards-compatibility failures seen with Text/Enriched and Text/HTML deployments.

email

interoperability-note §6.1

Systems that strip trailing whitespace convert flowed lines to fixed lines, resulting in a message no worse than if Format=Flowed had not been used. Systems that add trailing whitespace may cause malformed display or replies.

email

interoperability-note §9

The line wrap and quoting specifications of Format=Flowed may not be suitable for right-to-left charsets such as Arabic and Hebrew. Format=Fixed combined with Quoted-Printable encoding may be more suitable for those cases.

email

interoperability-note §4.3

The Usenet signature separator '-- ' (DASH DASH SP) is a special case: an optionally quoted line consisting of exactly DASH DASH SP is not considered a flowed line, even though it ends in a space.

email

normative-requirement §4.1 SHOULD

A generating agent SHOULD: (1) ensure all lines are 79 characters or fewer; (2) trim spaces before user-inserted hard line breaks; (3) space-stuff lines starting with a space, 'From ', or '>'.

email

normative-requirement §4.1 SHOULD NOT

A generating agent SHOULD NOT insert white space into a word (a sequence of printable characters without spaces). If a word exceeds 79 characters (but is less than 998), the agent SHOULD send it as-is, exceeding the line-length limit.

email

normative-requirement §4.5 SHOULD

A sequence of quoted lines of the same quote depth SHOULD be encoded as a paragraph. If a receiving agent reformats quoted flowed lines, the lines SHOULD be de-quoted, reformatted, and then re-quoted using the original quote depth.

email

normative-requirement §4.5 SHOULD

If a change in quoting depth occurs on a flowed line, this is an improperly formatted message. The receiver SHOULD handle this using the 'quote-depth-wins' rule: ignore the flowed indicator and treat the line as fixed, ending the paragraph.

email

normative-requirement §4.6 SHOULD

If a message is digitally signed or encrypted, the message SHOULD be prepared for transmission (including soft line breaks, space-stuffing, and QP encoding) before signing or encrypting. On receipt, signature verification or decryption SHOULD occur before QP decoding and removal of flowed formatting.

email, crypto, security

normative-requirement §4.4 SHOULD

On generation, unquoted lines starting with '>' and any lines starting with a space or 'From ' SHOULD be space-stuffed. Other lines MAY be space-stuffed as desired.

email

normative-requirement §4.1 SHOULD NOT

Quoted-Printable encoding SHOULD NOT be used with Format=Flowed unless absolutely necessary (e.g., non-US-ASCII over strictly 7-bit transport). A message SHOULD NOT be QP-encoded solely to protect trailing spaces, unless the body is cryptographically signed or encrypted.

email

normative-requirement §4.1 SHOULD

When generating Format=Flowed text, lines SHOULD be shorter than 80 characters (counting the trailing space but not the CRLF). Lines of 72 or fewer characters are suggested for paragraphs longer than 79 characters total.

email

protocol-element §4.2

A 'flowed' line ends in one or more space characters; a 'fixed' line does not. 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 constitutes a paragraph.

email

protocol-element §4

Defines a new MIME parameter 'Format' for use with Text/Plain, with values 'Fixed' (default) and 'Flowed'. Neither the parameter name nor value is case-sensitive. If not specified, Fixed is assumed.

email

protocol-element §4.7

Lines are classified by a two-dimensional table: (starts with quote, ends with spaces) → (unquoted fixed, quoted fixed, unquoted flowed, quoted flowed). Processing order: quote test first, then space-stuffing test, then flowed test.

email

protocol-element §4.4

Space-stuffing adds a single leading space to any line that starts with '>', a space, or 'From ' when the message is generated. On reception, if the first character of a line is a space, it is logically deleted before the flowed test.

email

protocol-element §4.5

The canonical quote indicator is one or more '>' characters at the start of a line. The count of '>' characters specifies the quote depth. Logically, all quote marks are counted and deleted before further processing.

email

registry §8

IANA is requested to add a reference to RFC 2646 in the Text/Plain Media Type registration, reflecting the new 'Format' parameter with values 'Fixed' and 'Flowed'.

email, registry

security-consideration §7

The Format parameter introduces no security considerations beyond those applicable to Text/Plain. The interaction between Format=Flowed and digital signatures or encryption is discussed in section 4.6, requiring that cryptographic processing operate on the on-wire formatted content.

email, security, crypto

wire-format §4.1

A soft line break is encoded as SP CRLF (a trailing space followed by CRLF). A hard line break is encoded as bare CRLF. The trailing space signals that the line is flowed and may be joined with the next.

email

wire-format §5

The ABNF grammar defines: paragraph = 1*flowed-line fixed-line; fixed = [quote] [stuffing] *text-char non-sp CRLF; flowed lines are flow-qt or flow-unqt, each ending in 1*SP CRLF; sig-sep = [quote] "--" SP CRLF; stuffing = [SP].

email