rfc2646.txt

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


RFC 2646            The Text/Plain Format Parameter          August 1999


   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.

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 ">"
   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.  A sequence of quoted lines of the same
   quote depth SHOULD be encoded as a paragraph, with the last line
   generated as fixed and prior lines generated as flowed.

   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.  Consecutive lines with the
   same quoting depth are considered one paragraph and are reformatted
   together.  To re-quote after reformatting, a quote indicator
   containing the same number of close angle brackets originally present
   is prefixed to each line.



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


   On reception, if a change in quoting 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 ignore
   the flowed indicator and treat the line as fixed.  That is, the
   change in quote depth ends the 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):

      > 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 should 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 SHOULD NOT create this situation; a receiving
   agent SHOULD handle it using quote-depth wins.

4.6.  Digital Signatures and Encryption

   If a message is digitally signed or encrypted it is important that
   cryptographic processing use the on-the-wire Format=Flowed format.
   That is, during generation the message SHOULD be prepared for
   transmission, including addition of soft line breaks, space-stuffing,
   and [Quoted-Printable] encoding (to protect soft line breaks) before
   being digitally signed or encrypted; similarly, on receipt the
   message SHOULD have the signature verified or be decrypted before
   [Quoted-Printable] decoding and removal of stuffed spaces, soft line
   breaks and quote marks, and reflowing.





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


4.7.  Line Analysis Table

   Lines contained in a Text/Plain body part with Format=Flowed can be
   analyzed by examining the start and end of the line.  If the line
   starts with the quote indicator, it is quoted.  If the line ends with
   one or more space characters, it is flowed.  This is summarized by
   the following table:

      Starts          Ends in
      with            One or             Line
      Quote           More Spaces        Type
      ------          -----------        ---------------
      no              no                 unquoted, fixed
      yes             no                 quoted,   fixed
      no              yes                unquoted, flowed
      yes             yes                quoted,   flowed

4.8.  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.'#









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


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

   The constructs used in Text/Plain; Format=Flowed body parts are
   described using [ABNF], including the Core Rules:

      paragraph     = 1*flowed-line fixed-line
      fixed-line    = fixed / sig-sep
      fixed         = [quote] [stuffing] *text-char non-sp CRLF
      flowed-line   = flow-qt / flow-unqt
      flow-qt       = quote [stuffing] *text-char 1*SP CRLF
      flow-unqt     = [stuffing] *text-char 1*SP CRLF
      non-sp        = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F
                         ; any 7-bit US-ASCII character, excluding
                         ; NUL, CR, LF, and SP
      quote         = 1*">"
      sig-sep       = [quote] "--" SP CRLF
      stuffing      = [SP] ; space-stuffed, added on generation if
                           ; needed, deleted on reception
      text-char     = non-sp / SP

6.  Failure Modes

6.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 821 [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.

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



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


   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.

7.  Security Considerations

   This parameter introduces no security considerations beyond those
   which apply to Text/Plain.

   Section 4.6 discusses the interaction between Format=Flowed and
   digital signatures or encryption.

8.  IANA Considerations

   IANA is requested to add a reference to this specification in the
   Text/Plain Media Type registration.

9.  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 should be taken in
   applying format=flowed in these cases, as format=fixed combined with
   quoted-printable encoding may be more suitable.

10.  Acknowledgments

   This proposal evolved from a discussion of Chris Newman's
   Text/Paragraph draft which took place on the IETF 822 mailing list.
   Special thanks to Ian Bell, Steve Dorner, Brian Kelley, Dan Kohn,
   Laurence Lundblade, and Dan Wing for their reviews, comments,
   suggestions, and discussions.

11.  References

   [ABNF]             Crocker, D. and  P. Overell, "Augmented BNF for
                      Syntax Specifications: ABNF", RFC 2234, November
                      1997.

   [KEYWORDS]         S. Bradner, "Key words for use in RFCs to Indicate
                      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RICH]             Resnick, P. and A. Walker, "The text/enriched MIME
                      Content-type", RFC 1896, February 1996.





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


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

   [SMTP]             Postel, J., "Simple Mail Transfer Protocol", STD
                      10, RFC 821,  August 1982.

   [HTML]             Berners-Lee, T. and D. Connolly, "Hypertext Markup
                      Language -- 2.0", RFC 1866, November 1995.


12.  Editor's Address

   Randall Gellens
   QUALCOMM Incorporated
   5775 Morehouse Dr.
   San Diego, CA  92121-2779
   USA

   Phone: [phone]
   EMail: [e-mail]

























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


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Gellens                     Standards Track                    [Page 14]