RFC 3676
The Text/Plain Format and DelSp Parameters
Hiii, RFC 3676 is here 🎀
Okay bestie, so this one is RFC 3676: The Text/Plain Format and DelSp Parameters 🌸 It came out of the Network Working Group, written by R. Gellens at Qualcomm, and it's dated February 2004. It's a Standards Track doc 💅 and it obsoletes RFC 2646, so if you were reading that one, this is the glow-up version ✨
Status of this Memo
Okay so this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 💖
Abstract
So this spec sets up two parameters, Format and DelSP, to go with the Text/Plain media type 🧚 When they're present, trailing whitespace marks flowed lines, and a canonical quote indicator marks quoted lines. Older implementations just see normal Text/Plain, because it is normal Text/Plain, but you still get 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
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. . . . . . . . . . . . . . . . . . . . . 201. Introduction ✨
Okay so there have been interoperability problems with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap" 😭 (See Section 3.)
Trying to roll out new media types like Text/Enriched [Rich] and Text/HTML [HTML] has struggled with a lack of backwards compatibility and a pretty hostile reaction from users on the receiving end 💀
What we actually need is a format that's in all significant ways Text/Plain, so it's totally fine to display as Text/Plain, but that also lets the sender tell the receiver which lines are quoted and which lines count as a logical paragraph, so they can be flowed (wrapped and joined) when 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" here means a series of lines that get treated as one unit for display purposes, and that can be flowed (wrapped and joined) to fit the display window, and also when making text for replies, forwarding, etc. 🌸
3. The Problem 💅
The Text/Plain media type is the lowest common denominator of Internet email 📧 Lines can be no more than 998 characters (by convention usually no more than 78), and the carriage-return and line-feed (CRLF) sequence is what marks a line break (see [MIME-IMT] and [MSG-FMT]).
Text/Plain is usually displayed as preformatted text, often in a fixed font. The characters start at the left margin of the display window and move to the right until a CRLF sequence shows up, and then a new line starts back at the left margin. When a line is longer than the display window, some clients wrap it, while others use a horizontal scroll bar 🙈
Text that matches this description is called "fixed" in this memo 🧚
Some interoperability problems have been observed with this format:
3.1. Paragraph Text 🍓
Lots of modern programs use a proportional-spaced font, and they use CRLF to mark paragraph breaks. Line breaks are "soft", happening as needed on display. Characters get grouped into a paragraph until a CRLF sequence appears, and then a new paragraph starts. Each paragraph is displayed starting at the left margin (or paragraph indent), and it keeps going to the right until a word shows up that doesn't fit in the remaining display width. That word is displayed at the left margin of the next line, and this continues until the paragraph ends (a CRLF is seen). Extra vertical space gets left between paragraphs 🫶
Text that matches this description is called "flowed" in this memo 🌈
Lots of software products wrongly label this format as Text/Plain, which causes a ton of user discomfort 😭
3.2. Embarrassing Line Wrap 💀
When Text/Plain messages get quoted in replies or forwarded messages, each line keeps getting longer, and eventually lines get arbitrarily hard wrapped. That's the "embarrassing line wrap" 😩 At best it's hard to read, and it often messes up attributions.
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 figure out who said lines 2 and 4 above 🙈
Also, as devices with display widths smaller than 79 or 80 characters get more popular, embarrassing line wrap is showing up even more, 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 🦋
Trying to deploy new media types like Text/Enriched [Rich] and Text/HTML [HTML] has run into a lack of backwards compatibility and a pretty hostile reaction from users on the receiving end.
Specifically, Text/Enriched needs open angle brackets ("<") and hard line breaks to be doubled, which makes users unhappy when they view it as Text/Plain 😭 Text/HTML needs even more text changes, and the complaints go up right along with that 💅
A proposal to define a new media type that explicitly represents the paragraph form didn't work out either, because it lacked interoperability with software that's already out there. Some programs treat unknown subtypes of TEXT as an attachment 🙃
What we actually want is a format that's in all significant ways Text/Plain, so it's totally fine to display as Text/Plain, but that also lets the sender tell the receiver which lines can be treated as a logical paragraph, and so can be flowed (wrapped and joined) when appropriate 🌸
4. The Format and DelSp Parameters ✨
This spec defines two MIME parameters to use with Text/Plain 🎀
Name: Format
Value: Fixed, Flowed
Name: DelSp
Value: Yes, No(Neither the parameter names nor the values are case sensitive.)
If Format isn't specified, or if its value isn't recognized, a value of Fixed is assumed. The semantics of the Fixed value are the usual ones associated with Text/Plain [MIME-IMT] 💅
A Format value of Flowed says the definition of flowed text (as specified in this memo) was used on generation, and it MAY be used on reception 🧚
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 isn't specified, or if its value isn't recognized, a value of No is assumed. Using 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 it's used in a Text content type other than Text/Plain with Format = Flowed 👑
This section talks about flowed text, and section 6 has the formal definition 🌈
Section 5 covers interoperability 🦋
Note that this memo describes an on-the-wire format. It doesn't address formats for local file storage 💖
4.1. Interpreting Format=Flowed 💖
okay so, if the first character of a line is a quote mark (>), the line counts as quoted (see Section 4.5) 🎀. Logically, you count and delete all the quote marks, which leaves you with a line that has a non-zero quote depth and some content. (The agent is totally free to show the content with quote marks, excerpt bars, or whatever else it wants 💅.) This quoted-line check happens before any other test, meaning before you check for space-stuffed or flowed 🧚.
If the first character of a line is a space, the line has been space-stuffed (see Section 4.4) 🦋. Logically, you delete that leading space before you look at the line any further, so before you check for flowed 🌸.
If the line ends in a space, it's flowed. Otherwise it's fixed. The one exception is a signature separator line, which is described in Section 4.3 🫶. Those lines end in a space but are neither flowed nor fixed, so they're a special little case ✨.
If the line is flowed and DelSp is "yes", the trailing space right before the line's CRLF gets logically deleted 🍓. If the DelSp parameter is "no" (or it isn't specified, or it's set to a value nobody recognizes 🙈), the trailing space stays put.
Any leftover trailing spaces are part of the line's content, but the CRLF of a soft line break is not 💜.
A run of one or more flowed lines followed by one fixed line counts as a paragraph, and it MAY be flowed (wrapped and unwrapped) as appropriate when displaying it and when building 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 for improperly constructed messages 💀. A flowed line SHOULD be treated as ending the paragraph if the next line has a different quote depth (see 4.5) or if the next line is a signature separator (see 4.3) 🔥. And the end of the body also ends the paragraph 🎀.
A line made of one or more spaces (after you delete a space acting as stuffing) counts as a flowed line 🦋.
An empty line (just a CRLF) is a fixed line 🌸.
Also, for Unicode text, [Annex-14] has guidance on which characters you can wrap a line at 🧚.
4.2. Generating Format=Flowed 🎀
When you're generating Format=Flowed text, lines SHOULD be 78 characters or shorter 💅. That count includes any trailing whitespace and any space added as part of stuffing (see Section 4.4) ✨. As suggested values, any paragraph longer than 78 characters in total could be wrapped using lines of 72 or fewer characters 🦋. The exact line length is a matter of aesthetics and preference, but longer lines are more likely to need rewrapping and to run into trouble with older mailers 😭. (Someone has suggested that 66 character lines are the most readable 📖.)
The limit of 78 or fewer characters between CRLFs on the wire is there to conform to [MSG-FMT] 🫶.
(On top of conforming to [MSG-FMT], there's a historical need for all lines, even when a program that doesn't understand flowed text displays them, to fit on a standard 79- or 80-column screen without needing to be wrapped 🖥️. The limit is 78 and not 79 or 80, because even though 79 or 80 would technically fit, the last column is often saved for a line-wrap indicator 💖.)
When you're creating flowed text, the generating agent wraps the text, which means it inserts "soft" line breaks wherever they're needed 🌸. Soft line breaks go at natural wrapping points, like between words 🧚. A soft line break is a SP CRLF sequence 💜.
There are two techniques for inserting soft line breaks 🍓. The older one, established by RFC 2646, creates a soft line break by inserting a CRLF right after a space 🦋. With this technique, soft line breaks are only possible where spaces already exist 🙈. When you use this technique, the DelSp parameter SHOULD be used, and if it is used, it MUST be set to "no" 🔥.
The newer technique is suitable even for languages and coded character sets where the ASCII space character is rare or not used at all 🌈. It creates a soft line break by inserting a SP CRLF sequence ✨. When you use this technique, the DelSp parameter MUST be used, and MUST be set to "yes" 👑. Heads up: because of space-stuffing (see Section 4.4), if you use this technique and insert a soft line break at a spot where a SP already exists (like between words), and you add the SP CRLF sequence immediately before that SP, the pre-existing SP becomes leading and therefore needs stuffing 😭. It is RECOMMENDED that agents avoid this by inserting the SP CRLF sequence after the existing SP 🫶.
Generating agents MAY use either method within each Text/Plain body part 💅.
No matter which technique you use, a generating agent SHOULD NOT insert a space somewhere unnatural, like into a word (a sequence of printable characters with no spaces in it, in a language or coded character set where spaces are common) 🙅♀️. If you run into a word like that which is longer than 78 characters (but under 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as-is and go past the 78-character limit 🎀.
A generating agent SHOULD:
- Make sure all lines (fixed and flowed) are 78 characters or fewer, counting any trailing space and any space added as stuffing, but not counting the CRLF, unless a single word on its own is longer than 78 characters 💖.
- Trim spaces before user-inserted hard line breaks ✨.
A generating agent MUST:
- Space-stuff lines that start with a space,
"From ", or">"😭.
If you want messages that don't need space-stuffing, which look nicer when viewed as Format=Fixed, a generating agent MAY avoid wrapping right before ">", "From ", or a space 🌸.
(See Sections 4.4 and 4.5 for more on space-stuffing and quoting, respectively 🧚.)
A Format=Flowed message is made of zero or more paragraphs, and each one has one or more flowed lines followed by one fixed line 🦋. The usual setup is a series of flowed text lines with blank (empty) fixed lines between them 💜.
Any number of fixed lines can show up between paragraphs 🌈.
When you're placing soft line breaks in a paragraph, generating agents MUST NOT put them in a spot that makes any line of the paragraph a signature separator line, because paragraphs can't contain signature separator lines (see Sections 4.3 and 6) 🚫.
[Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed unless it's absolutely necessary, like for 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 just to protect the trailing space on flowed lines, unless the body part is cryptographically signed or encrypted (see Section 4.6) 🔐.
The whole point of Format=Flowed is to let user agents generate flowed text that's not obnoxious when you look at it as pure, raw Text/Plain (without decoding it) ✨. Quoted-Printable gets in the way of that and can make end users reject Format=Flowed altogether 😭💅.
4.3. Usenet Signature Convention 👑
There's a long-standing Usenet news convention, which also shows up a lot in Internet mail, of using "-- " as the separator line between the body and the signature of a message 🎀. When you generate a Format=Flowed message that has 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 made of DASH DASH SP is neither fixed nor flowed 🫶.
Generating agents MUST NOT end a paragraph with a signature line like that 🙅♀️.
A receiving agent needs to check for a signature line both before the quoted-line test (see Section 4.5), and also after it logically counts and deletes the quote marks and stuffing (see Section 4.4) from a quoted line 🧚.
4.4. Space-Stuffing 🌸
To allow for unquoted lines that start with ">", and to protect against systems that "From-munge" messages in transit (changing any line that starts with "From " to ">From "), Format=Flowed provides for space-stuffing 💖.
Space-stuffing adds a single space to the start of any line that needs protection when the message is generated 🦋. On reception, if the first character of a line is a space, it gets logically deleted ✨. This happens after the quoted-line test (which logically counts and deletes any quote marks) and before the flowed-line test 🌈.
When generating, any unquoted lines that start with ">", and any lines that start with a space or "From ", MUST be space-stuffed 😭. Other lines MAY be space-stuffed if you want 💜.
(Note that space-stuffing is conceptually similar to dot-stuffing as specified in [SMTP] 🧚.)
4.5. Quoting 🎀
okay so in Format=Flowed, the canonical quote indicator (aka the quote mark) is one or more close angle brackets (>). Any line that starts with the quote indicator counts as quoted, and the number of > characters at the start tells you the quote depth. Flowed lines that are also quoted can need extra handling when they're displayed or copied into new messages 💅
When you make quoted flowed lines, every single one starts with the quote indicator ✨
Quick vibe check on space-stuffing: these two lines are semantically identical 🙈
>> Exit, Stage Left>>Exit, Stage LeftBoth have a quote-depth of two and the content "Exit, Stage Left". But this one is a different beast 💀
> > Exit, Stage LeftThat one has a quote-depth of one, and its content is "> Exit, Stage Left".
Now, when a generating agent is making quoted flowed lines, it has to watch out for 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. So whenever the quote depth changes, or the line goes from quoted to unquoted, or from unquoted to quoted, the line right before that change MUST NOT be a flowed line. No exceptions, periodt 💖
If a receiving agent wants to reformat flowed quoted lines (joining them and/or wrapping them) when displaying them or making new messages, it SHOULD de-quote them, reformat, and then re-quote. To de-quote, you count the close angle brackets in the quote indicator at the start of each line. To re-quote after reformatting, you put a quote indicator with that same number of close angle brackets in front of each line 🦋
On reception, if the quote depth changes on a flowed line, that's an improperly formatted message 😭 The receiver SHOULD handle this with the 'quote-depth-wins' rule, which means treating the paragraph as ending with the flowed line right before the change in quote depth.
Basically, whenever two adjacent lines have different quote depths, senders MUST make sure the earlier line is not flowed (it does not end in a space), and receivers that find a flowed line there SHOULD treat it as the last line of a paragraph 🌸
Here's an example, where * means a soft line break (SP CRLF) and # means a hard line break (CRLF):
> 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's the last line of the one-deep quote block. So what happens next, when the next line starts the two-deep quote block? 🤔
If you process that example with quote-depth wins, the first two lines become 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 deal with it by going with the quote depth 💅
4.6. Digital Signatures and Encryption 🔐
If a message is digitally signed or encrypted, it's super important that the cryptographic processing works on the same text that was used when the signature was generated or the message was encrypted. Format=flowed lets text get changed (by adding or removing line breaks and trailing spaces) between composing and sending, and between receiving and displaying. So if the originator and the recipient don't both use the on-the-wire format for the cryptographic processing, you can run into interoperability problems or security vulnerabilities 😬
How format=flowed interacts with a given cryptographic process depends on the details of that process, so you should understand those details before using format=flowed with signed and/or encrypted messages.
Here's the tea. [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." So it would be possible to add a format=flowed header to a regular, format=fixed vanilla PGP (not [OpenPGP-MIME]) signed message in transit, and add arbitrary trailing space characters, and nobody would notice. That would change how a client that supports format=flowed renders the message 🫣
So the use of [OpenPGP] with format=flowed messages is strongly discouraged. [OpenPGP-MIME] is recommended instead 🫶
4.7. Examples 🧚
The following example has 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 like so (using * for a soft line break, that is, the SP CRLF sequence, and # for 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 quoting, here's the same exchange 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 🌈
Flowed lines are basically indistinguishable from fixed lines, so software that doesn't recognize Format=Flowed treats flowed lines as normal Text/Plain (which, honestly, is what they are). So Format=Flowed works with older clients, although flowed lines will have trailing white space inserted ✨
If a space-stuffed message gets received by an agent that handles Format=Flowed, the space-stuffing gets reversed, so the message looks unchanged. An agent that doesn't know about Format=Flowed won't undo any space-stuffing, so Format=Flowed messages might show up with a leading space on some lines (the ones that start with a space, with a ">" that isn't a quote indicator, or with "From "). Since lines that need space-stuffing hardly ever happen, and the aesthetic damage from leftover space-stuffing is minimal, this isn't expected to be a big deal 🙈
If some lines begin with one or more spaces, the generating agent MAY space-stuff all lines, so the relative indentation still looks right in clients that don't know about Format=Flowed 🌸
Messages generated with DelSp=yes and received by clients that are aware of Format=Flowed but NOT aware of the DelSp parameter will have an extra space left over after soft line breaks are removed. So when you're generating text in languages or coded character sets where spaces are common, the generating agent MAY always use the DelSp=no method.
Hand-aligned text, like ASCII tables or art, source code, and so on, SHOULD be sent as fixed lines, not flowed lines 💅
Wait, quick correction: the last sentence there is a SHOULD in the original, so I'm keeping it as the requirement above. Hand-aligned text 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 / SPSo a Format=Flowed message body is any number of paragraphs and/or fixed lines and/or signature separator lines. Paragraphs need at least one flowed line and get terminated by a fixed line, and that fixed line is part of the paragraph. (There are a few exceptions to this, which the text covers 🎀)
Without at least one flowed line, you just have a series of fixed lines, each one independent. No paragraph there 🙃
With at least one flowed line, you do have a paragraph, and the received lines can be reflowed to fit the display window size. That only works if the lines are part of a logical grouping, which is the paragraph ✨
Also, the definitions of flowed-line and sig-sep are potentially ambiguous: a signature separator line matches both, but it gets treated as a signature separator line, not a flowed line 🖊️
7. Failure Modes 💀
7.1. Trailing White Space Corruption 🫠
There are systems out there that alter trailing whitespace on messages passing through them. These systems may strip it or, in rarer cases, add it, in violation of RFC 2821 [SMTP] Section 4.5.2.
Stripping trailing whitespace turns flowed lines into fixed lines, which leaves the message no worse off than if Format=Flowed hadn't been used at all 🌸
Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply 😭
Most systems that add trailing white space do it to create a line that fills an internal record format, so the result is almost always a line with an even number of characters (counting the added trailing white space) 🔢
One possible workaround would be to define Format=Flowed lines to use either one or two trailing space characters to mark a flowed line, so the total line length is odd. But since systems like this are pretty scarce these days, it's not worth the extra complexity 🙅♀️
8. Security Considerations 🔐
Any security considerations that 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. Go read it, it matters 💜
9. IANA Considerations ✨
okay so IANA just added a reference to this spec in the Text/Plain Media Type registration 📝🦋 that's the whole IANA section, bestie, and it's giving quiet confidence 💅
10. Internationalization Considerations 🌍
okay this one is important 🫶 the line wrap and quoting rules of Format=Flowed might not be a good fit for some charsets, like Arabic and Hebrew, which are written right to left ➡️⬅️ so you gotta be careful using format=flowed for those. in these cases, format=fixed combined with [quoted-printable] encoding may be more suitable 🌸
and the DelSp parameter? it was added specifically so Format=Flowed can work with languages and coded character sets where the ASCII space character is rarely used, or not used at all 🧚 that's literally the whole reason it exists, iconic 👑
11. Acknowledgments 💜
the DelSp parameter was developed during a bunch of discussions with a lot of people 🫶 including Harald Alvestrand, Grant Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed, Alexey Melnikov, John Myers, and Pete Resnick. so many legends 😭
corrections and clarifications to RFC 2646 and the early versions of this doc were pointed out by several people too, including Adam Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho Mahalingam, Keith Moore, Greg Troxel, and Dan Wing 🎀
and lowkey my favourite line: I'm told that NeXT's mail application used a very similar mechanism (without support for non-Western languages) in 1992. the OG glow-up 🍓⭐
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:
- Added DelSp parameter to handle languages and coded character sets in which space is less common or not used. 🧚
- Updated text on generating and interpreting to accommodate the DelSp parameter.
- Changed the limits of 79 or 80 to be 78 in conformance with RFC 2822.
- Added text on generating to clarify that the 78-character limit includes trailing white space and stuffing.
- Changed sig-sep in ABNF to allow stuffing.
- Changed fixed-line to allow empty lines in ABNF.
- Added explanatory text following ABNF.
- Moved text from Abstract to new Introduction; rewrote Abstract.
- Moved interoperability text to new section, and updated.
- Clarified Security Considerations.
- Text on digital signatures now discusses that OpenPGP ignores trailing white space.
- Mention Unicode Annex 14.
- Added mention of quoting to Abstract and Introduction.
- Deleted line analysis table.
- Added recommendations for OpenPGP and OpenPGP-MIME.
- Rewrote ABNF rules to remove most ambiguity and note remaining case.
- Added note that c-t-e is irrelevant to flowed text processing.
- Added text indicating that end of data terminates a paragraph.
- Moved sig-sep out of fixed-line ABNF.
- Changed some SHOULDs to MUSTs (space-stuffing, quoted paragraphs). 🚨 yes these are the real deal, not vibes
- Added note to ABNF that space and ">" are encoded according to charset.
- Mentioned exceptions in section on interpreting.
- Clarified and made consistent treatment of signature separator lines.
Editorial:
- Added mention of NeXT's mail application to Acknowledgments.
- Updated Acknowledgments.
- Updated [SMTP] reference to 2821.
- Added Notices.
- Split References into Normative and Informative.
- Improved text wording in some areas.
- Standardize on "quote depth", not "quoting depth".
- Moved section on interpreting before section on generating.
- Reworded non-normative "should"s.
- Noted meaning of "paragraph".
okay and the last bit of Appendix A is the DelSp story 🦋 it was added specifically so Format=Flowed works with languages and coded character sets where the ASCII space character is rarely used, or not used at all. it was initially rejected as too much of a kludge, but it got selected anyway because it allows maximum interoperability between clients that support neither this spec nor RFC 2646, clients that support RFC 2646 but not this spec, and clients that support this spec. and that whole set gets multiplied by those that handle languages where spaces are common and those where they're uncommon or not used. the math is wild but it's giving compromise that actually works 🔥
Author's Address 🖊️
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
USA
Phone: +1 858 651 5115
EMail: randy@qualcomm.comFull 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. ✨
📦 where this page comes from
- ietf: rfc3676 2004-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms