idnits 2.17.1 draft-ietf-822ext-mime-conf-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 723: '...multipart entity MUST NOT contain any ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 103 has weird spacing: '...ortions of MI...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 1995) is 10579 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC821' on line 132 looks like a reference -- Missing reference section? 'RFC1421' on line 378 looks like a reference -- Missing reference section? 'ATK' on line 827 looks like a reference -- Missing reference section? 'ISO-2022' on line 831 looks like a reference -- Missing reference section? 'ISO-8859' on line 836 looks like a reference -- Missing reference section? 'ISO-646' on line 848 looks like a reference -- Missing reference section? 'MPEG' on line 853 looks like a reference -- Missing reference section? 'PCM' on line 858 looks like a reference -- Missing reference section? 'POSTSCRIPT' on line 862 looks like a reference -- Missing reference section? 'POSTSCRIPT2' on line 866 looks like a reference -- Missing reference section? 'RFC-783' on line 870 looks like a reference -- Missing reference section? 'RFC-821' on line 874 looks like a reference -- Missing reference section? 'RFC-822' on line 878 looks like a reference -- Missing reference section? 'RFC-934' on line 882 looks like a reference -- Missing reference section? 'RFC-959' on line 886 looks like a reference -- Missing reference section? 'RFC-1049' on line 891 looks like a reference -- Missing reference section? 'RFC-1154' on line 895 looks like a reference -- Missing reference section? 'RFC-1341' on line 900 looks like a reference -- Missing reference section? 'RFC-1342' on line 906 looks like a reference -- Missing reference section? 'RFC-1344' on line 911 looks like a reference -- Missing reference section? 'RFC-1345' on line 915 looks like a reference -- Missing reference section? 'RFC-1421' on line 919 looks like a reference -- Missing reference section? 'RFC-1422' on line 925 looks like a reference -- Missing reference section? 'RFC-1423' on line 930 looks like a reference -- Missing reference section? 'RFC-1424' on line 935 looks like a reference -- Missing reference section? 'RFC-1521' on line 940 looks like a reference -- Missing reference section? 'RFC-1522' on line 946 looks like a reference -- Missing reference section? 'RFC-1524' on line 951 looks like a reference -- Missing reference section? 'RFC-1543' on line 956 looks like a reference -- Missing reference section? 'RFC-1563' on line 960 looks like a reference -- Missing reference section? 'RFC-1590' on line 964 looks like a reference -- Missing reference section? 'RFC-1602' on line 968 looks like a reference -- Missing reference section? 'RFC-1652' on line 973 looks like a reference -- Missing reference section? 'RFC-1700' on line 981 looks like a reference -- Missing reference section? 'RFC-MIME-IMB' on line 986 looks like a reference -- Missing reference section? 'RFC-MIME-IMT' on line 991 looks like a reference -- Missing reference section? 'RFC-MIME-HEADERS' on line 996 looks like a reference -- Missing reference section? 'RFC-MIME-REG' on line 1002 looks like a reference -- Missing reference section? 'RFC-MIME-CONF' on line 1007 looks like a reference -- Missing reference section? 'US-ASCII' on line 1013 looks like a reference -- Missing reference section? 'X400' on line 1017 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 43 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nathaniel Borenstein 2 Internet Draft Ned Freed 3 5 Multipurpose Internet Mail Extensions 6 (MIME) Part Five: 8 Conformance Criteria and Examples 10 April 11, 1995 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are 15 working documents of the Internet Engineering Task Force 16 (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet-Drafts as reference material or to cite them other 24 than as a "working draft" or "work in progress". 26 To learn the current status of any Internet-Draft, please 27 check the 1id-abstracts.txt listing contained in the 28 Internet-Drafts Shadow Directories on ds.internic.net (US East 29 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 30 or munnari.oz.au (Pacific Rim). 32 1. Abstract 34 STD 11, RFC 822, defines a message representation protocol 35 specifying considerable detail about US-ASCII message headers, 36 and leaves the message content, or message body, as flat US- 37 ASCII text. This set of documents, collectively called the 38 Multipurpose Internet Mail Extensions, or MIME, redefines the 39 format of messages to allow for 40 (1) textual message bodies in character sets other than 41 US-ASCII, 43 (2) non-textual message bodies, 45 (3) multi-part message bodies, and 47 (4) textual header information in character sets other than 48 US-ASCII. 50 These documents are based on earlier work documented in RFC 51 934, STD 11, and RFC 1049, but extends and revises them. 52 Because RFC 822 said so little about message bodies, these 53 documents are largely orthogonal to (rather than a revision 54 of) RFC 822. 56 In particular, these documents are designed to provide 57 facilities to include multiple parts in a single message, to 58 represent body and header text in character sets other than 59 US-ASCII, to represent formatted multi-font text messages, to 60 represent non-textual material such as images and audio 61 fragments, and generally to facilitate later extensions 62 defining new types of Internet mail for use by cooperating 63 mail agents. 65 The initial document in this set, RFC MIME-IMB, specifies the 66 various headers used to describe the structure of MIME 67 messages. The second document defines the general structure of 68 the MIME media typing system and defines an initial set of 69 media types. The third document, RFC MIME-HEADERS, describes 70 extensions to RFC 822 to allow non-US-ASCII text data in 71 Internet mail header fields. The fourth document, RFC MIME- 72 REG, specifies various IANA registration procedures for MIME- 73 related entities. This fifth and final document describes MIME 74 conformance criteria as well as providing some illustrative 75 examples of MIME message formats, acknowledgements, and the 76 bibliography. 78 These documents are revisions of RFCs 1521, 1522, and 1590, 79 which themselves were revisions of RFCs 1341 and 1342. 80 Appendix B of this document describes differences and changes 81 from previous versions. 83 2. Table of Contents 85 1 Abstract .............................................. 1 86 2 Table of Contents ..................................... 3 87 3 Introduction .......................................... 3 88 4 MIME Conformance ...................................... 3 89 5 Guidelines for Sending Email Data ..................... 6 90 6 Canonical Encoding Model .............................. 9 91 7 Summary ............................................... 11 92 8 Security Considerations ............................... 12 93 9 Authors' Addresses .................................... 12 94 10 Acknowledgements ..................................... 13 95 A A Complex Multipart Example ........................... 15 96 B Changes from RFC 1521, 1522, and 1590 ................. 17 97 C References ............................................ 21 99 3. Introduction 101 The first and second documents in this set defined MIME header 102 field and the initial set of MIME media types. This document 103 describes what portions of MIME must be supported by a 104 conformant MIME implementation. It also describes various 105 pitfalls of contemporary messaging systems as well as the 106 canonical encoding model MIME is based on. 108 4. MIME Conformance 110 The mechanisms described in these documents are open-ended. 111 It is definitely not expected that all implementations will 112 support all available media types, nor that they will all 113 share the same extensions. In order to promote 114 interoperability, however, it is useful to define the concept 115 of "MIME-conformance" to define a certain level of 116 implementation that allows the useful interworking of messages 117 with content that differs from US-ASCII text. In this 118 section, we specify the requirements for such conformance. 120 A mail user agent that is MIME-conformant MUST: 122 (1) Always generate a "MIME-Version: 1.0" header field in 123 any message it creates. 125 (2) Recognize the Content-Transfer-Encoding header field 126 and decode all received data encoded with either the 127 quoted-printable or base64 implementations. Any non- 128 7-bit data that is sent without encoding must be 129 properly labelled with a content-transfer-encoding of 130 8bit or binary, as appropriate. If the underlying 131 transport does not support 8bit or binary (as SMTP 132 [RFC821] does not), the sender is required to both 133 encode and label data using an appropriate Content- 134 Transfer-Encoding such as quoted-printable or base64. 136 (3) Recognize and interpret the Content-Type header field, 137 and avoid showing users raw data with a Content-Type 138 field other than text. Be able to send at least 139 text/plain messages, with the character set specified 140 as a parameter if it is not US-ASCII. 142 (4) Explicitly handle the following media type values, to 143 at least the following extents: 145 Text: 147 -- Recognize and display "text" mail with the 148 character set "US-ASCII." 150 -- Recognize other character sets at least to the 151 extent of being able to inform the user about what 152 character set the message uses. 154 -- Recognize the "ISO-8859-*" character sets to the 155 extent of being able to display those characters that 156 are common to ISO-8859-* and US-ASCII, namely all 157 characters represented by octet values 1-127. 159 -- For unrecognized subtypes in a known character 160 set, show or offer to show the user the "raw" version 161 of the data after conversion of the content from 162 canonical form to local form. 164 -- Treat material in an unknown character set as if 165 it were "application/octet-stream". 167 Image, audio, and video: 169 -- At a minumum provide facilities to treat any 170 unrecognized subtypes as if they were 171 "application/octet-stream". 173 Application: 175 -- Offer the ability to remove either of the quoted- 176 printable or base64 encodings defined in this 177 document if they were used and put the resulting 178 information in a user file. 180 Multipart: 182 -- Recognize the mixed subtype. Display all relevant 183 information on the message level and the body part 184 header level and then display or offer to display 185 each of the body parts individually. 187 -- Recognize the "alternative" subtype, and avoid 188 showing the user redundant parts of 189 multipart/alternative mail. 191 -- Recognize the "multipart/digest" subtype, 192 specifically using "message/rfc822" rather than 193 "text/plain" as the default media type for body parts 194 inside "multipart/digest" entities. 196 -- Treat any unrecognized subtypes as if they were 197 "mixed". 199 Message: 201 -- Recognize and display at least the primary 202 (RFC822) encapsulation in such a way as to preserve 203 any recursive structure, that is, displaying or 204 offering to display the encapsulated data in 205 accordance with its media type. 207 -- Treat any unrecognized subtypes as if they were 208 "application/octet-stream". 210 (5) Upon encountering any unrecognized Content-Type field, 211 an implementation must treat it as if it had a media 212 type of "application/octet-stream" with no parameter 213 sub-arguments. How such data are handled is up to an 214 implementation, but likely options for handling such 215 unrecognized data include offering the user to write it 216 into a file (decoded from its mail transport format) or 217 offering the user to name a program to which the 218 decoded data should be passed as input. 220 A user agent that meets the above conditions is said to be 221 MIME-conformant. The meaning of this phrase is that it is 222 assumed to be "safe" to send virtually any kind of properly- 223 marked data to users of such mail systems, because such 224 systems will at least be able to treat the data as 225 undifferentiated binary, and will not simply splash it onto 226 the screen of unsuspecting users. 228 There is another sense in which it is always "safe" to send 229 data in a format that is MIME-conformant, which is that such 230 data will not break or be broken by any known systems that are 231 conformant with RFC 821 and RFC 822. User agents that are 232 MIME-conformant have the additional guarantee that the user 233 will not be shown data that were never intended to be viewed 234 as text. 236 5. Guidelines for Sending Email Data 238 Internet email is not a perfect, homogeneous system. Mail may 239 become corrupted at several stages in its travel to a final 240 destination. Specifically, email sent throughout the Internet 241 may travel across many networking technologies. Many 242 networking and mail technologies do not support the full 243 functionality possible in the SMTP transport environment. 244 Mail traversing these systems is likely to be modified in 245 order that it can be transported. 247 There exist many widely-deployed non-conformant MTAs in the 248 Internet. These MTAs, speaking the SMTP protocol, alter 249 messages on the fly to take advantage of the internal data 250 structure of the hosts they are implemented on, or are just 251 plain broken. 253 The following guidelines may be useful to anyone devising a 254 data format (media type) that is supposed to survive the 255 widest range of networking technologies and known broken MTAs 256 unscathed. Note that anything encoded in the base64 encoding 257 will satisfy these rules, but that some well-known mechanisms, 258 notably the UNIX uuencode facility, will not. Note also that 259 anything encoded in the Quoted-Printable encoding will survive 260 most gateways intact, but possibly not some gateways to 261 systems that use the EBCDIC character set. 263 (1) Under some circumstances the encoding used for data may 264 change as part of normal gateway or user agent 265 operation. In particular, conversion from base64 to 266 quoted-printable and vice versa may be necessary. This 267 may result in the confusion of CRLF sequences with line 268 breaks in text bodies. As such, the persistence of 269 CRLF as something other than a line break must not be 270 relied on. 272 (2) Many systems may elect to represent and store text data 273 using local newline conventions. Local newline 274 conventions may not match the RFC822 CRLF convention -- 275 systems are known that use plain CR, plain LF, CRLF, or 276 counted records. The result is that isolated CR and LF 277 characters are not well tolerated in general; they may 278 be lost or converted to delimiters on some systems, and 279 hence must not be relied on. 281 (3) The transmission of NULs (US-ASCII value 0) is 282 problematic in Internet mail. (This is largely the 283 result of NULs being used as a termination character by 284 many of the standard runtime library routines in the C 285 programming language.) The practice of using NULs as 286 termination characters is so entrenched now that 287 messages should not rely on them being preserved. 289 (4) TAB (HT) characters may be misinterpreted or may be 290 automatically converted to variable numbers of spaces. 291 This is unavoidable in some environments, notably those 292 not based on the US-ASCII character set. Such 293 conversion is STRONGLY DISCOURAGED, but it may occur, 294 and mail formats must not rely on the persistence of 295 TAB (HT) characters. 297 (5) Lines longer than 76 characters may be wrapped or 298 truncated in some environments. Line wrapping and line 299 truncation are STRONGLY DISCOURAGED, but unavoidable in 300 some cases. Applications which require long lines must 301 somehow differentiate between soft and hard line 302 breaks. (A simple way to do this is to use the 303 quoted-printable encoding.) 305 (6) Trailing "white space" characters (SPACE, TAB (HT)) on 306 a line may be discarded by some transport agents, while 307 other transport agents may pad lines with these 308 characters so that all lines in a mail file are of 309 equal length. The persistence of trailing white space, 310 therefore, must not be relied on. 312 (7) Many mail domains use variations on the US-ASCII 313 character set, or use character sets such as EBCDIC 314 which contain most but not all of the US-ASCII 315 characters. The correct translation of characters not 316 in the "invariant" set cannot be depended on across 317 character converting gateways. For example, this 318 situation is a problem when sending uuencoded 319 information across BITNET, an EBCDIC system. Similar 320 problems can occur without crossing a gateway, since 321 many Internet hosts use character sets other than US- 322 ASCII internally. The definition of Printable Strings 323 in X.400 adds further restrictions in certain special 324 cases. In particular, the only characters that are 325 known to be consistent across all gateways are the 73 326 characters that correspond to the upper and lower case 327 letters A-Z and a-z, the 10 digits 0-9, and the 328 following eleven special characters: 330 "'" (US-ASCII decimal value 39) 331 "(" (US-ASCII decimal value 40) 332 ")" (US-ASCII decimal value 41) 333 "+" (US-ASCII decimal value 43) 334 "," (US-ASCII decimal value 44) 335 "-" (US-ASCII decimal value 45) 336 "." (US-ASCII decimal value 46) 337 "/" (US-ASCII decimal value 47) 338 ":" (US-ASCII decimal value 58) 339 "=" (US-ASCII decimal value 61) 340 "?" (US-ASCII decimal value 63) 342 A maximally portable mail representation will confine 343 itself to relatively short lines of text in which the 344 only meaningful characters are taken from this set of 345 73 characters. The base64 encoding follows this rule. 347 (8) Some mail transport agents will corrupt data that 348 includes certain literal strings. In particular, a 349 period (".") alone on a line is known to be corrupted 350 by some (incorrect) SMTP implementations, and a line 351 that starts with the five characters "From " (the fifth 352 character is a SPACE) are commonly corrupted as well. 353 A careful composition agent can prevent these 354 corruptions by encoding the data (e.g., in the quoted- 355 printable encoding using "=46rom " in place of "From " 356 at the start of a line, and "=2E" in place of "." alone 357 on a line). 359 Please note that the above list is NOT a list of recommended 360 practices for MTAs. RFC 821 MTAs are prohibited from altering 361 the character of white space or wrapping long lines. These 362 BAD and invalid practices are known to occur on established 363 networks, and implementations should be robust in dealing with 364 the bad effects they can cause. 366 6. Canonical Encoding Model 368 There was some confusion, in earlier drafts of these 369 documents, regarding the model for when email data was to be 370 converted to canonical form and encoded, and in particular how 371 this process would affect the treatment of CRLFs, given that 372 the representation of newlines varies greatly from system to 373 system. For this reason, a canonical model for encoding is 374 presented below. 376 The process of composing a MIME entity can be modeled as being 377 done in a number of steps. Note that these steps are roughly 378 similar to those steps used in PEM [RFC1421] and are performed 379 for each "innermost level" body: 381 (1) Creation of local form. 383 The body to be transmitted is created in the system's 384 native format. The native character set is used and, 385 where appropriate, local end of line conventions are 386 used as well. The body may be a UNIX-style text file, 387 or a Sun raster image, or a VMS indexed file, or audio 388 data in a system-dependent format stored only in 389 memory, or anything else that corresponds to the local 390 model for the representation of some form of 391 information. Fundamentally, the data is created in the 392 "native" form that corresponds to the type specified by 393 the media type. 395 (2) Conversion to canonical form. 397 The entire body, including "out-of-band" information 398 such as record lengths and possibly file attribute 399 information, is converted to a universal canonical 400 form. The specific media type of the body as well as 401 its associated attributes dictate the nature of the 402 canonical form that is used. Conversion to the proper 403 canonical form may involve character set conversion, 404 transformation of audio data, compression, or various 405 other operations specific to the various media types. 406 If character set conversion is involved, however, care 407 must be taken to understand the semantics of the media 408 type, which may have strong implications for any 409 character set conversion, e.g. with regard to 410 syntactically meaningful characters in a text subtype 411 other than "plain". 413 For example, in the case of text/plain data, the text 414 must be converted to a supported character set and 415 lines must be delimited with CRLF delimiters in 416 accordance with RFC 822. Note that the restriction on 417 line lengths implied by RFC 822 is eliminated if the 418 next step employs either quoted-printable or base64 419 encoding. 421 (3) Apply transfer encoding. 423 A Content-Transfer-Encoding appropriate for this body 424 is applied. Note that there is no fixed relationship 425 between the media type and the transfer encoding. In 426 particular, it may be appropriate to base the choice of 427 base64 or quoted-printable on character frequency 428 counts which are specific to a given instance of a 429 body. 431 (4) Insertion into entity. 433 The encoded object is inserted into a MIME entity with 434 appropriate headers. The entity is then inserted into 435 the body of a higher-level entity (message or 436 multipart) if needed. 438 It is vital to note that these steps are only a model; they 439 are specifically NOT a blueprint for how an actual system 440 would be built. In particular, the model fails to account for 441 two common designs: 443 (1) In many cases the conversion to a canonical form prior 444 to encoding will be subsumed into the encoder itself, 445 which understands local formats directly. For example, 446 the local newline convention for text bodies might be 447 carried through to the encoder itself along with 448 knowledge of what that format is. 450 (2) The output of the encoders may have to pass through one 451 or more additional steps prior to being transmitted as 452 a message. As such, the output of the encoder may not 453 be conformant with the formats specified by RFC 822. 454 In particular, once again it may be appropriate for the 455 converter's output to be expressed using local newline 456 conventions rather than using the standard RFC 822 CRLF 457 delimiters. 459 Other implementation variations are conceivable as well. The 460 vital aspect of this discussion is that, in spite of any 461 optimizations, collapsings of required steps, or insertion of 462 additional processing, the resulting messages must be 463 consistent with those produced by the model described here. 464 For example, a message with the following header fields: 466 Content-type: text/foo; charset=bar 467 Content-Transfer-Encoding: base64 469 must be first represented in the text/foo form, then (if 470 necessary) represented in the "bar" character set, and finally 471 transformed via the base64 algorithm into a mail-safe form. 473 7. Summary 475 This document defines what is meant by MIME Conformance. It 476 also details various problems known to exist in the Internet 477 email system and how to use MIME to overcome them. Finally, it 478 describes MIME's canonical encoding model. 480 8. Security Considerations 482 Security issues are discussed in the second document in this 483 set, RFC MIME-IMT. 485 9. Authors' Addresses 487 For more information, the authors of this document are best 488 contacted via Internet mail: 490 Nathaniel S. Borenstein 491 First Virtual Holdings 492 25 Washington Avenue 493 Morristown, NJ 07960 494 USA 496 Email: nsb@nsb.fv.com 497 Phone: +1 201 540 8967 498 Fax: +1 201 993 3032 500 Ned Freed 501 Innosoft International, Inc. 502 1050 East Garvey Avenue South 503 West Covina, CA 91790 504 USA 506 Email: ned@innosoft.com 507 Phone: +1 818 919 3600 508 Fax: +1 818 919 3614 510 MIME is a result of the work of the Internet Engineering Task 511 Force Working Group on Email Extensions. The chairman of that 512 group, Greg Vaudreuil, may be reached at: 514 Gregory M. Vaudreuil 515 Tigon Corporation 516 17060 Dallas Parkway 517 Dallas Texas, 75248 519 Email: greg.vaudreuil@ons.octel.com 520 Phone: +1 214 733 2722 521 10. Acknowledgements 523 This document is the result of the collective effort of a 524 large number of people, at several IETF meetings, on the 525 IETF-SMTP and IETF-822 mailing lists, and elsewhere. Although 526 any enumeration seems doomed to suffer from egregious 527 omissions, the following are among the many contributors to 528 this effort: 530 Harald Tveit Alvestrand Marc Andreessen 531 Randall Atkinson Bob Braden 532 Philippe Brandon Brian Capouch 533 Kevin Carosso Uhhyung Choi 534 Peter Clitherow Dave Collier-Brown 535 Cristian Constantinof John Coonrod 536 Mark Crispin Dave Crocker 537 Stephen Crocker Terry Crowley 538 Walt Daniels Jim Davis 539 Frank Dawson Axel Deininger 540 Hitoshi Doi Kevin Donnelly 541 Steve Dorner Keith Edwards 542 Chris Eich Dana S. Emery 543 Johnny Eriksson Craig Everhart 544 Patrik Faltstrom Erik E. Fair 545 Roger Fajman Alain Fontaine 546 Martin Forssen James M. Galvin 547 Stephen Gildea Philip Gladstone 548 Thomas Gordon Keld Simonsen 549 Terry Gray Phill Gross 550 James Hamilton David Herron 551 Mark Horton Bruce Howard 552 Bill Janssen Olle Jarnefors 553 Risto Kankkunen Phil Karn 554 Alan Katz Tim Kehres 555 Neil Katin Steve Kille 556 Kyuho Kim Anders Klemets 557 John Klensin Valdis Kletniek 558 Jim Knowles Stev Knowles 559 Bob Kummerfeld Pekka Kytolaakso 560 Stellan Lagerstrom Vincent Lau 561 Timo Lehtinen Donald Lindsay 562 Warner Losh Carlyn Lowery 563 Laurence Lundblade Charles Lynn 564 John R. MacMillan Larry Masinter 565 Rick McGowan Michael J. McInerny 566 Leo Mclaughlin Goli Montaser-Kohsari 567 Tom Moore John Gardiner Myers 568 Erik Naggum Mark Needleman 569 Chris Newman John Noerenberg 570 Mats Ohrman Julian Onions 571 Michael Patton David J. Pepper 572 Erik van der Poel Blake C. Ramsdell 573 Christer Romson Luc Rooijakkers 574 Marshall T. Rose Jonathan Rosenberg 575 Guido van Rossum Jan Rynning 576 Harri Salminen Michael Sanderson 577 Yutaka Sato Markku Savela 578 Richard Alan Schafer Masahiro Sekiguchi 579 Mark Sherman Bob Smart 580 Peter Speck Henry Spencer 581 Einar Stefferud Michael Stein 582 Klaus Steinberger Peter Svanberg 583 James Thompson Steve Uhler 584 Stuart Vance Peter Vanderbilt 585 Greg Vaudreuil Ed Vielmetti 586 Larry W. Virden Ryan Waldron 587 Rhys Weatherly Jay Weber 588 Dave Wecker Wally Wedel 589 Sven-Ove Westberg Brian Wideen 590 John Wobus Glenn Wright 591 Rayan Zachariassen David Zimmerman 593 The authors apologize for any omissions from this list, which 594 are certainly unintentional. 596 Appendix A -- A Complex Multipart Example 598 What follows is the outline of a complex multipart message. 599 This message has five parts to be displayed serially: two 600 introductory plain text parts, an embedded multipart message, 601 a text/enriched part, and a closing encapsulated text message 602 in a non-ASCII character set. The embedded multipart message 603 has two parts to be displayed in parallel, a picture and an 604 audio fragment. 606 MIME-Version: 1.0 607 From: Nathaniel Borenstein 608 To: Ned Freed 609 Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) 610 Subject: A multipart example 611 Content-Type: multipart/mixed; 612 boundary=unique-boundary-1 614 This is the preamble area of a multipart message. 615 Mail readers that understand multipart format 616 should ignore this preamble. 618 If you are reading this text, you might want to 619 consider changing to a mail reader that understands 620 how to properly display multipart messages. 622 --unique-boundary-1 624 ... Some text appears here ... 626 [Note that the blank between the boundary and the start 627 of the text in this part means no header fields were 628 given and this is text in the US-ASCII character set. 629 It could have been done with explicit typing as in the 630 next part.] 632 --unique-boundary-1 633 Content-type: text/plain; charset=US-ASCII 635 This could have been part of the previous part, but 636 illustrates explicit versus implicit typing of body 637 parts. 639 --unique-boundary-1 640 Content-Type: multipart/parallel; boundary=unique-boundary-2 642 --unique-boundary-2 643 Content-Type: audio/basic 644 Content-Transfer-Encoding: base64 646 ... base64-encoded 8000 Hz single-channel 647 mu-law-format audio data goes here ... 649 --unique-boundary-2 650 Content-Type: image/tiff 651 Content-Transfer-Encoding: base64 653 ... base64-encoded image data goes here ... 655 --unique-boundary-2-- 657 --unique-boundary-1 658 Content-type: text/enriched 660 This is enriched. 661 as defined in RFC 1563 663 Isn't it 664 cool? 666 --unique-boundary-1 667 Content-Type: message/rfc822 669 From: (mailbox in US-ASCII) 670 To: (address in US-ASCII) 671 Subject: (subject in US-ASCII) 672 Content-Type: Text/plain; charset=ISO-8859-1 673 Content-Transfer-Encoding: Quoted-printable 675 ... Additional text in ISO-8859-1 goes here ... 677 --unique-boundary-1-- 678 Appendix B -- Changes from RFC 1521, 1522, and 1590 680 These documents are a revision of RFC 1521, 1522, and 1590. 681 For the convenience of those familiar with the earlier 682 documents, the changes from those documents are summarized in 683 this appendix. For further history, note that Appendix H in 684 RFC 1521 specified how that document differed from its 685 predecessor, RFC 1341. 687 (1) This document has been completely reformatted and split 688 into multiple documents. This was done to improve the 689 quality of the plain text version of this document, 690 which is required to be the reference copy. 692 (2) BNF describing the overall structure of MIME message 693 and part headers has been added. This is a 694 documentation change only -- the underlying syntax has 695 not changed in any way. 697 (3) The specific BNF for the seven media types in MIME has 698 been removed. This BNF was incorrect, incomplete, amd 699 inconsistent with the type-indendependent BNF. And 700 since the type-independent BNF already fully specifies 701 the syntax of the various MIME headers, the type- 702 specific BNF was, in the final analysis, completely 703 unnecessary and caused more problems than it solved. 705 (4) The more specific "US-ASCII" character set name has 706 replaced the use of the term ASCII in many parts of 707 this specification. 709 (5) The informal concept of a primary subtype has been 710 removed. 712 (6) The term "object" was being used inconsistently. This 713 term has been replaced with the more precise terms 714 "body", "body part", and "entity" where appropriate. 716 (7) The BNF for the multipart media type has been 717 rearranged to make it clear that the CRLF preceeding 718 the boundary marker is actually part of the marker 719 itself rather than the preceeding body part. 721 (8) The prose and BNF describing the multipart media type 722 have been changed to make it clear that the body parts 723 within a multipart entity MUST NOT contain any lines 724 beginning with the boundary parameter string. 726 (9) In the rules on reassembling "message/partial" MIME 727 entities, "Subject" is added to the list of headers to 728 take from the inner message, and the example is 729 modified to clarify this point. 731 (10) In the discussion of the application/postscript type, 732 an additional paragraph has been added warning about 733 possible interoperability problems caused by embedding 734 of binary data inside a PostScript MIME entity. 736 (11) Added a clarifying note to the basic syntax rules for 737 the Content-Type header field to make it clear that the 738 following two forms: 740 Content-type: text/plain; charset=us-ascii (comment) 742 Content-type: text/plain; charset="us-ascii" 744 are completely equivalent. 746 (12) The following sentence has been removed from the 747 discussion of the MIME-Version header: "However, 748 conformant software is encouraged to check the version 749 number and at least warn the user if an unrecognized 750 MIME-version is encountered." 752 (13) A typo was fixed that said "application/external-body" 753 instead of "message/external-body". 755 (14) The definition of a character set has been reorganized 756 to make the requirements clearer. 758 (15) The definition of the "image/gif" media type has been 759 moved to a separate document. This change was made 760 because of potential conflicts with IETF rules 761 governing the standardization of patented technology. 763 (16) The definitions of "7bit" and "8bit" have been 764 tightened so that use of bare CR, LF can only be used 765 as end-of-line sequences. The document also no longer 766 requires that NUL characters be preserved, which brings 767 MIME into alignment with real-world implementations. 769 (17) The definition of canonical text in MIME has been 770 tightened so that line breaks must be represented by a 771 CRLF sequence. CR and LF characters are not allowed 772 outside of this usage. The definition of quoted- 773 printable encoding has been altered accordingly. 775 (18) Prose was added to clarify the use of the "7bit", "8- 776 bit", and "binary" transfer-encodings on multipart or 777 message entities encapsulating "8bit" or "binary" data. 779 (19) In the section on MIME Conformance, "multipart/digest" 780 support was added to the list of requirements for 781 minimal MIME conformance. Also, the requirement for 782 "message/rfc822" support were strengthened to clarify 783 the importance of recognizing recursive structure. 785 (20) The various restrictions on subtypes of "message" are 786 now specified entirely on a subtype by subtype basis. 788 (21) The definition of "message/rfc822" was changed to 789 indicate that at least one of the "From", "Subject", or 790 "Date" headers must be present. 792 (22) The required handling of unrecognized subtypes as 793 "application/octet-stream" has been made more explicit 794 in both the type definitions sections and the 795 conformance guidelines. 797 (23) Examples using text/richtext were changed to 798 text/enriched. 800 (24) The BNF definition of subtype has been changed to make 801 it clear that either an IANA registered subtype or a 802 nonstandard "X-" subtype must be used in a Content-Type 803 header field. 805 (25) The use of escape and shift mechanisms in the US-ASCII 806 and ISO-8859-X character sets this specification 807 defines has been clarified: Such mechanisms should 808 never be used in conjunction with these character sets 809 and their effect if they are used is undefined. 811 (26) The definition of the AFS access-type for 812 message/external-body has been removed. 814 (27) Entities that are simply registered for use and those 815 that are standardized by the IETF are now distinguished 816 in the MIME BNF. 818 (28) The handling of the combination of 819 multipart/alternative and message/external-body is now 820 specifically addressed. 822 (29) Security issues specific to message/external-body are 823 now discussed in some detail. 825 Appendix C -- References 827 [ATK] 828 Borenstein, Nathaniel S., Multimedia Applications 829 Development with the Andrew Toolkit, Prentice-Hall, 1990. 831 [ISO-2022] 832 International Standard -- Information Processing -- ISO 833 7-bit and 8-bit Coded Character Sets -- Code Extension 834 Techniques, ISO 2022:1986. 836 [ISO-8859] 837 International Standard -- Information Processing -- 8-bit 838 Single-Byte Coded Graphic Character Sets -- Part 1: Latin 839 Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet 840 No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, 841 ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 842 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 843 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 844 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. 845 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: 846 Latin alphabet No. 5, ISO 8859-9, 1990. 848 [ISO-646] 849 International Standard -- Information Processing -- ISO 850 7-bit Coded Character Set For Information Interchange, 851 ISO 646:1983. 853 [MPEG] 854 Video Coding Draft Standard ISO 11172 CD, ISO 855 IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 856 1991. 858 [PCM] 859 CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code 860 Modulation (PCM) of Voice Frequencies", Geneva, 1972. 862 [POSTSCRIPT] 863 Adobe Systems, Inc., PostScript Language Reference 864 Manual, Addison-Wesley, 1985. 866 [POSTSCRIPT2] 867 Adobe Systems, Inc., PostScript Language Reference 868 Manual, Addison-Wesley, Second Edition, 1990. 870 [RFC-783] 871 Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, 872 MIT, June 1981. 874 [RFC-821] 875 Postel, J.B., "Simple Mail Transfer Protocol", STD 10, 876 RFC 821, USC/Information Sciences Institute, August 1982. 878 [RFC-822] 879 Crocker, D., "Standard for the Format of ARPA Internet 880 Text Messages", STD 11, RFC 822, UDEL, August 1982. 882 [RFC-934] 883 Rose, M. and E. Stefferud, "Proposed Standard for Message 884 Encapsulation", RFC 934, Delaware and NMA, January 1985. 886 [RFC-959] 887 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 888 9, RFC 959, USC/Information Sciences Institute, October 889 1985. 891 [RFC-1049] 892 Sirbu, M., "Content-Type Header Field for Internet 893 Messages", RFC 1049, CMU, March 1988. 895 [RFC-1154] 896 Robinson, D. and R. Ullmann, "Encoding Header Field for 897 Internet Messages", RFC 1154, Prime Computer, Inc., April 898 1990. 900 [RFC-1341] 901 Borenstein, N., and N. Freed, "MIME (Multipurpose 902 Internet Mail Extensions): Mechanisms for Specifying and 903 Describing the Format of Internet Message Bodies", RFC 904 1341, Bellcore, Innosoft, June 1992. 906 [RFC-1342] 907 Moore, K., "Representation of Non-Ascii Text in Internet 908 Message Headers", RFC 1342, University of Tennessee, June 909 1992. 911 [RFC-1344] 912 Borenstein, N., "Implications of MIME for Internet Mail 913 Gateways", RFC 1344, Bellcore, June 1992. 915 [RFC-1345] 916 Simonsen, K., "Character Mnemonics & Character Sets", RFC 917 1345, Rationel Almen Planlaegning, June 1992. 919 [RFC-1421] 920 Linn, J., "Privacy Enhancement for Internet Electronic 921 Mail: Part I -- Message Encryption and Authentication 922 Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, 923 February 1993. 925 [RFC-1422] 926 Kent, S., "Privacy Enhancement for Internet Electronic 927 Mail: Part II -- Certificate-Based Key Management", RFC 928 1422, IAB IRTF PSRG, IETF PEM WG, February 1993. 930 [RFC-1423] 931 Balenson, D., "Privacy Enhancement for Internet 932 Electronic Mail: Part III -- Algorithms, Modes, and 933 Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. 935 [RFC-1424] 936 Kaliski, B., "Privacy Enhancement for Internet Electronic 937 Mail: Part IV -- Key Certification and Related 938 Services", IAB IRTF PSRG, IETF PEM WG, February 1993. 940 [RFC-1521] 941 Borenstein, N. and Freed, N., "MIME (Multipurpose 942 Internet Mail Extensions): Mechanisms for Specifying and 943 Describing the Format of Internet Message Bodies", RFC 944 1521, Bellcore, Innosoft, September, 1993. 946 [RFC-1522] 947 Moore, K., "Representation of Non-ASCII Text in Internet 948 Message Headers", RFC 1522, University of Tennessee, 949 September 1993. 951 [RFC-1524] 952 Borenstein, N., "A User Agent Configuration Mechanism for 953 Multimedia Mail Format Information", RFC 1524, Bellcore, 954 September 1993. 956 [RFC-1543] 957 Postel, J., "Instructions to RFC Authors", RFC 1543, 958 USC/Information Sciences Institute, October 1993. 960 [RFC-1563] 961 Borenstein, N., "The text/enriched MIME Content-type", 962 RFC 1563, Bellcore, January, 1994. 964 [RFC-1590] 965 Postel, J., "Media Type Registration Procedure", RFC 966 1590, USC/Information Sciences Institute, March 1994. 968 [RFC-1602] 969 Internet Architecture Board, Internet Engineering 970 Steering Group, Huitema, C., Gross, P., "The Internet 971 Standards Process -- Revision 2", March 1994. 973 [RFC-1652] 974 Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., 975 Stefferud, E., and Crocker, D., "SMTP Service Extension 976 for 8bit-MIME transport", RFC 1652, United Nations 977 University, Innosoft, Dover Beach Consulting, Inc., 978 Network Management Associates, Inc., The Branch Office, 979 March 1994. 981 [RFC-1700] 982 Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 983 RFC 1700, USC/Information Sciences Institute, October 984 1994. 986 [RFC-MIME-IMB] 987 Borenstein, N. and Freed, N., "Multipurpose Internet Mail 988 Extensions (MIME) Part One: Format of Internet Message 989 Bodies", RFC MIME-IMB, Bellcore, Innosoft, April, 1995. 991 [RFC-MIME-IMT] 992 Borenstein, N. and Freed, N., "Multipurpose Internet Mail 993 Extensions (MIME) Part Two: Media Types", RFC MIME-IMT, 994 Bellcore, Innosoft, April, 1995. 996 [RFC-MIME-HEADERS] 997 Moore, K., "Multipurpose Internet Mail Extensions (MIME) 998 Part Three: Representation of Non-Ascii Text in Internet 999 Message Headers", RFC MIME-HEADERS, University of 1000 Tennessee, ?. 1002 [RFC-MIME-REG] 1003 Postel, J. and Freed, N., "Multipurpose Internet Mail 1004 Extensions (MIME) Part Four: Media Type Registration 1005 Procedure", RFC MIME-REG, ISI, Innosoft, April, 1995. 1007 [RFC-MIME-CONF] 1008 Borenstein, N. and Freed, N., "Multipurpose Internet Mail 1009 Extensions (MIME) Part Five: Conformance Criteria and 1010 Examples", RFC MIME-CONF, Bellcore, Innosoft, April, 1011 1995. 1013 [US-ASCII] 1014 Coded Character Set -- 7-Bit American Standard Code for 1015 Information Interchange, ANSI X3.4-1986. 1017 [X400] 1018 Schicker, Pietro, "Message Handling Systems, X.400", 1019 Message Handling Systems and Distributed Applications, E. 1020 Stefferud, O-j. Jacobsen, and P. Schicker, eds., North- 1021 Holland, 1989, pp. 3-41.