rfc2646.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/2 页

Network Working Group                                 R. Gellens, Editor
Request for Comments: 2646                                      Qualcomm
Updates: 2046                                                August 1999
Category: Standards Track


                    The Text/Plain Format Parameter

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 (1999).  All Rights Reserved.

Table of Contents

    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
    2.  Conventions Used in this Document . . . . . . . . . . . . .   2
    3.  The Problem  . . . . . . . . . . . . . . . . . . . . . . . .  2
      3.1.  Paragraph Text  . . . . . . . . . . . . . . . . . . . .   3
      3.2.  Embarrassing Line Wrap . . . . . . . . . . . . . . . . .  3
      3.3.  New Media Types . . . . . . . . . . . . . . . . . . . .   4
    4.  The Format Parameter to the Text/Plain Media Type  . . . . .  4
      4.1.  Generating Format=Flowed  . . . . . . . . . . . . . . .   5
      4.2.  Interpreting Format=Flowed . . . . . . . . . . . . . . .  6
      4.3.  Usenet Signature Convention . . . . . . . . . . . . . .   7
      4.4.  Space-Stuffing . . . . . . . . . . . . . . . . . . . . .  7
      4.5.  Quoting . . . . . . . . . . . . . . . . . . . . . . . .   8
      4.6.  Digital Signatures and Encryption  . . . . . . . . . . .  9
      4.7.  Line Analysis Table . . . . . . . . . . . . . . . . . .  10
      4.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
    5.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
    6.  Failure Modes  . . . . . . . . . . . . . . . . . . . . . . . 11
      6.1.  Trailing White Space Corruption . . . . . . . . . . . .  11
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . 12
    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . .  12
    9.  Internationalization Considerations  . . . . . . . . . . . . 12
   10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  12
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   12.  Editor's Address  . . . . . . . . . . . . . . . . . . . . .  13
   13.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 14




Gellens                     Standards Track                     [Page 1]

RFC 2646            The Text/Plain Format Parameter          August 1999


1.  Abstract

   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 can be considered a logical paragraph, and thus flowed
   (wrapped and joined) as appropriate.

   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.

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].

3.  The Problem

   The Text/Plain media type is the lowest common denominator of
   Internet email, with lines of no more than 997 characters (by
   convention usually no more than 80), and where the CRLF sequence
   represents a line break [MIME-IMT].

   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 media
   type:





Gellens                     Standards Track                     [Page 2]

RFC 2646            The Text/Plain Format Parameter          August 1999


3.1.  Paragraph Text

   Many modern programs use a proportional-spaced font and 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 media type as
   Text/Plain, resulting in much user discomfort.

3.2.  Embarrassing Line Wrap

   As Text/Plain messages get quoted in replies or forwarded messages,
   the length of each line gradually increases, resulting in
   "embarrassing line wrap." This results in text which is at best hard
   to read, and often confuses 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 assign attribution to lines 2 and 4 above.

   In addition, as devices with display widths smaller than 80
   characters become more popular, embarrassing line wrap has become
   even more prevalent, even with unquoted text.











Gellens                     Standards Track                     [Page 3]

RFC 2646            The Text/Plain Format Parameter          August 1999


   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.

   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 Parameter to the Text/Plain Media Type

   This document defines a new MIME parameter for use with Text/Plain:

      Name:  Format
      Value:  Fixed, Flowed

   (Neither the parameter name nor its value are case sensitive.)

   If not specified, a value of Fixed is assumed.  The semantics of the
   Fixed value are the usual associated with Text/Plain [MIME-IMT].





Gellens                     Standards Track                     [Page 4]

RFC 2646            The Text/Plain Format Parameter          August 1999


   A 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.

   This section discusses flowed text; section 5 provides a formal
   definition.

   Because flowed lines are all-but-indistinguishable from fixed lines,
   currently deployed software treats flowed lines as normal Text/Plain
   (which is what they are).  Thus, no interoperability problems are
   expected.

   Note that this memo describes an on-the-wire format.  It does not
   address formats for local file storage.

4.1.  Generating Format=Flowed

   When generating Format=Flowed text, lines SHOULD be shorter than 80
   characters.  As suggested values, any paragraph longer than 79
   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 reason for the restriction to 79 or fewer characters between
   CRLFs on the wire is to ensure that all lines, even when displayed by
   a non-flowed-aware program, will fit in a standard 80-column screen
   without having to be wrapped.  The limit is 79, not 80, because while
   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
   between words.  Because a soft line break is a SP CRLF sequence, the
   generating agent creates one by inserting a CRLF after the occurance
   of a space.

   A generating agent SHOULD NOT insert white space into a word (a
   sequence of printable characters not containing spaces).  If faced
   with a word which exceeds 79 characters (but less than 998
   characters, the [SMTP] limit on line length), the agent SHOULD send
   the word as is and exceed the 79-character limit on line length.








Gellens                     Standards Track                     [Page 5]

RFC 2646            The Text/Plain Format Parameter          August 1999


   A generating agent SHOULD:

      1.  Ensure all lines (fixed and flowed) are 79 characters or
          fewer in length, counting the trailing space but not
          counting the CRLF, unless a word by itself exceeds 79
          characters.
      2.  Trim spaces before user-inserted hard line breaks.
      3.  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.

   [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).

   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.2.  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).




Gellens                     Standards Track                     [Page 6]

RFC 2646            The Text/Plain Format Parameter          August 1999


   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 one or more spaces, the line is flowed.
   Otherwise it is fixed.  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).

   A line consisting of one or more spaces (after deleting a stuffed
   space) is considered a flowed line.

4.3.  Usenet Signature Convention

   There is a convention in Usenet news 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) line consisting of
   DASH DASH SP is not considered flowed.

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, 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 " SHOULD be space-stuffed.  Other
   lines MAY be space-stuffed as desired.

   (Note that space-stuffing is similar to dot-stuffing as specified in
   [SMTP].)






Gellens                     Standards Track                     [Page 7]