rfc2646.txt - rohrpost - A commandline mail client to change the world as we see it.
(HTM) git clone git://r-36.net/rohrpost
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) 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