rfc2049.txt (51207B)
1 2 3 4 5 6 7 Network Working Group N. Freed 8 Request for Comments: 2049 Innosoft 9 Obsoletes: 1521, 1522, 1590 N. Borenstein 10 Category: Standards Track First Virtual 11 November 1996 12 13 14 Multipurpose Internet Mail Extensions 15 (MIME) Part Five: 16 Conformance Criteria and Examples 17 18 Status of this Memo 19 20 This document specifies an Internet standards track protocol for the 21 Internet community, and requests discussion and suggestions for 22 improvements. Please refer to the current edition of the "Internet 23 Official Protocol Standards" (STD 1) for the standardization state 24 and status of this protocol. Distribution of this memo is unlimited. 25 26 Abstract 27 28 STD 11, RFC 822, defines a message representation protocol specifying 29 considerable detail about US-ASCII message headers, and leaves the 30 message content, or message body, as flat US-ASCII text. This set of 31 documents, collectively called the Multipurpose Internet Mail 32 Extensions, or MIME, redefines the format of messages to allow for 33 34 (1) textual message bodies in character sets other than 35 US-ASCII, 36 37 (2) an extensible set of different formats for non-textual 38 message bodies, 39 40 (3) multi-part message bodies, and 41 42 (4) textual header information in character sets other than 43 US-ASCII. 44 45 These documents are based on earlier work documented in RFC 934, STD 46 11, and RFC 1049, but extends and revises them. Because RFC 822 said 47 so little about message bodies, these documents are largely 48 orthogonal to (rather than a revision of) RFC 822. 49 50 The initial document in this set, RFC 2045, specifies the various 51 headers used to describe the structure of MIME messages. The second 52 document defines the general structure of the MIME media typing 53 system and defines an initial set of media types. The third 54 document, RFC 2047, describes extensions to RFC 822 to allow non-US- 55 56 57 58 Freed & Borenstein Standards Track [Page 1] 59 60 RFC 2049 MIME Conformance November 1996 61 62 63 ASCII text data in Internet mail header fields. The fourth document, 64 RFC 2048, specifies various IANA registration procedures for MIME- 65 related facilities. This fifth and final document describes MIME 66 conformance criteria as well as providing some illustrative examples 67 of MIME message formats, acknowledgements, and the bibliography. 68 69 These documents are revisions of RFCs 1521, 1522, and 1590, which 70 themselves were revisions of RFCs 1341 and 1342. Appendix B of this 71 document describes differences and changes from previous versions. 72 73 Table of Contents 74 75 1. Introduction .......................................... 2 76 2. MIME Conformance ...................................... 2 77 3. Guidelines for Sending Email Data ..................... 6 78 4. Canonical Encoding Model .............................. 9 79 5. Summary ............................................... 12 80 6. Security Considerations ............................... 12 81 7. Authors' Addresses .................................... 12 82 8. Acknowledgements ...................................... 13 83 A. A Complex Multipart Example ........................... 15 84 B. Changes from RFC 1521, 1522, and 1590 ................. 16 85 C. References ............................................ 20 86 87 1. Introduction 88 89 The first and second documents in this set define MIME header fields 90 and the initial set of MIME media types. The third document 91 describes extensions to RFC822 formats to allow for character sets 92 other than US-ASCII. This document describes what portions of MIME 93 must be supported by a conformant MIME implementation. It also 94 describes various pitfalls of contemporary messaging systems as well 95 as the canonical encoding model MIME is based on. 96 97 2. MIME Conformance 98 99 The mechanisms described in these documents are open-ended. It is 100 definitely not expected that all implementations will support all 101 available media types, nor that they will all share the same 102 extensions. In order to promote interoperability, however, it is 103 useful to define the concept of "MIME-conformance" to define a 104 certain level of implementation that allows the useful interworking 105 of messages with content that differs from US-ASCII text. In this 106 section, we specify the requirements for such conformance. 107 108 109 110 111 112 113 114 Freed & Borenstein Standards Track [Page 2] 115 116 RFC 2049 MIME Conformance November 1996 117 118 119 A mail user agent that is MIME-conformant MUST: 120 121 (1) Always generate a "MIME-Version: 1.0" header field in 122 any message it creates. 123 124 (2) Recognize the Content-Transfer-Encoding header field 125 and decode all received data encoded by either quoted- 126 printable or base64 implementations. The identity 127 transformations 7bit, 8bit, and binary must also be 128 recognized. 129 130 Any non-7bit data that is sent without encoding must be 131 properly labelled with a content-transfer-encoding of 132 8bit or binary, as appropriate. If the underlying 133 transport does not support 8bit or binary (as SMTP 134 [RFC-821] does not), the sender is required to both 135 encode and label data using an appropriate Content- 136 Transfer-Encoding such as quoted-printable or base64. 137 138 (3) Must treat any unrecognized Content-Transfer-Encoding 139 as if it had a Content-Type of "application/octet- 140 stream", regardless of whether or not the actual 141 Content-Type is recognized. 142 143 (4) Recognize and interpret the Content-Type header field, 144 and avoid showing users raw data with a Content-Type 145 field other than text. Implementations must be able 146 to send at least text/plain messages, with the 147 character set specified with the charset parameter if 148 it is not US-ASCII. 149 150 (5) Ignore any content type parameters whose names they do 151 not recognize. 152 153 (6) Explicitly handle the following media type values, to 154 at least the following extents: 155 156 Text: 157 158 -- Recognize and display "text" mail with the 159 character set "US-ASCII." 160 161 -- Recognize other character sets at least to the 162 extent of being able to inform the user about what 163 character set the message uses. 164 165 166 167 168 169 170 Freed & Borenstein Standards Track [Page 3] 171 172 RFC 2049 MIME Conformance November 1996 173 174 175 -- Recognize the "ISO-8859-*" character sets to the 176 extent of being able to display those characters that 177 are common to ISO-8859-* and US-ASCII, namely all 178 characters represented by octet values 1-127. 179 180 -- For unrecognized subtypes in a known character 181 set, show or offer to show the user the "raw" version 182 of the data after conversion of the content from 183 canonical form to local form. 184 185 -- Treat material in an unknown character set as if 186 it were "application/octet-stream". 187 188 Image, audio, and video: 189 190 -- At a minumum provide facilities to treat any 191 unrecognized subtypes as if they were 192 "application/octet-stream". 193 194 Application: 195 196 -- Offer the ability to remove either of the quoted- 197 printable or base64 encodings defined in this 198 document if they were used and put the resulting 199 information in a user file. 200 201 Multipart: 202 203 -- Recognize the mixed subtype. Display all relevant 204 information on the message level and the body part 205 header level and then display or offer to display 206 each of the body parts individually. 207 208 -- Recognize the "alternative" subtype, and avoid 209 showing the user redundant parts of 210 multipart/alternative mail. 211 212 -- Recognize the "multipart/digest" subtype, 213 specifically using "message/rfc822" rather than 214 "text/plain" as the default media type for body parts 215 inside "multipart/digest" entities. 216 217 -- Treat any unrecognized subtypes as if they were 218 "mixed". 219 220 221 222 223 224 225 226 Freed & Borenstein Standards Track [Page 4] 227 228 RFC 2049 MIME Conformance November 1996 229 230 231 Message: 232 233 -- Recognize and display at least the RFC822 message 234 encapsulation (message/rfc822) in such a way as to 235 preserve any recursive structure, that is, displaying 236 or offering to display the encapsulated data in 237 accordance with its media type. 238 239 -- Treat any unrecognized subtypes as if they were 240 "application/octet-stream". 241 242 (7) Upon encountering any unrecognized Content-Type field, 243 an implementation must treat it as if it had a media 244 type of "application/octet-stream" with no parameter 245 sub-arguments. How such data are handled is up to an 246 implementation, but likely options for handling such 247 unrecognized data include offering the user to write it 248 into a file (decoded from its mail transport format) or 249 offering the user to name a program to which the 250 decoded data should be passed as input. 251 252 (8) Conformant user agents are required, if they provide 253 non-standard support for non-MIME messages employing 254 character sets other than US-ASCII, to do so on 255 received messages only. Conforming user agents must not 256 send non-MIME messages containing anything other than 257 US-ASCII text. 258 259 In particular, the use of non-US-ASCII text in mail 260 messages without a MIME-Version field is strongly 261 discouraged as it impedes interoperability when sending 262 messages between regions with different localization 263 conventions. Conforming user agents MUST include proper 264 MIME labelling when sending anything other than plain 265 text in the US-ASCII character set. 266 267 In addition, non-MIME user agents should be upgraded if 268 at all possible to include appropriate MIME header 269 information in the messages they send even if nothing 270 else in MIME is supported. This upgrade will have 271 little, if any, effect on non-MIME recipients and will 272 aid MIME in correctly displaying such messages. It 273 also provides a smooth transition path to eventual 274 adoption of other MIME capabilities. 275 276 (9) Conforming user agents must ensure that any string of 277 non-white-space printable US-ASCII characters within a 278 "*text" or "*ctext" that begins with "=?" and ends with 279 280 281 282 Freed & Borenstein Standards Track [Page 5] 283 284 RFC 2049 MIME Conformance November 1996 285 286 287 "?=" be a valid encoded-word. ("begins" means: At the 288 start of the field-body or immediately following 289 linear-white-space; "ends" means: At the end of the 290 field-body or immediately preceding linear-white- 291 space.) In addition, any "word" within a "phrase" that 292 begins with "=?" and ends with "?=" must be a valid 293 encoded-word. 294 295 (10) Conforming user agents must be able to distinguish 296 encoded-words from "text", "ctext", or "word"s, 297 according to the rules in section 4, anytime they 298 appear in appropriate places in message headers. It 299 must support both the "B" and "Q" encodings for any 300 character set which it supports. The program must be 301 able to display the unencoded text if the character set 302 is "US-ASCII". For the ISO-8859-* character sets, the 303 mail reading program must at least be able to display 304 the characters which are also in the US-ASCII set. 305 306 A user agent that meets the above conditions is said to be MIME- 307 conformant. The meaning of this phrase is that it is assumed to be 308 "safe" to send virtually any kind of properly-marked data to users of 309 such mail systems, because such systems will at least be able to 310 treat the data as undifferentiated binary, and will not simply splash 311 it onto the screen of unsuspecting users. 312 313 There is another sense in which it is always "safe" to send data in a 314 format that is MIME-conformant, which is that such data will not 315 break or be broken by any known systems that are conformant with RFC 316 821 and RFC 822. User agents that are MIME-conformant have the 317 additional guarantee that the user will not be shown data that were 318 never intended to be viewed as text. 319 320 3. Guidelines for Sending Email Data 321 322 Internet email is not a perfect, homogeneous system. Mail may become 323 corrupted at several stages in its travel to a final destination. 324 Specifically, email sent throughout the Internet may travel across 325 many networking technologies. Many networking and mail technologies 326 do not support the full functionality possible in the SMTP transport 327 environment. Mail traversing these systems is likely to be modified 328 in order that it can be transported. 329 330 There exist many widely-deployed non-conformant MTAs in the Internet. 331 These MTAs, speaking the SMTP protocol, alter messages on the fly to 332 take advantage of the internal data structure of the hosts they are 333 implemented on, or are just plain broken. 334 335 336 337 338 Freed & Borenstein Standards Track [Page 6] 339 340 RFC 2049 MIME Conformance November 1996 341 342 343 The following guidelines may be useful to anyone devising a data 344 format (media type) that is supposed to survive the widest range of 345 networking technologies and known broken MTAs unscathed. Note that 346 anything encoded in the base64 encoding will satisfy these rules, but 347 that some well-known mechanisms, notably the UNIX uuencode facility, 348 will not. Note also that anything encoded in the Quoted-Printable 349 encoding will survive most gateways intact, but possibly not some 350 gateways to systems that use the EBCDIC character set. 351 352 (1) Under some circumstances the encoding used for data may 353 change as part of normal gateway or user agent 354 operation. In particular, conversion from base64 to 355 quoted-printable and vice versa may be necessary. This 356 may result in the confusion of CRLF sequences with line 357 breaks in text bodies. As such, the persistence of 358 CRLF as something other than a line break must not be 359 relied on. 360 361 (2) Many systems may elect to represent and store text data 362 using local newline conventions. Local newline 363 conventions may not match the RFC822 CRLF convention -- 364 systems are known that use plain CR, plain LF, CRLF, or 365 counted records. The result is that isolated CR and LF 366 characters are not well tolerated in general; they may 367 be lost or converted to delimiters on some systems, and 368 hence must not be relied on. 369 370 (3) The transmission of NULs (US-ASCII value 0) is 371 problematic in Internet mail. (This is largely the 372 result of NULs being used as a termination character by 373 many of the standard runtime library routines in the C 374 programming language.) The practice of using NULs as 375 termination characters is so entrenched now that 376 messages should not rely on them being preserved. 377 378 (4) TAB (HT) characters may be misinterpreted or may be 379 automatically converted to variable numbers of spaces. 380 This is unavoidable in some environments, notably those 381 not based on the US-ASCII character set. Such 382 conversion is STRONGLY DISCOURAGED, but it may occur, 383 and mail formats must not rely on the persistence of 384 TAB (HT) characters. 385 386 (5) Lines longer than 76 characters may be wrapped or 387 truncated in some environments. Line wrapping or line 388 truncation imposed by mail transports is STRONGLY 389 DISCOURAGED, but unavoidable in some cases. 390 Applications which require long lines must somehow 391 392 393 394 Freed & Borenstein Standards Track [Page 7] 395 396 RFC 2049 MIME Conformance November 1996 397 398 399 differentiate between soft and hard line breaks. (A 400 simple way to do this is to use the quoted-printable 401 encoding.) 402 403 (6) Trailing "white space" characters (SPACE, TAB (HT)) on 404 a line may be discarded by some transport agents, while 405 other transport agents may pad lines with these 406 characters so that all lines in a mail file are of 407 equal length. The persistence of trailing white space, 408 therefore, must not be relied on. 409 410 (7) Many mail domains use variations on the US-ASCII 411 character set, or use character sets such as EBCDIC 412 which contain most but not all of the US-ASCII 413 characters. The correct translation of characters not 414 in the "invariant" set cannot be depended on across 415 character converting gateways. For example, this 416 situation is a problem when sending uuencoded 417 information across BITNET, an EBCDIC system. Similar 418 problems can occur without crossing a gateway, since 419 many Internet hosts use character sets other than US- 420 ASCII internally. The definition of Printable Strings 421 in X.400 adds further restrictions in certain special 422 cases. In particular, the only characters that are 423 known to be consistent across all gateways are the 73 424 characters that correspond to the upper and lower case 425 letters A-Z and a-z, the 10 digits 0-9, and the 426 following eleven special characters: 427 428 "'" (US-ASCII decimal value 39) 429 "(" (US-ASCII decimal value 40) 430 ")" (US-ASCII decimal value 41) 431 "+" (US-ASCII decimal value 43) 432 "," (US-ASCII decimal value 44) 433 "-" (US-ASCII decimal value 45) 434 "." (US-ASCII decimal value 46) 435 "/" (US-ASCII decimal value 47) 436 ":" (US-ASCII decimal value 58) 437 "=" (US-ASCII decimal value 61) 438 "?" (US-ASCII decimal value 63) 439 440 A maximally portable mail representation will confine 441 itself to relatively short lines of text in which the 442 only meaningful characters are taken from this set of 443 73 characters. The base64 encoding follows this rule. 444 445 (8) Some mail transport agents will corrupt data that 446 includes certain literal strings. In particular, a 447 448 449 450 Freed & Borenstein Standards Track [Page 8] 451 452 RFC 2049 MIME Conformance November 1996 453 454 455 period (".") alone on a line is known to be corrupted 456 by some (incorrect) SMTP implementations, and a line 457 that starts with the five characters "From " (the fifth 458 character is a SPACE) are commonly corrupted as well. 459 A careful composition agent can prevent these 460 corruptions by encoding the data (e.g., in the quoted- 461 printable encoding using "=46rom " in place of "From " 462 at the start of a line, and "=2E" in place of "." alone 463 on a line). 464 465 Please note that the above list is NOT a list of recommended 466 practices for MTAs. RFC 821 MTAs are prohibited from altering the 467 character of white space or wrapping long lines. These BAD and 468 invalid practices are known to occur on established networks, and 469 implementations should be robust in dealing with the bad effects they 470 can cause. 471 472 4. Canonical Encoding Model 473 474 There was some confusion, in earlier versions of these documents, 475 regarding the model for when email data was to be converted to 476 canonical form and encoded, and in particular how this process would 477 affect the treatment of CRLFs, given that the representation of 478 newlines varies greatly from system to system. For this reason, a 479 canonical model for encoding is presented below. 480 481 The process of composing a MIME entity can be modeled as being done 482 in a number of steps. Note that these steps are roughly similar to 483 those steps used in PEM [RFC-1421] and are performed for each 484 "innermost level" body: 485 486 (1) Creation of local form. 487 488 The body to be transmitted is created in the system's 489 native format. The native character set is used and, 490 where appropriate, local end of line conventions are 491 used as well. The body may be a UNIX-style text file, 492 or a Sun raster image, or a VMS indexed file, or audio 493 data in a system-dependent format stored only in 494 memory, or anything else that corresponds to the local 495 model for the representation of some form of 496 information. Fundamentally, the data is created in the 497 "native" form that corresponds to the type specified by 498 the media type. 499 500 501 502 503 504 505 506 Freed & Borenstein Standards Track [Page 9] 507 508 RFC 2049 MIME Conformance November 1996 509 510 511 (2) Conversion to canonical form. 512 513 The entire body, including "out-of-band" information 514 such as record lengths and possibly file attribute 515 information, is converted to a universal canonical 516 form. The specific media type of the body as well as 517 its associated attributes dictate the nature of the 518 canonical form that is used. Conversion to the proper 519 canonical form may involve character set conversion, 520 transformation of audio data, compression, or various 521 other operations specific to the various media types. 522 If character set conversion is involved, however, care 523 must be taken to understand the semantics of the media 524 type, which may have strong implications for any 525 character set conversion, e.g. with regard to 526 syntactically meaningful characters in a text subtype 527 other than "plain". 528 529 For example, in the case of text/plain data, the text 530 must be converted to a supported character set and 531 lines must be delimited with CRLF delimiters in 532 accordance with RFC 822. Note that the restriction on 533 line lengths implied by RFC 822 is eliminated if the 534 next step employs either quoted-printable or base64 535 encoding. 536 537 (3) Apply transfer encoding. 538 539 A Content-Transfer-Encoding appropriate for this body 540 is applied. Note that there is no fixed relationship 541 between the media type and the transfer encoding. In 542 particular, it may be appropriate to base the choice of 543 base64 or quoted-printable on character frequency 544 counts which are specific to a given instance of a 545 body. 546 547 (4) Insertion into entity. 548 549 The encoded body is inserted into a MIME entity with 550 appropriate headers. The entity is then inserted into 551 the body of a higher-level entity (message or 552 multipart) as needed. 553 554 Conversion from entity form to local form is accomplished by 555 reversing these steps. Note that reversal of these steps may produce 556 differing results since there is no guarantee that the original and 557 final local forms are the same. 558 559 560 561 562 Freed & Borenstein Standards Track [Page 10] 563 564 RFC 2049 MIME Conformance November 1996 565 566 567 It is vital to note that these steps are only a model; they are 568 specifically NOT a blueprint for how an actual system would be built. 569 In particular, the model fails to account for two common designs: 570 571 (1) In many cases the conversion to a canonical form prior 572 to encoding will be subsumed into the encoder itself, 573 which understands local formats directly. For example, 574 the local newline convention for text bodies might be 575 carried through to the encoder itself along with 576 knowledge of what that format is. 577 578 (2) The output of the encoders may have to pass through one 579 or more additional steps prior to being transmitted as 580 a message. As such, the output of the encoder may not 581 be conformant with the formats specified by RFC 822. 582 In particular, once again it may be appropriate for the 583 converter's output to be expressed using local newline 584 conventions rather than using the standard RFC 822 CRLF 585 delimiters. 586 587 Other implementation variations are conceivable as well. The vital 588 aspect of this discussion is that, in spite of any optimizations, 589 collapsings of required steps, or insertion of additional processing, 590 the resulting messages must be consistent with those produced by the 591 model described here. For example, a message with the following 592 header fields: 593 594 Content-type: text/foo; charset=bar 595 Content-Transfer-Encoding: base64 596 597 must be first represented in the text/foo form, then (if necessary) 598 represented in the "bar" character set, and finally transformed via 599 the base64 algorithm into a mail-safe form. 600 601 NOTE: Some confusion has been caused by systems that represent 602 messages in a format which uses local newline conventions which 603 differ from the RFC822 CRLF convention. It is important to note that 604 these formats are not canonical RFC822/MIME. These formats are 605 instead *encodings* of RFC822, where CRLF sequences in the canonical 606 representation of the message are encoded as the local newline 607 convention. Note that formats which encode CRLF sequences as, for 608 example, LF are not capable of representing MIME messages containing 609 binary data which contains LF octets not part of CRLF line separation 610 sequences. 611 612 613 614 615 616 617 618 Freed & Borenstein Standards Track [Page 11] 619 620 RFC 2049 MIME Conformance November 1996 621 622 623 5. Summary 624 625 This document defines what is meant by MIME Conformance. It also 626 details various problems known to exist in the Internet email system 627 and how to use MIME to overcome them. Finally, it describes MIME's 628 canonical encoding model. 629 630 6. Security Considerations 631 632 Security issues are discussed in the second document in this set, RFC 633 2046. 634 635 7. Authors' Addresses 636 637 For more information, the authors of this document are best contacted 638 via Internet mail: 639 640 Ned Freed 641 Innosoft International, Inc. 642 1050 East Garvey Avenue South 643 West Covina, CA 91790 644 USA 645 646 Phone: +1 818 919 3600 647 Fax: +1 818 919 3614 648 EMail: ned@innosoft.com 649 650 Nathaniel S. Borenstein 651 First Virtual Holdings 652 25 Washington Avenue 653 Morristown, NJ 07960 654 USA 655 656 Phone: +1 201 540 8967 657 Fax: +1 201 993 3032 658 EMail: nsb@nsb.fv.com 659 660 MIME is a result of the work of the Internet Engineering Task Force 661 Working Group on RFC 822 Extensions. The chairman of that group, 662 Greg Vaudreuil, may be reached at: 663 664 Gregory M. Vaudreuil 665 Octel Network Services 666 17080 Dallas Parkway 667 Dallas, TX 75248-1905 668 USA 669 670 EMail: Greg.Vaudreuil@Octel.Com 671 672 673 674 Freed & Borenstein Standards Track [Page 12] 675 676 RFC 2049 MIME Conformance November 1996 677 678 679 8. Acknowledgements 680 681 This document is the result of the collective effort of a large 682 number of people, at several IETF meetings, on the IETF-SMTP and 683 IETF-822 mailing lists, and elsewhere. Although any enumeration 684 seems doomed to suffer from egregious omissions, the following are 685 among the many contributors to this effort: 686 687 Harald Tveit Alvestrand Marc Andreessen 688 Randall Atkinson Bob Braden 689 Philippe Brandon Brian Capouch 690 Kevin Carosso Uhhyung Choi 691 Peter Clitherow Dave Collier-Brown 692 Cristian Constantinof John Coonrod 693 Mark Crispin Dave Crocker 694 Stephen Crocker Terry Crowley 695 Walt Daniels Jim Davis 696 Frank Dawson Axel Deininger 697 Hitoshi Doi Kevin Donnelly 698 Steve Dorner Keith Edwards 699 Chris Eich Dana S. Emery 700 Johnny Eriksson Craig Everhart 701 Patrik Faltstrom Erik E. Fair 702 Roger Fajman Alain Fontaine 703 Martin Forssen James M. Galvin 704 Stephen Gildea Philip Gladstone 705 Thomas Gordon Keld Simonsen 706 Terry Gray Phill Gross 707 James Hamilton David Herron 708 Mark Horton Bruce Howard 709 Bill Janssen Olle Jarnefors 710 Risto Kankkunen Phil Karn 711 Alan Katz Tim Kehres 712 Neil Katin Steve Kille 713 Kyuho Kim Anders Klemets 714 John Klensin Valdis Kletniek 715 Jim Knowles Stev Knowles 716 Bob Kummerfeld Pekka Kytolaakso 717 Stellan Lagerstrom Vincent Lau 718 Timo Lehtinen Donald Lindsay 719 Warner Losh Carlyn Lowery 720 Laurence Lundblade Charles Lynn 721 John R. MacMillan Larry Masinter 722 Rick McGowan Michael J. McInerny 723 Leo Mclaughlin Goli Montaser-Kohsari 724 Tom Moore John Gardiner Myers 725 Erik Naggum Mark Needleman 726 Chris Newman John Noerenberg 727 728 729 730 Freed & Borenstein Standards Track [Page 13] 731 732 RFC 2049 MIME Conformance November 1996 733 734 735 Mats Ohrman Julian Onions 736 Michael Patton David J. Pepper 737 Erik van der Poel Blake C. Ramsdell 738 Christer Romson Luc Rooijakkers 739 Marshall T. Rose Jonathan Rosenberg 740 Guido van Rossum Jan Rynning 741 Harri Salminen Michael Sanderson 742 Yutaka Sato Markku Savela 743 Richard Alan Schafer Masahiro Sekiguchi 744 Mark Sherman Bob Smart 745 Peter Speck Henry Spencer 746 Einar Stefferud Michael Stein 747 Klaus Steinberger Peter Svanberg 748 James Thompson Steve Uhler 749 Stuart Vance Peter Vanderbilt 750 Greg Vaudreuil Ed Vielmetti 751 Larry W. Virden Ryan Waldron 752 Rhys Weatherly Jay Weber 753 Dave Wecker Wally Wedel 754 Sven-Ove Westberg Brian Wideen 755 John Wobus Glenn Wright 756 Rayan Zachariassen David Zimmerman 757 758 The authors apologize for any omissions from this list, which are 759 certainly unintentional. 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 Freed & Borenstein Standards Track [Page 14] 787 788 RFC 2049 MIME Conformance November 1996 789 790 791 Appendix A -- A Complex Multipart Example 792 793 What follows is the outline of a complex multipart message. This 794 message contains five parts that are to be displayed serially: two 795 introductory plain text objects, an embedded multipart message, a 796 text/enriched object, and a closing encapsulated text message in a 797 non-ASCII character set. The embedded multipart message itself 798 contains two objects to be displayed in parallel, a picture and an 799 audio fragment. 800 801 MIME-Version: 1.0 802 From: Nathaniel Borenstein <nsb@nsb.fv.com> 803 To: Ned Freed <ned@innosoft.com> 804 Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) 805 Subject: A multipart example 806 Content-Type: multipart/mixed; 807 boundary=unique-boundary-1 808 809 This is the preamble area of a multipart message. 810 Mail readers that understand multipart format 811 should ignore this preamble. 812 813 If you are reading this text, you might want to 814 consider changing to a mail reader that understands 815 how to properly display multipart messages. 816 817 --unique-boundary-1 818 819 ... Some text appears here ... 820 821 [Note that the blank between the boundary and the start 822 of the text in this part means no header fields were 823 given and this is text in the US-ASCII character set. 824 It could have been done with explicit typing as in the 825 next part.] 826 827 --unique-boundary-1 828 Content-type: text/plain; charset=US-ASCII 829 830 This could have been part of the previous part, but 831 illustrates explicit versus implicit typing of body 832 parts. 833 834 --unique-boundary-1 835 Content-Type: multipart/parallel; boundary=unique-boundary-2 836 837 --unique-boundary-2 838 Content-Type: audio/basic 839 840 841 842 Freed & Borenstein Standards Track [Page 15] 843 844 RFC 2049 MIME Conformance November 1996 845 846 847 Content-Transfer-Encoding: base64 848 849 ... base64-encoded 8000 Hz single-channel 850 mu-law-format audio data goes here ... 851 852 --unique-boundary-2 853 Content-Type: image/jpeg 854 Content-Transfer-Encoding: base64 855 856 ... base64-encoded image data goes here ... 857 858 --unique-boundary-2-- 859 860 --unique-boundary-1 861 Content-type: text/enriched 862 863 This is <bold><italic>enriched.</italic></bold> 864 <smaller>as defined in RFC 1896</smaller> 865 866 Isn't it 867 <bigger><bigger>cool?</bigger></bigger> 868 869 --unique-boundary-1 870 Content-Type: message/rfc822 871 872 From: (mailbox in US-ASCII) 873 To: (address in US-ASCII) 874 Subject: (subject in US-ASCII) 875 Content-Type: Text/plain; charset=ISO-8859-1 876 Content-Transfer-Encoding: Quoted-printable 877 878 ... Additional text in ISO-8859-1 goes here ... 879 880 --unique-boundary-1-- 881 882 Appendix B -- Changes from RFC 1521, 1522, and 1590 883 884 These documents are a revision of RFC 1521, 1522, and 1590. For the 885 convenience of those familiar with the earlier documents, the changes 886 from those documents are summarized in this appendix. For further 887 history, note that Appendix H in RFC 1521 specified how that document 888 differed from its predecessor, RFC 1341. 889 890 (1) This document has been completely reformatted and split 891 into multiple documents. This was done to improve the 892 quality of the plain text version of this document, 893 which is required to be the reference copy. 894 895 896 897 898 Freed & Borenstein Standards Track [Page 16] 899 900 RFC 2049 MIME Conformance November 1996 901 902 903 (2) BNF describing the overall structure of MIME object 904 headers has been added. This is a documentation change 905 only -- the underlying syntax has not changed in any 906 way. 907 908 (3) The specific BNF for the seven media types in MIME has 909 been removed. This BNF was incorrect, incomplete, amd 910 inconsistent with the type-indendependent BNF. And 911 since the type-independent BNF already fully specifies 912 the syntax of the various MIME headers, the type- 913 specific BNF was, in the final analysis, completely 914 unnecessary and caused more problems than it solved. 915 916 (4) The more specific "US-ASCII" character set name has 917 replaced the use of the informal term ASCII in many 918 parts of these documents. 919 920 (5) The informal concept of a primary subtype has been 921 removed. 922 923 (6) The term "object" was being used inconsistently. The 924 definition of this term has been clarified, along with 925 the related terms "body", "body part", and "entity", 926 and usage has been corrected where appropriate. 927 928 (7) The BNF for the multipart media type has been 929 rearranged to make it clear that the CRLF preceeding 930 the boundary marker is actually part of the marker 931 itself rather than the preceeding body part. 932 933 (8) The prose and BNF describing the multipart media type 934 have been changed to make it clear that the body parts 935 within a multipart object MUST NOT contain any lines 936 beginning with the boundary parameter string. 937 938 (9) In the rules on reassembling "message/partial" MIME 939 entities, "Subject" is added to the list of headers to 940 take from the inner message, and the example is 941 modified to clarify this point. 942 943 (10) "Message/partial" fragmenters are restricted to 944 splitting MIME objects only at line boundaries. 945 946 (11) In the discussion of the application/postscript type, 947 an additional paragraph has been added warning about 948 possible interoperability problems caused by embedding 949 of binary data inside a PostScript MIME entity. 950 951 952 953 954 Freed & Borenstein Standards Track [Page 17] 955 956 RFC 2049 MIME Conformance November 1996 957 958 959 (12) Added a clarifying note to the basic syntax rules for 960 the Content-Type header field to make it clear that the 961 following two forms: 962 963 Content-type: text/plain; charset=us-ascii (comment) 964 965 Content-type: text/plain; charset="us-ascii" 966 967 are completely equivalent. 968 969 (13) The following sentence has been removed from the 970 discussion of the MIME-Version header: "However, 971 conformant software is encouraged to check the version 972 number and at least warn the user if an unrecognized 973 MIME-version is encountered." 974 975 (14) A typo was fixed that said "application/external-body" 976 instead of "message/external-body". 977 978 (15) The definition of a character set has been reorganized 979 to make the requirements clearer. 980 981 (16) The definition of the "image/gif" media type has been 982 moved to a separate document. This change was made 983 because of potential conflicts with IETF rules 984 governing the standardization of patented technology. 985 986 (17) The definitions of "7bit" and "8bit" have been 987 tightened so that use of bare CR, LF can only be used 988 as end-of-line sequences. The document also no longer 989 requires that NUL characters be preserved, which brings 990 MIME into alignment with real-world implementations. 991 992 (18) The definition of canonical text in MIME has been 993 tightened so that line breaks must be represented by a 994 CRLF sequence. CR and LF characters are not allowed 995 outside of this usage. The definition of quoted- 996 printable encoding has been altered accordingly. 997 998 (19) The definition of the quoted-printable encoding now 999 includes a number of suggestions for how quoted- 1000 printable encoders might best handle improperly encoded 1001 material. 1002 1003 (20) Prose was added to clarify the use of the "7bit", 1004 "8bit", and "binary" transfer-encodings on multipart or 1005 message entities encapsulating "8bit" or "binary" data. 1006 1007 1008 1009 1010 Freed & Borenstein Standards Track [Page 18] 1011 1012 RFC 2049 MIME Conformance November 1996 1013 1014 1015 (21) In the section on MIME Conformance, "multipart/digest" 1016 support was added to the list of requirements for 1017 minimal MIME conformance. Also, the requirement for 1018 "message/rfc822" support were strengthened to clarify 1019 the importance of recognizing recursive structure. 1020 1021 (22) The various restrictions on subtypes of "message" are 1022 now specified entirely on a subtype by subtype basis. 1023 1024 (23) The definition of "message/rfc822" was changed to 1025 indicate that at least one of the "From", "Subject", or 1026 "Date" headers must be present. 1027 1028 (24) The required handling of unrecognized subtypes as 1029 "application/octet-stream" has been made more explicit 1030 in both the type definitions sections and the 1031 conformance guidelines. 1032 1033 (25) Examples using text/richtext were changed to 1034 text/enriched. 1035 1036 (26) The BNF definition of subtype has been changed to make 1037 it clear that either an IANA registered subtype or a 1038 nonstandard "X-" subtype must be used in a Content-Type 1039 header field. 1040 1041 (27) MIME media types that are simply registered for use and 1042 those that are standardized by the IETF are now 1043 distinguished in the MIME BNF. 1044 1045 (28) All of the various MIME registration procedures have 1046 been extensively revised. IANA registration procedures 1047 for character sets have been moved to a separate 1048 document that is no included in this set of documents. 1049 1050 (29) The use of escape and shift mechanisms in the US-ASCII 1051 and ISO-8859-X character sets these documents define 1052 have been clarified: Such mechanisms should never be 1053 used in conjunction with these character sets and their 1054 effect if they are used is undefined. 1055 1056 (30) The definition of the AFS access-type for 1057 message/external-body has been removed. 1058 1059 (31) The handling of the combination of 1060 multipart/alternative and message/external-body is now 1061 specifically addressed. 1062 1063 1064 1065 1066 Freed & Borenstein Standards Track [Page 19] 1067 1068 RFC 2049 MIME Conformance November 1996 1069 1070 1071 (32) Security issues specific to message/external-body are 1072 now discussed in some detail. 1073 1074 Appendix C -- References 1075 1076 [ATK] 1077 Borenstein, Nathaniel S., Multimedia Applications 1078 Development with the Andrew Toolkit, Prentice-Hall, 1990. 1079 1080 [ISO-2022] 1081 International Standard -- Information Processing -- 1082 Character Code Structure and Extension Techniques, 1083 ISO/IEC 2022:1994, 4th ed. 1084 1085 [ISO-8859] 1086 International Standard -- Information Processing -- 8-bit 1087 Single-Byte Coded Graphic Character Sets 1088 - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed. 1089 - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed. 1090 - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed. 1091 - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed. 1092 - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st 1093 ed. 1094 - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed. 1095 - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed. 1096 - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed. 1097 - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st 1098 ed. 1099 International Standard -- Information Technology -- 8-bit 1100 Single-Byte Coded Graphic Character Sets 1101 - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1102 1st ed. 1103 1104 [ISO-646] 1105 International Standard -- Information Technology -- ISO 1106 7-bit Coded Character Set for Information Interchange, 1107 ISO 646:1991, 3rd ed.. 1108 1109 [JPEG] 1110 JPEG Draft Standard ISO 10918-1 CD. 1111 1112 [MPEG] 1113 Video Coding Draft Standard ISO 11172 CD, ISO 1114 IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 1115 1991. 1116 1117 1118 1119 1120 1121 1122 Freed & Borenstein Standards Track [Page 20] 1123 1124 RFC 2049 MIME Conformance November 1996 1125 1126 1127 [PCM] 1128 CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code 1129 Modulation (PCM) of Voice Frequencies", Geneva, 1972. 1130 1131 [POSTSCRIPT] 1132 Adobe Systems, Inc., PostScript Language Reference 1133 Manual, Addison-Wesley, 1985. 1134 1135 [POSTSCRIPT2] 1136 Adobe Systems, Inc., PostScript Language Reference 1137 Manual, Addison-Wesley, Second Ed., 1990. 1138 1139 [RFC-783] 1140 Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, 1141 MIT, June 1981. 1142 1143 [RFC-821] 1144 Postel, J.B., "Simple Mail Transfer Protocol", STD 10, 1145 RFC 821, USC/Information Sciences Institute, August 1982. 1146 1147 [RFC-822] 1148 Crocker, D., "Standard for the Format of ARPA Internet 1149 Text Messages", STD 11, RFC 822, UDEL, August 1982. 1150 1151 [RFC-934] 1152 Rose, M. and E. Stefferud, "Proposed Standard for Message 1153 Encapsulation", RFC 934, Delaware and NMA, January 1985. 1154 1155 [RFC-959] 1156 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 1157 9, RFC 959, USC/Information Sciences Institute, October 1158 1985. 1159 1160 [RFC-1049] 1161 Sirbu, M., "Content-Type Header Field for Internet 1162 Messages", RFC 1049, CMU, March 1988. 1163 1164 [RFC-1154] 1165 Robinson, D., and R. Ullmann, "Encoding Header Field for 1166 Internet Messages", RFC 1154, Prime Computer, Inc., April 1167 1990. 1168 1169 [RFC-1341] 1170 Borenstein, N., and N. Freed, "MIME (Multipurpose 1171 Internet Mail Extensions): Mechanisms for Specifying and 1172 Describing the Format of Internet Message Bodies", RFC 1173 1341, Bellcore, Innosoft, June 1992. 1174 1175 1176 1177 1178 Freed & Borenstein Standards Track [Page 21] 1179 1180 RFC 2049 MIME Conformance November 1996 1181 1182 1183 [RFC-1342] 1184 Moore, K., "Representation of Non-Ascii Text in Internet 1185 Message Headers", RFC 1342, University of Tennessee, June 1186 1992. 1187 1188 [RFC-1344] 1189 Borenstein, N., "Implications of MIME for Internet Mail 1190 Gateways", RFC 1344, Bellcore, June 1992. 1191 1192 [RFC-1345] 1193 Simonsen, K., "Character Mnemonics & Character Sets", RFC 1194 1345, Rationel Almen Planlaegning, June 1992. 1195 1196 [RFC-1421] 1197 Linn, J., "Privacy Enhancement for Internet Electronic 1198 Mail: Part I -- Message Encryption and Authentication 1199 Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, 1200 February 1993. 1201 1202 [RFC-1422] 1203 Kent, S., "Privacy Enhancement for Internet Electronic 1204 Mail: Part II -- Certificate-Based Key Management", RFC 1205 1422, IAB IRTF PSRG, IETF PEM WG, February 1993. 1206 1207 [RFC-1423] 1208 Balenson, D., "Privacy Enhancement for Internet 1209 Electronic Mail: Part III -- Algorithms, Modes, and 1210 Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. 1211 1212 [RFC-1424] 1213 Kaliski, B., "Privacy Enhancement for Internet Electronic 1214 Mail: Part IV -- Key Certification and Related 1215 Services", IAB IRTF PSRG, IETF PEM WG, February 1993. 1216 1217 [RFC-1521] 1218 Borenstein, N., and Freed, N., "MIME (Multipurpose 1219 Internet Mail Extensions): Mechanisms for Specifying and 1220 Describing the Format of Internet Message Bodies", RFC 1221 1521, Bellcore, Innosoft, September, 1993. 1222 1223 [RFC-1522] 1224 Moore, K., "Representation of Non-ASCII Text in Internet 1225 Message Headers", RFC 1522, University of Tennessee, 1226 September 1993. 1227 1228 1229 1230 1231 1232 1233 1234 Freed & Borenstein Standards Track [Page 22] 1235 1236 RFC 2049 MIME Conformance November 1996 1237 1238 1239 [RFC-1524] 1240 Borenstein, N., "A User Agent Configuration Mechanism for 1241 Multimedia Mail Format Information", RFC 1524, Bellcore, 1242 September 1993. 1243 1244 [RFC-1543] 1245 Postel, J., "Instructions to RFC Authors", RFC 1543, 1246 USC/Information Sciences Institute, October 1993. 1247 1248 [RFC-1556] 1249 Nussbacher, H., "Handling of Bi-directional Texts in 1250 MIME", RFC 1556, Israeli Inter-University Computer 1251 Center, December 1993. 1252 1253 [RFC-1590] 1254 Postel, J., "Media Type Registration Procedure", RFC 1255 1590, USC/Information Sciences Institute, March 1994. 1256 1257 [RFC-1602] 1258 Internet Architecture Board, Internet Engineering 1259 Steering Group, Huitema, C., Gross, P., "The Internet 1260 Standards Process -- Revision 2", March 1994. 1261 1262 [RFC-1652] 1263 Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., 1264 Stefferud, E., and Crocker, D., "SMTP Service Extension 1265 for 8bit-MIME transport", RFC 1652, United Nations 1266 University, Innosoft, Dover Beach Consulting, Inc., 1267 Network Management Associates, Inc., The Branch Office, 1268 March 1994. 1269 1270 [RFC-1700] 1271 Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 1272 RFC 1700, USC/Information Sciences Institute, October 1273 1994. 1274 1275 [RFC-1741] 1276 Faltstrom, P., Crocker, D., and Fair, E., "MIME Content 1277 Type for BinHex Encoded Files", December 1994. 1278 1279 [RFC-1896] 1280 Resnick, P., and A. Walker, "The text/enriched MIME 1281 Content-type", RFC 1896, February, 1996. 1282 1283 1284 1285 1286 1287 1288 1289 1290 Freed & Borenstein Standards Track [Page 23] 1291 1292 RFC 2049 MIME Conformance November 1996 1293 1294 1295 [RFC-2045] 1296 Freed, N., and and N. Borenstein, "Multipurpose Internet Mail 1297 Extensions (MIME) Part One: Format of Internet Message 1298 Bodies", RFC 2045, Innosoft, First Virtual Holdings, 1299 November 1996. 1300 1301 [RFC-2046] 1302 Freed, N., and N. Borenstein, "Multipurpose Internet Mail 1303 Extensions (MIME) Part Two: Media Types", RFC 2046, 1304 Innosoft, First Virtual Holdings, November 1996. 1305 1306 [RFC-2047] 1307 Moore, K., "Multipurpose Internet Mail Extensions (MIME) 1308 Part Three: Representation of Non-ASCII Text in Internet 1309 Message Headers", RFC 2047, University of 1310 Tennessee, November 1996. 1311 1312 [RFC-2048] 1313 Freed, N., Klensin, J., and J. Postel, "Multipurpose 1314 Internet Mail Extensions (MIME) Part Four: MIME 1315 Registration Procedures", RFC 2048, Innosoft, MCI, 1316 ISI, November 1996. 1317 1318 [RFC-2049] 1319 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1320 Extensions (MIME) Part Five: Conformance Criteria and 1321 Examples", RFC 2049 (this document), Innosoft, First 1322 Virtual Holdings, November 1996. 1323 1324 [US-ASCII] 1325 Coded Character Set -- 7-Bit American Standard Code for 1326 Information Interchange, ANSI X3.4-1986. 1327 1328 [X400] 1329 Schicker, Pietro, "Message Handling Systems, X.400", 1330 Message Handling Systems and Distributed Applications, E. 1331 Stefferud, O-j. Jacobsen, and P. Schicker, eds., North- 1332 Holland, 1989, pp. 3-41. 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 Freed & Borenstein Standards Track [Page 24] 1347