0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
0016
0017
0018
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
0078
0079
0080
0081
0082
0083
0084
0085
0086
0087
0088
0089
0090
0091
0092
0093
0094
0095
0096
0097
0098
0099
0100
0101
0102
0103
0104
0105
0106
0107
0108
0109
0110
0111
0112
0113
0114
0115
0116
0117
0118
0119
0120
0121
0122
0123
0124
0125
0126
0127
0128
0129
0130
0131
0132
0133
0134
0135
0136
0137
0138
0139
0140
0141
0142
0143
0144
0145
0146
0147
0148
0149
0150
0151
0152
0153
0154
0155
0156
0157
0158
0159
0160
0161
0162
0163
0164
0165
0166
0167
0168
0169
0170
0171
0172
0173
0174
0175
0176
0177
0178
0179
0180
0181
0182
0183
0184
0185
0186
0187
0188
0189
0190
0191
0192
0193
0194
0195
0196
0197
0198
0199
0200
0201
0202
0203
0204
0205
0206
0207
0208
0209
0210
0211
0212
0213
0214
0215
0216
0217
0218
0219
0220
0221
0222
0223
0224
0225
0226
0227
0228
0229
0230
0231
0232
0233
0234
0235
0236
0237
0238
0239
0240
0241
0242
0243
0244
0245
0246
0247
0248
0249
0250
0251
0252
0253
0254
0255
0256
0257
0258
0259
0260
0261
0262
0263
0264
0265
0266
0267
0268
0269
0270
0271
0272
0273
0274
0275
0276
0277
0278
0279
0280
0281
0282
0283
0284
0285
0286
0287
0288
0289
0290
0291
0292
0293
0294
0295
0296
0297
0298
0299
0300
0301
0302
0303
0304
0305
0306
0307
0308
0309
0310
0311
0312
0313
0314
0315
0316
0317
0318
0319
0320
0321
0322
0323
0324
0325
0326
0327
0328
0329
0330
0331
0332
0333
0334
0335
0336
0337
0338
0339
0340
0341
0342
0343
0344
0345
0346
0347
0348
0349
0350
0351
0352
0353
0354
0355
0356
0357
0358
0359
0360
0361
0362
0363
0364
0365
0366
0367
0368
0369
0370
0371
0372
0373
0374
0375
0376
0377
0378
0379
0380
0381
0382
0383
0384
0385
0386
0387
0388
0389
0390
0391
0392
0393
0394
0395
0396
0397
0398
0399
0400
0401
0402
0403
0404
0405
0406
0407
0408
0409
0410
0411
0412
0413
0414
0415
0416
0417
0418
0419
0420
0421
0422
0423
0424
0425
0426
0427
0428
0429
0430
0431
0432
0433
0434
0435
0436
0437
0438
0439
0440
0441
0442
0443
0444
0445
0446
0447
0448
0449
0450
0451
0452
0453
0454
0455
0456
0457
0458
0459
0460
0461
0462
0463
0464
0465
0466
0467
0468
0469
0470
0471
0472
0473
0474
0475
0476
0477
0478
0479
0480
0481
0482
0483
0484
0485
0486
0487
0488
0489
0490
0491
0492
0493
0494
0495
0496
0497
0498
0499
0500
0501
0502
0503
0504
0505
0506
0507
0508
0509
0510
0511
0512
0513
0514
0515
0516
0517
0518
0519
0520
0521
0522
0523
0524
0525
0526
0527
0528
0529
0530
0531
0532
0533
0534
0535
0536
0537
0538
0539
0540
0541
0542
0543
0544
0545
0546
0547
0548
0549
0550
0551
0552
0553
0554
0555
0556
0557
0558
0559
0560
0561
0562
0563
0564
0565
0566
0567
0568
0569
0570
0571
0572
0573
0574
0575
0576
0577
0578
0579
0580
0581
0582
0583
0584
0585
0586
0587
0588
0589
0590
0591
0592
0593
0594
0595
0596
0597
0598
0599
0600
0601
0602
0603
0604
0605
0606
0607
0608
0609
0610
0611
0612
0613
0614
0615
0616
0617
0618
0619
0620
0621
0622
0623
0624
0625
0626
0627
0628
0629
0630
0631
0632
0633
0634
0635
0636
0637
0638
0639
0640
0641
0642
0643
0644
0645
0646
0647
0648
0649
0650
0651
0652
0653
0654
0655
0656
0657
0658
0659
0660
0661
0662
0663
0664
0665
0666
0667
0668
0669
0670
0671
0672
0673
0674
0675
0676
0677
0678
0679
0680
0681
0682
0683
0684
0685
0686
0687
0688
0689
0690
0691
0692
0693
0694
0695
0696
0697
0698
0699
0700
0701
0702
0703
0704
0705
0706
0707
0708
0709
0710
0711
0712
0713
0714
0715
0716
0717
0718
0719
0720
0721
0722
0723
0724
0725
0726
0727
0728
0729
0730
0731
0732
0733
0734
0735
0736
0737
0738
0739
0740
0741
0742
0743
0744
0745
0746
0747
0748
0749
0750
0751
0752
0753
0754
0755
0756
0757
0758
0759
0760
0761
0762
0763
0764
0765
0766
0767
0768
0769
0770
0771
0772
0773
0774
0775
0776
0777
0778
0779
0780
0781
0782
0783
0784
0785
0786
0787
0788
0789
0790
0791
0792
0793
0794
0795
0796
0797
0798
0799
0800
0801
0802
0803
0804
0805
0806
0807
0808
0809
0810
0811
0812
0813
0814
0815
0816
0817
0818
0819
0820
0821
0822
0823
0824
0825
0826
0827
0828
0829
0830
0831
0832
0833
0834
0835
0836
0837
0838
0839
0840
0841
0842
0843
0844
0845
0846
0847
0848
0849
0850
0851
0852
0853
0854
0855
0856
0857
0858
0859
0860
0861
0862
0863
0864
0865
0866
0867
0868
0869
0870
0871
0872
0873
0874
0875
0876
0877
0878
0879
0880
0881
0882
0883
0884
0885
0886
0887
0888
0889
0890
0891
0892
0893
0894
0895
0896
0897
0898
0899
0900
0901
0902
0903
0904
0905
0906
0907
0908
0909
0910
0911
0912
0913
0914
0915
0916
0917
0918
0919
0920
0921
0922
0923
0924
0925
0926
0927
0928
0929
0930
0931
0932
0933
0934
0935
0936
0937
0938
0939
0940
0941
0942
0943
0944
0945
0946
0947
0948
0949
0950
0951
0952
0953
0954
0955
0956
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]

Search by Algolia