7Network Working Group N. Freed
8Request for Comments: 2049 Innosoft
9Obsoletes: 1521, 1522, 1590 N. Borenstein
10Category: Standards Track First Virtual
14 Multipurpose Internet Mail Extensions
16 Conformance Criteria and Examples
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.
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
34 (1) textual message bodies in character sets other than
37 (2) an extensible set of different formats for non-textual
40 (3) multi-part message bodies, and
42 (4) textual header information in character sets other than
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.
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-
58Freed & Borenstein Standards Track [Page 1]
60RFC 2049 MIME Conformance November 1996
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.
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.
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
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.
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.
114Freed & Borenstein Standards Track [Page 2]
116RFC 2049 MIME Conformance November 1996
119 A mail user agent that is MIME-conformant MUST:
121 (1) Always generate a "MIME-Version: 1.0" header field in
122 any message it creates.
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
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.
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.
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
150 (5) Ignore any content type parameters whose names they do
153 (6) Explicitly handle the following media type values, to
154 at least the following extents:
158 -- Recognize and display "text" mail with the
159 character set "US-ASCII."
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.
170Freed & Borenstein Standards Track [Page 3]
172RFC 2049 MIME Conformance November 1996
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.
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.
185 -- Treat material in an unknown character set as if
186 it were "application/octet-stream".
188 Image, audio, and video:
190 -- At a minumum provide facilities to treat any
191 unrecognized subtypes as if they were
192 "application/octet-stream".
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.
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.
208 -- Recognize the "alternative" subtype, and avoid
209 showing the user redundant parts of
210 multipart/alternative mail.
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.
217 -- Treat any unrecognized subtypes as if they were
226Freed & Borenstein Standards Track [Page 4]
228RFC 2049 MIME Conformance November 1996
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.
239 -- Treat any unrecognized subtypes as if they were
240 "application/octet-stream".
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.
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
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.
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.
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
282Freed & Borenstein Standards Track [Page 5]
284RFC 2049 MIME Conformance November 1996
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
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.
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.
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.
3203. Guidelines for Sending Email Data
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.
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.
338Freed & Borenstein Standards Track [Page 6]
340RFC 2049 MIME Conformance November 1996
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.
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
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.
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.
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
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
394Freed & Borenstein Standards Track [Page 7]
396RFC 2049 MIME Conformance November 1996
399 differentiate between soft and hard line breaks. (A
400 simple way to do this is to use the quoted-printable
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.
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:
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)
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.
445 (8) Some mail transport agents will corrupt data that
446 includes certain literal strings. In particular, a
450Freed & Borenstein Standards Track [Page 8]
452RFC 2049 MIME Conformance November 1996
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
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
4724. Canonical Encoding Model
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.
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:
486 (1) Creation of local form.
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
506Freed & Borenstein Standards Track [Page 9]
508RFC 2049 MIME Conformance November 1996
511 (2) Conversion to canonical form.
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
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
537 (3) Apply transfer encoding.
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
547 (4) Insertion into entity.
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.
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.
562Freed & Borenstein Standards Track [Page 10]
564RFC 2049 MIME Conformance November 1996
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:
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.
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
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
594 Content-type: text/foo; charset=bar
595 Content-Transfer-Encoding: base64
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.
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
618Freed & Borenstein Standards Track [Page 11]
620RFC 2049 MIME Conformance November 1996
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.
6306. Security Considerations
632 Security issues are discussed in the second document in this set, RFC
637 For more information, the authors of this document are best contacted
641 Innosoft International, Inc.
642 1050 East Garvey Avenue South
643 West Covina, CA 91790
646 Phone: +1 818 919 3600
648 EMail: ned@innosoft.com
650 Nathaniel S. Borenstein
651 First Virtual Holdings
656 Phone: +1 201 540 8967
658 EMail: nsb@nsb.fv.com
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:
665 Octel Network Services
667 Dallas, TX 75248-1905
670 EMail: Greg.Vaudreuil@Octel.Com
674Freed & Borenstein Standards Track [Page 12]
676RFC 2049 MIME Conformance November 1996
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:
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
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
730Freed & Borenstein Standards Track [Page 13]
732RFC 2049 MIME Conformance November 1996
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
758 The authors apologize for any omissions from this list, which are
759 certainly unintentional.
786Freed & Borenstein Standards Track [Page 14]
788RFC 2049 MIME Conformance November 1996
791Appendix A -- A Complex Multipart Example
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
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
809 This is the preamble area of a multipart message.
810 Mail readers that understand multipart format
811 should ignore this preamble.
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.
819 ... Some text appears here ...
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
828 Content-type: text/plain; charset=US-ASCII
830 This could have been part of the previous part, but
831 illustrates explicit versus implicit typing of body
835 Content-Type: multipart/parallel; boundary=unique-boundary-2
838 Content-Type: audio/basic
842Freed & Borenstein Standards Track [Page 15]
844RFC 2049 MIME Conformance November 1996
847 Content-Transfer-Encoding: base64
849 ... base64-encoded 8000 Hz single-channel
850 mu-law-format audio data goes here ...
853 Content-Type: image/jpeg
854 Content-Transfer-Encoding: base64
856 ... base64-encoded image data goes here ...
858 --unique-boundary-2--
861 Content-type: text/enriched
863 This is <bold><italic>enriched.</italic></bold>
864 <smaller>as defined in RFC 1896</smaller>
867 <bigger><bigger>cool?</bigger></bigger>
870 Content-Type: message/rfc822
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
878 ... Additional text in ISO-8859-1 goes here ...
880 --unique-boundary-1--
882Appendix B -- Changes from RFC 1521, 1522, and 1590
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.
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.
898Freed & Borenstein Standards Track [Page 16]
900RFC 2049 MIME Conformance November 1996
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
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.
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.
920 (5) The informal concept of a primary subtype has been
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.
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.
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.
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.
943 (10) "Message/partial" fragmenters are restricted to
944 splitting MIME objects only at line boundaries.
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.
954Freed & Borenstein Standards Track [Page 17]
956RFC 2049 MIME Conformance November 1996
959 (12) Added a clarifying note to the basic syntax rules for
960 the Content-Type header field to make it clear that the
963 Content-type: text/plain; charset=us-ascii (comment)
965 Content-type: text/plain; charset="us-ascii"
967 are completely equivalent.
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."
975 (14) A typo was fixed that said "application/external-body"
976 instead of "message/external-body".
978 (15) The definition of a character set has been reorganized
979 to make the requirements clearer.
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.
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.
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.
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
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.
1010Freed & Borenstein Standards Track [Page 18]
1012RFC 2049 MIME Conformance November 1996
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.
1021 (22) The various restrictions on subtypes of "message" are
1022 now specified entirely on a subtype by subtype basis.
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.
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.
1033 (25) Examples using text/richtext were changed to
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
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.
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.
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.
1056 (30) The definition of the AFS access-type for
1057 message/external-body has been removed.
1059 (31) The handling of the combination of
1060 multipart/alternative and message/external-body is now
1061 specifically addressed.
1066Freed & Borenstein Standards Track [Page 19]
1068RFC 2049 MIME Conformance November 1996
1071 (32) Security issues specific to message/external-body are
1072 now discussed in some detail.
1074Appendix C -- References
1077 Borenstein, Nathaniel S., Multimedia Applications
1078 Development with the Andrew Toolkit, Prentice-Hall, 1990.
1081 International Standard -- Information Processing --
1082 Character Code Structure and Extension Techniques,
1083 ISO/IEC 2022:1994, 4th ed.
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
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
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,
1105 International Standard -- Information Technology -- ISO
1106 7-bit Coded Character Set for Information Interchange,
1107 ISO 646:1991, 3rd ed..
1110 JPEG Draft Standard ISO 10918-1 CD.
1113 Video Coding Draft Standard ISO 11172 CD, ISO
1114 IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May,
1122Freed & Borenstein Standards Track [Page 20]
1124RFC 2049 MIME Conformance November 1996
1128 CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code
1129 Modulation (PCM) of Voice Frequencies", Geneva, 1972.
1132 Adobe Systems, Inc., PostScript Language Reference
1133 Manual, Addison-Wesley, 1985.
1136 Adobe Systems, Inc., PostScript Language Reference
1137 Manual, Addison-Wesley, Second Ed., 1990.
1140 Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,
1144 Postel, J.B., "Simple Mail Transfer Protocol", STD 10,
1145 RFC 821, USC/Information Sciences Institute, August 1982.
1148 Crocker, D., "Standard for the Format of ARPA Internet
1149 Text Messages", STD 11, RFC 822, UDEL, August 1982.
1152 Rose, M. and E. Stefferud, "Proposed Standard for Message
1153 Encapsulation", RFC 934, Delaware and NMA, January 1985.
1156 Postel, J. and J. Reynolds, "File Transfer Protocol", STD
1157 9, RFC 959, USC/Information Sciences Institute, October
1161 Sirbu, M., "Content-Type Header Field for Internet
1162 Messages", RFC 1049, CMU, March 1988.
1165 Robinson, D., and R. Ullmann, "Encoding Header Field for
1166 Internet Messages", RFC 1154, Prime Computer, Inc., April
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.
1178Freed & Borenstein Standards Track [Page 21]
1180RFC 2049 MIME Conformance November 1996
1184 Moore, K., "Representation of Non-Ascii Text in Internet
1185 Message Headers", RFC 1342, University of Tennessee, June
1189 Borenstein, N., "Implications of MIME for Internet Mail
1190 Gateways", RFC 1344, Bellcore, June 1992.
1193 Simonsen, K., "Character Mnemonics & Character Sets", RFC
1194 1345, Rationel Almen Planlaegning, June 1992.
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,
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.
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.
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.
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.
1224 Moore, K., "Representation of Non-ASCII Text in Internet
1225 Message Headers", RFC 1522, University of Tennessee,
1234Freed & Borenstein Standards Track [Page 22]
1236RFC 2049 MIME Conformance November 1996
1240 Borenstein, N., "A User Agent Configuration Mechanism for
1241 Multimedia Mail Format Information", RFC 1524, Bellcore,
1245 Postel, J., "Instructions to RFC Authors", RFC 1543,
1246 USC/Information Sciences Institute, October 1993.
1249 Nussbacher, H., "Handling of Bi-directional Texts in
1250 MIME", RFC 1556, Israeli Inter-University Computer
1251 Center, December 1993.
1254 Postel, J., "Media Type Registration Procedure", RFC
1255 1590, USC/Information Sciences Institute, March 1994.
1258 Internet Architecture Board, Internet Engineering
1259 Steering Group, Huitema, C., Gross, P., "The Internet
1260 Standards Process -- Revision 2", March 1994.
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,
1271 Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1272 RFC 1700, USC/Information Sciences Institute, October
1276 Faltstrom, P., Crocker, D., and Fair, E., "MIME Content
1277 Type for BinHex Encoded Files", December 1994.
1280 Resnick, P., and A. Walker, "The text/enriched MIME
1281 Content-type", RFC 1896, February, 1996.
1290Freed & Borenstein Standards Track [Page 23]
1292RFC 2049 MIME Conformance November 1996
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,
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.
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.
1313 Freed, N., Klensin, J., and J. Postel, "Multipurpose
1314 Internet Mail Extensions (MIME) Part Four: MIME
1315 Registration Procedures", RFC 2048, Innosoft, MCI,
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.
1325 Coded Character Set -- 7-Bit American Standard Code for
1326 Information Interchange, ANSI X3.4-1986.
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.
1346Freed & Borenstein Standards Track [Page 24]