doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc3676.txt b/doc/rfc/rfc3676.txt
new file mode 100644
index 0000000..bc08fba
--- /dev/null
+++ b/doc/rfc/rfc3676.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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]
+