rohrpost

A commandline mail client to change the world as we see it.
git clone git://r-36.net/rohrpost
Log | Files | Refs | README | LICENSE

rfc2646.txt (29175B)


      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                 R. Gellens, Editor
      8 Request for Comments: 2646                                      Qualcomm
      9 Updates: 2046                                                August 1999
     10 Category: Standards Track
     11 
     12 
     13                     The Text/Plain Format Parameter
     14 
     15 Status of this Memo
     16 
     17    This document specifies an Internet standards track protocol for the
     18    Internet community, and requests discussion and suggestions for
     19    improvements.  Please refer to the current edition of the "Internet
     20    Official Protocol Standards" (STD 1) for the standardization state
     21    and status of this protocol.  Distribution of this memo is unlimited.
     22 
     23 Copyright Notice
     24 
     25    Copyright (C) The Internet Society (1999).  All Rights Reserved.
     26 
     27 Table of Contents
     28 
     29     1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
     30     2.  Conventions Used in this Document . . . . . . . . . . . . .   2
     31     3.  The Problem  . . . . . . . . . . . . . . . . . . . . . . . .  2
     32       3.1.  Paragraph Text  . . . . . . . . . . . . . . . . . . . .   3
     33       3.2.  Embarrassing Line Wrap . . . . . . . . . . . . . . . . .  3
     34       3.3.  New Media Types . . . . . . . . . . . . . . . . . . . .   4
     35     4.  The Format Parameter to the Text/Plain Media Type  . . . . .  4
     36       4.1.  Generating Format=Flowed  . . . . . . . . . . . . . . .   5
     37       4.2.  Interpreting Format=Flowed . . . . . . . . . . . . . . .  6
     38       4.3.  Usenet Signature Convention . . . . . . . . . . . . . .   7
     39       4.4.  Space-Stuffing . . . . . . . . . . . . . . . . . . . . .  7
     40       4.5.  Quoting . . . . . . . . . . . . . . . . . . . . . . . .   8
     41       4.6.  Digital Signatures and Encryption  . . . . . . . . . . .  9
     42       4.7.  Line Analysis Table . . . . . . . . . . . . . . . . . .  10
     43       4.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
     44     5.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     45     6.  Failure Modes  . . . . . . . . . . . . . . . . . . . . . . . 11
     46       6.1.  Trailing White Space Corruption . . . . . . . . . . . .  11
     47     7.  Security Considerations  . . . . . . . . . . . . . . . . . . 12
     48     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . .  12
     49     9.  Internationalization Considerations  . . . . . . . . . . . . 12
     50    10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  12
     51    11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 13
     52    12.  Editor's Address  . . . . . . . . . . . . . . . . . . . . .  13
     53    13.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
     54 
     55 
     56 
     57 
     58 Gellens                     Standards Track                     [Page 1]
     59 
     60 RFC 2646            The Text/Plain Format Parameter          August 1999
     61 
     62 
     63 1.  Abstract
     64 
     65    Interoperability problems have been observed with erroneous labelling
     66    of paragraph text as Text/Plain, and with various forms of
     67    "embarrassing line wrap." (See section 3.)
     68 
     69    Attempts to deploy new media types, such as Text/Enriched [RICH] and
     70    Text/HTML [HTML] have suffered from a lack of backwards compatibility
     71    and an often hostile user reaction at the receiving end.
     72 
     73    What is required is a format which is in all significant ways
     74    Text/Plain, and therefore is quite suitable for display as
     75    Text/Plain, and yet allows the sender to express to the receiver
     76    which lines can be considered a logical paragraph, and thus flowed
     77    (wrapped and joined) as appropriate.
     78 
     79    This memo proposes a new parameter to be used with Text/Plain, and,
     80    in the presence of this parameter, the use of trailing whitespace to
     81    indicate flowed lines.  This results in an encoding which appears as
     82    normal Text/Plain in older implementations, since it is in fact
     83    normal Text/Plain.
     84 
     85 2.  Conventions Used in this Document
     86 
     87    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
     88    and "MAY" in this document are to be interpreted as described in "Key
     89    words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
     90 
     91 3.  The Problem
     92 
     93    The Text/Plain media type is the lowest common denominator of
     94    Internet email, with lines of no more than 997 characters (by
     95    convention usually no more than 80), and where the CRLF sequence
     96    represents a line break [MIME-IMT].
     97 
     98    Text/Plain is usually displayed as preformatted text, often in a
     99    fixed font.  That is, the characters start at the left margin of the
    100    display window, and advance to the right until a CRLF sequence is
    101    seen, at which point a new line is started, again at the left margin.
    102    When a line length exceeds the display window, some clients will wrap
    103    the line, while others invoke a horizontal scroll bar.
    104 
    105    Text which meets this description is defined by this memo as "fixed".
    106 
    107    Some interoperability problems have been observed with this media
    108    type:
    109 
    110 
    111 
    112 
    113 
    114 Gellens                     Standards Track                     [Page 2]
    115 
    116 RFC 2646            The Text/Plain Format Parameter          August 1999
    117 
    118 
    119 3.1.  Paragraph Text
    120 
    121    Many modern programs use a proportional-spaced font and CRLF to
    122    represent paragraph breaks.  Line breaks are "soft", occurring as
    123    needed on display.  That is, characters are grouped into a paragraph
    124    until a CRLF sequence is seen, at which point a new paragraph is
    125    started.  Each paragraph is displayed, starting at the left margin
    126    (or paragraph indent), and continuing to the right until a word is
    127    encountered which does not fit in the remaining display width.  This
    128    word is displayed at the left margin of the next line.  This
    129    continues until the paragraph ends (a CRLF is seen).  Extra vertical
    130    space is left between paragraphs.
    131 
    132    Text which meets this description is defined by this memo as
    133    "flowed".
    134 
    135    Numerous software products erroneously label this media type as
    136    Text/Plain, resulting in much user discomfort.
    137 
    138 3.2.  Embarrassing Line Wrap
    139 
    140    As Text/Plain messages get quoted in replies or forwarded messages,
    141    the length of each line gradually increases, resulting in
    142    "embarrassing line wrap." This results in text which is at best hard
    143    to read, and often confuses attributions.
    144 
    145       Example:
    146 
    147             >>>>>>This is a comment from the first message to show a
    148             >quoting example.
    149             >>>>>This is a comment from the second message to show a
    150             >quoting example.
    151             >>>>This is a comment from the third message.
    152             >>>This is a comment from the fourth message.
    153 
    154    It can be confusing to assign attribution to lines 2 and 4 above.
    155 
    156    In addition, as devices with display widths smaller than 80
    157    characters become more popular, embarrassing line wrap has become
    158    even more prevalent, even with unquoted text.
    159 
    160 
    161 
    162 
    163 
    164 
    165 
    166 
    167 
    168 
    169 
    170 Gellens                     Standards Track                     [Page 3]
    171 
    172 RFC 2646            The Text/Plain Format Parameter          August 1999
    173 
    174 
    175    Example:
    176 
    177             This is paragraph text that is
    178             meant to be flowed across
    179             several lines.
    180             However, the sending mailer is
    181             converting it to fixed text at
    182             a width of 72
    183             characters, which causes it to
    184             look like this when shown on a
    185             PDA with only
    186             30 character lines.
    187 
    188 3.3.  New Media Types
    189 
    190    Attempts to deploy new media types, such as Text/Enriched [RICH] and
    191    Text/HTML [HTML] have suffered from a lack of backwards compatibility
    192    and an often hostile user reaction at the receiving end.
    193 
    194    In particular, Text/Enriched requires that open angle brackets ("<")
    195    and hard line breaks be doubled, with resulting user unhappiness when
    196    viewed as Text/Plain.  Text/HTML requires even more alteration of
    197    text, with a corresponding increase in user complaints.
    198 
    199    A proposal to define a new media type to explicitly represent the
    200    paragraph form suffered from a lack of interoperability with
    201    currently deployed software.  Some programs treat unknown subtypes of
    202    Text as an attachment.
    203 
    204    What is desired is a format which is in all significant ways
    205    Text/Plain, and therefore is quite suitable for display as
    206    Text/Plain, and yet allows the sender to express to the receiver
    207    which lines can be considered a logical paragraph, and thus flowed
    208    (wrapped and joined) as appropriate.
    209 
    210 4.  The Format Parameter to the Text/Plain Media Type
    211 
    212    This document defines a new MIME parameter for use with Text/Plain:
    213 
    214       Name:  Format
    215       Value:  Fixed, Flowed
    216 
    217    (Neither the parameter name nor its value are case sensitive.)
    218 
    219    If not specified, a value of Fixed is assumed.  The semantics of the
    220    Fixed value are the usual associated with Text/Plain [MIME-IMT].
    221 
    222 
    223 
    224 
    225 
    226 Gellens                     Standards Track                     [Page 4]
    227 
    228 RFC 2646            The Text/Plain Format Parameter          August 1999
    229 
    230 
    231    A value of Flowed indicates that the definition of flowed text (as
    232    specified in this memo) was used on generation, and MAY be used on
    233    reception.
    234 
    235    This section discusses flowed text; section 5 provides a formal
    236    definition.
    237 
    238    Because flowed lines are all-but-indistinguishable from fixed lines,
    239    currently deployed software treats flowed lines as normal Text/Plain
    240    (which is what they are).  Thus, no interoperability problems are
    241    expected.
    242 
    243    Note that this memo describes an on-the-wire format.  It does not
    244    address formats for local file storage.
    245 
    246 4.1.  Generating Format=Flowed
    247 
    248    When generating Format=Flowed text, lines SHOULD be shorter than 80
    249    characters.  As suggested values, any paragraph longer than 79
    250    characters in total length could be wrapped using lines of 72 or
    251    fewer characters.  While the specific line length used is a matter of
    252    aesthetics and preference, longer lines are more likely to require
    253    rewrapping and to encounter difficulties with older mailers.  It has
    254    been suggested that 66 character lines are the most readable.
    255 
    256    (The reason for the restriction to 79 or fewer characters between
    257    CRLFs on the wire is to ensure that all lines, even when displayed by
    258    a non-flowed-aware program, will fit in a standard 80-column screen
    259    without having to be wrapped.  The limit is 79, not 80, because while
    260    80 fit on a line, the last column is often reserved for a line-wrap
    261    indicator.)
    262 
    263    When creating flowed text, the generating agent wraps, that is,
    264    inserts 'soft' line breaks as needed.  Soft line breaks are added
    265    between words.  Because a soft line break is a SP CRLF sequence, the
    266    generating agent creates one by inserting a CRLF after the occurance
    267    of a space.
    268 
    269    A generating agent SHOULD NOT insert white space into a word (a
    270    sequence of printable characters not containing spaces).  If faced
    271    with a word which exceeds 79 characters (but less than 998
    272    characters, the [SMTP] limit on line length), the agent SHOULD send
    273    the word as is and exceed the 79-character limit on line length.
    274 
    275 
    276 
    277 
    278 
    279 
    280 
    281 
    282 Gellens                     Standards Track                     [Page 5]
    283 
    284 RFC 2646            The Text/Plain Format Parameter          August 1999
    285 
    286 
    287    A generating agent SHOULD:
    288 
    289       1.  Ensure all lines (fixed and flowed) are 79 characters or
    290           fewer in length, counting the trailing space but not
    291           counting the CRLF, unless a word by itself exceeds 79
    292           characters.
    293       2.  Trim spaces before user-inserted hard line breaks.
    294       3.  Space-stuff lines which start with a space, "From ", or
    295           ">".
    296 
    297    In order to create messages which do not require space-stuffing, and
    298    are thus more aesthetically pleasing when viewed as Format=Fixed, a
    299    generating agent MAY avoid wrapping immediately before ">", "From ",
    300    or space.
    301 
    302    (See sections 4.4 and 4.5 for more information on space-stuffing and
    303    quoting, respectively.)
    304 
    305    A Format=Flowed message consists of zero or more paragraphs, each
    306    containing one or more flowed lines followed by one fixed line.  The
    307    usual case is a series of flowed text lines with blank (empty) fixed
    308    lines between them.
    309 
    310    Any number of fixed lines can appear between paragraphs.
    311 
    312    [Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed
    313    unless absolutely necessary (for example, non-US-ASCII (8-bit)
    314    characters over a strictly 7-bit transport such as unextended SMTP).
    315    In particular, a message SHOULD NOT be encoded in Quoted-Printable
    316    for the sole purpose of protecting the trailing space on flowed lines
    317    unless the body part is cryptographically signed or encrypted (see
    318    Section 4.6).
    319 
    320    The intent of Format=Flowed is to allow user agents to generate
    321    flowed text which is non-obnoxious when viewed as pure, raw
    322    Text/Plain (without any decoding); use of Quoted-Printable hinders
    323    this and may cause Format=Flowed to be rejected by end users.
    324 
    325 4.2.  Interpreting Format=Flowed
    326 
    327    If the first character of a line is a quote mark (">"), the line is
    328    considered to be quoted (see section 4.5).  Logically, all quote
    329    marks are counted and deleted, resulting in a line with a non-zero
    330    quote depth, and content. (The agent is of course free to display the
    331    content with quote marks or excerpt bars or anything else.)
    332    Logically, this test for quoted lines is done before any other tests
    333    (that is, before checking for space-stuffed and flowed).
    334 
    335 
    336 
    337 
    338 Gellens                     Standards Track                     [Page 6]
    339 
    340 RFC 2646            The Text/Plain Format Parameter          August 1999
    341 
    342 
    343    If the first character of a line is a space, the line has been
    344    space-stuffed (see section 4.4).  Logically, this leading space is
    345    deleted before examining the line further (that is, before checking
    346    for flowed).
    347 
    348    If the line ends in one or more spaces, the line is flowed.
    349    Otherwise it is fixed.  Trailing spaces are part of the line's
    350    content, but the CRLF of a soft line break is not.
    351 
    352    A series of one or more flowed lines followed by one fixed line is
    353    considered a paragraph, and MAY be flowed (wrapped and unwrapped) as
    354    appropriate on display and in the construction of new messages (see
    355    section 4.5).
    356 
    357    A line consisting of one or more spaces (after deleting a stuffed
    358    space) is considered a flowed line.
    359 
    360 4.3.  Usenet Signature Convention
    361 
    362    There is a convention in Usenet news of using "-- " as the separator
    363    line between the body and the signature of a message.  When
    364    generating a Format=Flowed message containing a Usenet-style
    365    separator before the signature, the separator line is sent as-is.
    366    This is a special case; an (optionally quoted) line consisting of
    367    DASH DASH SP is not considered flowed.
    368 
    369 4.4.  Space-Stuffing
    370 
    371    In order to allow for unquoted lines which start with ">", and to
    372    protect against systems which "From-munge" in-transit messages
    373    (modifying any line which starts with "From " to ">From "),
    374    Format=Flowed provides for space-stuffing.
    375 
    376    Space-stuffing adds a single space to the start of any line which
    377    needs protection when the message is generated.  On reception, if the
    378    first character of a line is a space, it is logically deleted.  This
    379    occurs after the test for a quoted line, and before the test for a
    380    flowed line.
    381 
    382    On generation, any unquoted lines which start with ">", and any lines
    383    which start with a space or "From " SHOULD be space-stuffed.  Other
    384    lines MAY be space-stuffed as desired.
    385 
    386    (Note that space-stuffing is similar to dot-stuffing as specified in
    387    [SMTP].)
    388 
    389 
    390 
    391 
    392 
    393 
    394 Gellens                     Standards Track                     [Page 7]
    395 
    396 RFC 2646            The Text/Plain Format Parameter          August 1999
    397 
    398 
    399    If a space-stuffed message is received by an agent which handles
    400    Format=Flowed, the space-stuffing is reversed and thus the message
    401    appears unchanged.  An agent which is not aware of Format=Flowed will
    402    of course not undo any space-stuffing, thus Format=Flowed messages
    403    may appear with a leading space on some lines (those which start with
    404    a space, ">" which is not a quote indicator, or "From ").  Since
    405    lines which require space-stuffing rarely occur, and the aesthetic
    406    consequences of unreversed space-stuffing are minimal, this is not
    407    expected to be a significant problem.
    408 
    409 4.5.  Quoting
    410 
    411    In Format=Flowed, the canonical quote indicator (or quote mark) is
    412    one or more close angle bracket (">") characters.  Lines which start
    413    with the quote indicator are considered quoted.  The number of ">"
    414    characters at the start of the line specifies the quote depth.
    415    Flowed lines which are also quoted may require special handling on
    416    display and when copied to new messages.
    417 
    418    When creating quoted flowed lines, each such line starts with the
    419    quote indicator.
    420 
    421    Note that because of space-stuffing, the lines
    422        >> Exit, Stage Left
    423    and
    424        >>Exit, Stage Left
    425    are semantically identical; both have a quote-depth of two, and a
    426    content of "Exit, Stage Left".
    427 
    428    However, the line
    429        > > Exit, Stage Left
    430    is different.  It has a quote-depth of one, and a content of
    431    "> Exit, Stage Left".
    432 
    433    When generating quoted flowed lines, an agent needs to pay attention
    434    to changes in quote depth.  A sequence of quoted lines of the same
    435    quote depth SHOULD be encoded as a paragraph, with the last line
    436    generated as fixed and prior lines generated as flowed.
    437 
    438    If a receiving agent wishes to reformat flowed quoted lines (joining
    439    and/or wrapping them) on display or when generating new messages, the
    440    lines SHOULD be de-quoted, reformatted, and then re-quoted.  To
    441    de-quote, the number of close angle brackets in the quote indicator
    442    at the start of each line is counted.  Consecutive lines with the
    443    same quoting depth are considered one paragraph and are reformatted
    444    together.  To re-quote after reformatting, a quote indicator
    445    containing the same number of close angle brackets originally present
    446    is prefixed to each line.
    447 
    448 
    449 
    450 Gellens                     Standards Track                     [Page 8]
    451 
    452 RFC 2646            The Text/Plain Format Parameter          August 1999
    453 
    454 
    455    On reception, if a change in quoting depth occurs on a flowed line,
    456    this is an improperly formatted message.  The receiver SHOULD handle
    457    this error by using the 'quote-depth-wins' rule, which is to ignore
    458    the flowed indicator and treat the line as fixed.  That is, the
    459    change in quote depth ends the paragraph.
    460 
    461    For example, consider the following sequence of lines (using '*' to
    462    indicate a soft line break, i.e., SP CRLF, and '#' to indicate a hard
    463    line break, i.e., CRLF):
    464 
    465       > Thou villainous ill-breeding spongy dizzy-eyed*
    466       > reeky elf-skinned pigeon-egg!*     <--- problem ---<
    467       >> Thou artless swag-bellied milk-livered*
    468       >> dismal-dreaming idle-headed scut!#
    469       >>> Thou errant folly-fallen spleeny reeling-ripe*
    470       >>> unmuzzled ratsbane!#
    471       >>>> Henceforth, the coding style is to be strictly*
    472       >>>> enforced, including the use of only upper case.#
    473       >>>>> I've noticed a lack of adherence to the coding*
    474       >>>>> styles, of late.#
    475       >>>>>> Any complaints?#
    476 
    477    The second line ends in a soft line break, even though it is the last
    478    line of the one-deep quote block.  The question then arises as to how
    479    this line should be interpreted, considering that the next line is
    480    the first line of the two-deep quote block.
    481 
    482    The example text above, when processed according to quote-depth wins,
    483    results in the first two lines being considered as one quoted, flowed
    484    section, with a quote depth of 1; the third and fourth lines become a
    485    quoted, flowed section, with a quote depth of 2.
    486 
    487    A generating agent SHOULD NOT create this situation; a receiving
    488    agent SHOULD handle it using quote-depth wins.
    489 
    490 4.6.  Digital Signatures and Encryption
    491 
    492    If a message is digitally signed or encrypted it is important that
    493    cryptographic processing use the on-the-wire Format=Flowed format.
    494    That is, during generation the message SHOULD be prepared for
    495    transmission, including addition of soft line breaks, space-stuffing,
    496    and [Quoted-Printable] encoding (to protect soft line breaks) before
    497    being digitally signed or encrypted; similarly, on receipt the
    498    message SHOULD have the signature verified or be decrypted before
    499    [Quoted-Printable] decoding and removal of stuffed spaces, soft line
    500    breaks and quote marks, and reflowing.
    501 
    502 
    503 
    504 
    505 
    506 Gellens                     Standards Track                     [Page 9]
    507 
    508 RFC 2646            The Text/Plain Format Parameter          August 1999
    509 
    510 
    511 4.7.  Line Analysis Table
    512 
    513    Lines contained in a Text/Plain body part with Format=Flowed can be
    514    analyzed by examining the start and end of the line.  If the line
    515    starts with the quote indicator, it is quoted.  If the line ends with
    516    one or more space characters, it is flowed.  This is summarized by
    517    the following table:
    518 
    519       Starts          Ends in
    520       with            One or             Line
    521       Quote           More Spaces        Type
    522       ------          -----------        ---------------
    523       no              no                 unquoted, fixed
    524       yes             no                 quoted,   fixed
    525       no              yes                unquoted, flowed
    526       yes             yes                quoted,   flowed
    527 
    528 4.8.  Examples
    529 
    530    The following example contains three paragraphs:
    531 
    532       `Take some more tea,' the March Hare said to Alice, very
    533       earnestly.
    534 
    535       `I've had nothing yet,' Alice replied in an offended tone, `so I
    536       can't take more.'
    537 
    538       `You mean you can't take LESS,' said the Hatter: `it's very easy
    539       to take MORE than nothing.'
    540 
    541    This could be encoded as follows (using '*' to indicate a soft line
    542    break, that is, SP CRLF sequence, and '#' to indicate a hard line
    543    break, that is, CRLF):
    544 
    545       `Take some more tea,' the March Hare said to Alice, very*
    546       earnestly.*
    547       #
    548       `I've had nothing yet,' Alice replied in an offended tone, `so*
    549       I can't take more.'*
    550       #
    551       `You mean you can't take LESS,' said the Hatter: `it's very*
    552       easy to take MORE than nothing.'#
    553 
    554 
    555 
    556 
    557 
    558 
    559 
    560 
    561 
    562 Gellens                     Standards Track                    [Page 10]
    563 
    564 RFC 2646            The Text/Plain Format Parameter          August 1999
    565 
    566 
    567    To show an example of quoting, here we have the same exchange,
    568    presented as a series of direct quotes:
    569 
    570                 >>>Take some more tea.#
    571                 >>I've had nothing yet, so I can't take more.#
    572                 >You mean you can't take LESS, it's very easy to take*
    573                 >MORE than nothing.#
    574 
    575 5.  ABNF
    576 
    577    The constructs used in Text/Plain; Format=Flowed body parts are
    578    described using [ABNF], including the Core Rules:
    579 
    580       paragraph     = 1*flowed-line fixed-line
    581       fixed-line    = fixed / sig-sep
    582       fixed         = [quote] [stuffing] *text-char non-sp CRLF
    583       flowed-line   = flow-qt / flow-unqt
    584       flow-qt       = quote [stuffing] *text-char 1*SP CRLF
    585       flow-unqt     = [stuffing] *text-char 1*SP CRLF
    586       non-sp        = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F
    587                          ; any 7-bit US-ASCII character, excluding
    588                          ; NUL, CR, LF, and SP
    589       quote         = 1*">"
    590       sig-sep       = [quote] "--" SP CRLF
    591       stuffing      = [SP] ; space-stuffed, added on generation if
    592                            ; needed, deleted on reception
    593       text-char     = non-sp / SP
    594 
    595 6.  Failure Modes
    596 
    597 6.1.  Trailing White Space Corruption
    598 
    599    There are systems in existence which alter trailing whitespace on
    600    messages which pass through them.  Such systems may strip, or in
    601    rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP]
    602    section 4.5.2.
    603 
    604    Stripping trailing whitespace has the effect of converting flowed
    605    lines to fixed lines, which results in a message no worse than if
    606    Format=Flowed had not been used.
    607 
    608    Adding trailing whitespace to a Format=Flowed message may result in a
    609    malformed display or reply.
    610 
    611    Since most systems which add trailing white space do so to create a
    612    line which fills an internal record format, the result is almost
    613    always a line which contains an even number of characters (counting
    614    the added trailing white space).
    615 
    616 
    617 
    618 Gellens                     Standards Track                    [Page 11]
    619 
    620 RFC 2646            The Text/Plain Format Parameter          August 1999
    621 
    622 
    623    One possible avoidance, therefore, would be to define Format=Flowed
    624    lines to use either one or two trailing space characters to indicate
    625    a flowed line, such that the total line length is odd.  However,
    626    considering the scarcity of such systems today, it is not worth the
    627    added complexity.
    628 
    629 7.  Security Considerations
    630 
    631    This parameter introduces no security considerations beyond those
    632    which apply to Text/Plain.
    633 
    634    Section 4.6 discusses the interaction between Format=Flowed and
    635    digital signatures or encryption.
    636 
    637 8.  IANA Considerations
    638 
    639    IANA is requested to add a reference to this specification in the
    640    Text/Plain Media Type registration.
    641 
    642 9.  Internationalization Considerations
    643 
    644    The line wrap and quoting specifications of Format=Flowed may not be
    645    suitable for certain charsets, such as for Arabic and Hebrew
    646    characters that read from right to left.  Care should be taken in
    647    applying format=flowed in these cases, as format=fixed combined with
    648    quoted-printable encoding may be more suitable.
    649 
    650 10.  Acknowledgments
    651 
    652    This proposal evolved from a discussion of Chris Newman's
    653    Text/Paragraph draft which took place on the IETF 822 mailing list.
    654    Special thanks to Ian Bell, Steve Dorner, Brian Kelley, Dan Kohn,
    655    Laurence Lundblade, and Dan Wing for their reviews, comments,
    656    suggestions, and discussions.
    657 
    658 11.  References
    659 
    660    [ABNF]             Crocker, D. and  P. Overell, "Augmented BNF for
    661                       Syntax Specifications: ABNF", RFC 2234, November
    662                       1997.
    663 
    664    [KEYWORDS]         S. Bradner, "Key words for use in RFCs to Indicate
    665                       Requirement Levels", BCP 14, RFC 2119, March 1997.
    666 
    667    [RICH]             Resnick, P. and A. Walker, "The text/enriched MIME
    668                       Content-type", RFC 1896, February 1996.
    669 
    670 
    671 
    672 
    673 
    674 Gellens                     Standards Track                    [Page 12]
    675 
    676 RFC 2646            The Text/Plain Format Parameter          August 1999
    677 
    678 
    679    [MIME-IMT]         Freed, N. and N. Borenstein, "Multipurpose
    680                       Internet Mail Extensions (MIME) Part Two: Media
    681                       Types", RFC 2046, November 1996.
    682 
    683    [Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose
    684                       Internet Mail Extensions (MIME) Part One: Format
    685                       of Internet Message Bodies", RFC 2045, November
    686                       1996.
    687 
    688    [SMTP]             Postel, J., "Simple Mail Transfer Protocol", STD
    689                       10, RFC 821,  August 1982.
    690 
    691    [HTML]             Berners-Lee, T. and D. Connolly, "Hypertext Markup
    692                       Language -- 2.0", RFC 1866, November 1995.
    693 
    694 
    695 12.  Editor's Address
    696 
    697    Randall Gellens
    698    QUALCOMM Incorporated
    699    5775 Morehouse Dr.
    700    San Diego, CA  92121-2779
    701    USA
    702 
    703    Phone: +1 619 651 5115
    704    EMail: randy@qualcomm.com
    705 
    706 
    707 
    708 
    709 
    710 
    711 
    712 
    713 
    714 
    715 
    716 
    717 
    718 
    719 
    720 
    721 
    722 
    723 
    724 
    725 
    726 
    727 
    728 
    729 
    730 Gellens                     Standards Track                    [Page 13]
    731 
    732 RFC 2646            The Text/Plain Format Parameter          August 1999
    733 
    734 
    735 13.  Full Copyright Statement
    736 
    737    Copyright (C) The Internet Society (1999).  All Rights Reserved.
    738 
    739    This document and translations of it may be copied and furnished to
    740    others, and derivative works that comment on or otherwise explain it
    741    or assist in its implementation may be prepared, copied, published
    742    and distributed, in whole or in part, without restriction of any
    743    kind, provided that the above copyright notice and this paragraph are
    744    included on all such copies and derivative works.  However, this
    745    document itself may not be modified in any way, such as by removing
    746    the copyright notice or references to the Internet Society or other
    747    Internet organizations, except as needed for the purpose of
    748    developing Internet standards in which case the procedures for
    749    copyrights defined in the Internet Standards process must be
    750    followed, or as required to translate it into languages other than
    751    English.
    752 
    753    The limited permissions granted above are perpetual and will not be
    754    revoked by the Internet Society or its successors or assigns.
    755 
    756    This document and the information contained herein is provided on an
    757    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    758    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    759    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    760    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    761    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    762 
    763 Acknowledgement
    764 
    765    Funding for the RFC Editor function is currently provided by the
    766    Internet Society.
    767 
    768 
    769 
    770 
    771 
    772 
    773 
    774 
    775 
    776 
    777 
    778 
    779 
    780 
    781 
    782 
    783 
    784 
    785 
    786 Gellens                     Standards Track                    [Page 14]
    787