











Network Working Group                                          N. Freed

Request for Comments: 2049                                     Innosoft

Obsoletes: 1521, 1522, 1590                               N. Borenstein

Category: Standards Track                                 First Virtual

                                                          November 1996





                 Multipurpose Internet Mail Extensions

                           (MIME) Part Five:

                   Conformance Criteria and Examples



Status of this Memo



   This document specifies an Internet standards track protocol for the

   Internet community, and requests discussion and suggestions for

   improvements.  Please refer to the current edition of the "Internet

   Official Protocol Standards" (STD 1) for the standardization state

   and status of this protocol.  Distribution of this memo is unlimited.



Abstract



   STD 11, RFC 822, defines a message representation protocol specifying

   considerable detail about US-ASCII message headers, and leaves the

   message content, or message body, as flat US-ASCII text.  This set of

   documents, collectively called the Multipurpose Internet Mail

   Extensions, or MIME, redefines the format of messages to allow for



    (1)   textual message bodies in character sets other than

          US-ASCII,



    (2)   an extensible set of different formats for non-textual

          message bodies,



    (3)   multi-part message bodies, and



    (4)   textual header information in character sets other than

          US-ASCII.



   These documents are based on earlier work documented in RFC 934, STD

   11, and RFC 1049, but extends and revises them.  Because RFC 822 said

   so little about message bodies, these documents are largely

   orthogonal to (rather than a revision of) RFC 822.



   The initial document in this set, RFC 2045, specifies the various

   headers used to describe the structure of MIME messages. The second

   document defines the general structure of the MIME media typing

   system and defines an initial set of media types.  The third

   document, RFC 2047, describes extensions to RFC 822 to allow non-US-







Freed & Borenstein          Standards Track                     [Page 1]



RFC 2049                    MIME Conformance               November 1996





   ASCII text data in Internet mail header fields. The fourth document,

   RFC 2048, specifies various IANA registration procedures for MIME-

   related facilities. This fifth and final document describes MIME

   conformance criteria as well as providing some illustrative examples

   of MIME message formats, acknowledgements, and the bibliography.



   These documents are revisions of RFCs 1521, 1522, and 1590, which

   themselves were revisions of RFCs 1341 and 1342.  Appendix B of this

   document describes differences and changes from previous versions.



Table of Contents



   1. Introduction ..........................................    2

   2. MIME Conformance ......................................    2

   3. Guidelines for Sending Email Data .....................    6

   4. Canonical Encoding Model ..............................    9

   5. Summary ...............................................   12

   6. Security Considerations ...............................   12

   7. Authors' Addresses ....................................   12

   8. Acknowledgements ......................................   13

   A. A Complex Multipart Example ...........................   15

   B. Changes from RFC 1521, 1522, and 1590 .................   16

   C. References ............................................   20



1.  Introduction



   The first and second documents in this set define MIME header fields

   and the initial set of MIME media types.  The third document

   describes extensions to RFC822 formats to allow for character sets

   other than US-ASCII.  This document describes what portions  of MIME

   must be supported by a conformant MIME implementation. It also

   describes various pitfalls of contemporary messaging systems as well

   as the canonical encoding model MIME is based on.



2.  MIME Conformance



   The mechanisms described in these documents are open-ended.  It is

   definitely not expected that all implementations will support all

   available media types, nor that they will all share the same

   extensions.  In order to promote interoperability, however, it is

   useful to define the concept of "MIME-conformance" to define a

   certain level of implementation that allows the useful interworking

   of messages with content that differs from US-ASCII text.  In this

   section, we specify the requirements for such conformance.















Freed & Borenstein          Standards Track                     [Page 2]



RFC 2049                    MIME Conformance               November 1996





   A mail user agent that is MIME-conformant MUST:



    (1)   Always generate a "MIME-Version: 1.0" header field in

          any message it creates.



    (2)   Recognize the Content-Transfer-Encoding header field

          and decode all received data encoded by either quoted-

          printable or base64 implementations.  The identity

          transformations 7bit, 8bit, and binary must also be

          recognized.



          Any non-7bit data that is sent without encoding must be

          properly labelled with a content-transfer-encoding of

          8bit or binary, as appropriate.  If the underlying

          transport does not support 8bit or binary (as SMTP

          [RFC-821] does not), the sender is required to both

          encode and label data using an appropriate Content-

          Transfer-Encoding such as quoted-printable or base64.



    (3)   Must treat any unrecognized Content-Transfer-Encoding

          as if it had a Content-Type of "application/octet-

          stream", regardless of whether or not the actual

          Content-Type is recognized.



    (4)   Recognize and interpret the Content-Type header field,

          and avoid showing users raw data with a Content-Type

          field other than text.  Implementations  must be able

          to send at least text/plain messages, with the

          character set specified with the charset parameter if

          it is not US-ASCII.



    (5)   Ignore any content type parameters whose names they do

          not recognize.



    (6)   Explicitly handle the following media type values, to

          at least the following extents:



          Text:



            -- Recognize and display "text" mail with the

            character set "US-ASCII."



            -- Recognize other character sets at least to the

            extent of being able to inform the user about what

            character set the message uses.













Freed & Borenstein          Standards Track                     [Page 3]



RFC 2049                    MIME Conformance               November 1996





            -- Recognize the "ISO-8859-*" character sets to the

            extent of being able to display those characters that

            are common to ISO-8859-* and US-ASCII, namely all

            characters represented by octet values 1-127.



            -- For unrecognized subtypes in a known character

            set, show or offer to show the user the "raw" version

            of the data after conversion of the content from

            canonical form to local form.



            -- Treat material in an unknown character set as if

            it were "application/octet-stream".



          Image, audio, and video:



            -- At a minumum provide facilities to treat any

            unrecognized subtypes as if they were

            "application/octet-stream".



          Application:



            -- Offer the ability to remove either of the quoted-

            printable or base64 encodings defined in this

            document if they were used and put the resulting

            information in a user file.



          Multipart:



            -- Recognize the mixed subtype.  Display all relevant

            information on the message level and the body part

            header level and then display or offer to display

            each of the body parts individually.



            -- Recognize the "alternative" subtype, and avoid

            showing the user redundant parts of

            multipart/alternative mail.



            -- Recognize the "multipart/digest" subtype,

            specifically using "message/rfc822" rather than

            "text/plain" as the default media type for body parts

            inside "multipart/digest" entities.



            -- Treat any unrecognized subtypes as if they were

            "mixed".















Freed & Borenstein          Standards Track                     [Page 4]



RFC 2049                    MIME Conformance               November 1996





          Message:



            -- Recognize and display at least the RFC822 message

            encapsulation (message/rfc822) in such a way as to

            preserve any recursive structure, that is, displaying

            or offering to display the encapsulated data in

            accordance with its media type.



            -- Treat any unrecognized subtypes as if they were

            "application/octet-stream".



    (7)   Upon encountering any unrecognized Content-Type field,

          an implementation must treat it as if it had a media

          type of "application/octet-stream" with no parameter

          sub-arguments.  How such data are handled is up to an

          implementation, but likely options for handling such

          unrecognized data include offering the user to write it

          into a file (decoded from its mail transport format) or

          offering the user to name a program to which the

          decoded data should be passed as input.



    (8)   Conformant user agents are required, if they provide

          non-standard support for non-MIME messages employing

          character sets other than US-ASCII, to do so on

          received messages only. Conforming user agents must not

          send non-MIME messages containing anything other than

          US-ASCII text.



          In particular, the use of non-US-ASCII text in mail

          messages without a MIME-Version field is strongly

          discouraged as it impedes interoperability when sending

          messages between regions with different localization

          conventions. Conforming user agents MUST include proper

          MIME labelling when sending anything other than plain

          text in the US-ASCII character set.



          In addition, non-MIME user agents should be upgraded if

          at all possible to include appropriate MIME header

          information in the messages they send even if nothing

          else in MIME is supported.  This upgrade will have

          little, if any, effect on non-MIME recipients and will

          aid MIME in correctly displaying such messages.  It

          also provides a smooth transition path to eventual

          adoption of other MIME capabilities.



    (9)   Conforming user agents must ensure that any string of

          non-white-space printable US-ASCII characters within a

          "*text" or "*ctext" that begins with "=?" and ends with







Freed & Borenstein          Standards Track                     [Page 5]



RFC 2049                    MIME Conformance               November 1996





          "?=" be a valid encoded-word.  ("begins" means: At the

          start of the field-body or immediately following

          linear-white-space; "ends" means: At the end of the

          field-body or immediately preceding linear-white-

          space.) In addition, any "word" within a "phrase" that

          begins with "=?" and ends with "?=" must be a valid

          encoded-word.



    (10)  Conforming user agents must be able to distinguish

          encoded-words from "text", "ctext", or "word"s,

          according to the rules in section 4, anytime they

          appear in appropriate places in message headers.  It

          must support both the "B" and "Q" encodings for any

          character set which it supports.  The program must be

          able to display the unencoded text if the character set

          is "US-ASCII".  For the ISO-8859-* character sets, the

          mail reading program must at least be able to display

          the characters which are also in the US-ASCII set.



   A user agent that meets the above conditions is said to be MIME-

   conformant.  The meaning of this phrase is that it is assumed to be

   "safe" to send virtually any kind of properly-marked data to users of

   such mail systems, because such systems will at least be able to

   treat the data as undifferentiated binary, and will not simply splash

   it onto the screen of unsuspecting users.



   There is another sense in which it is always "safe" to send data in a

   format that is MIME-conformant, which is that such data will not

   break or be broken by any known systems that are conformant with RFC

   821 and RFC 822.  User agents that are MIME-conformant have the

   additional guarantee that the user will not be shown data that were

   never intended to be viewed as text.



3.  Guidelines for Sending Email Data



   Internet email is not a perfect, homogeneous system.  Mail may become

   corrupted at several stages in its travel to a final destination.

   Specifically, email sent throughout the Internet may travel across

   many networking technologies. Many networking and mail technologies

   do not support the full functionality possible in the SMTP transport

   environment.  Mail traversing these systems is likely to be modified

   in order that it can be transported.



   There exist many widely-deployed non-conformant MTAs in the Internet.

   These MTAs, speaking the SMTP protocol, alter messages on the fly to

   take advantage of the internal data structure of the hosts they are

   implemented on, or are just plain broken.









Freed & Borenstein          Standards Track                     [Page 6]



RFC 2049                    MIME Conformance               November 1996





   The following guidelines may be useful to anyone devising a data

   format (media type) that is supposed to survive the widest range of

   networking technologies and known broken MTAs unscathed.  Note that

   anything encoded in the base64 encoding will satisfy these rules, but

   that some well-known mechanisms, notably the UNIX uuencode facility,

   will not.  Note also that anything encoded in the Quoted-Printable

   encoding will survive most gateways intact, but possibly not some

   gateways to systems that use the EBCDIC character set.



    (1)   Under some circumstances the encoding used for data may

          change as part of normal gateway or user agent

          operation.  In particular, conversion from base64 to

          quoted-printable and vice versa may be necessary.  This

          may result in the confusion of CRLF sequences with line

          breaks in text bodies.  As such, the persistence of

          CRLF as something other than a line break must not be

          relied on.



    (2)   Many systems may elect to represent and store text data

          using local newline conventions.  Local newline

          conventions may not match the RFC822 CRLF convention --

          systems are known that use plain CR, plain LF, CRLF, or

          counted records.  The result is that isolated CR and LF

          characters are not well tolerated in general; they may

          be lost or converted to delimiters on some systems, and

          hence must not be relied on.



    (3)   The transmission of NULs (US-ASCII value 0) is

          problematic in Internet mail.  (This is largely the

          result of NULs being used as a termination character by

          many of the standard runtime library routines in the C

          programming language.) The practice of using NULs as

          termination characters is so entrenched now that

          messages should not rely on them being preserved.



    (4)   TAB (HT) characters may be misinterpreted or may be

          automatically converted to variable numbers of spaces.

          This is unavoidable in some environments, notably those

          not based on the US-ASCII character set.  Such

          conversion is STRONGLY DISCOURAGED, but it may occur,

          and mail formats must not rely on the persistence of

          TAB (HT) characters.



    (5)   Lines longer than 76 characters may be wrapped or

          truncated in some environments.  Line wrapping or line

          truncation imposed by mail transports is STRONGLY

          DISCOURAGED, but unavoidable in some cases.

          Applications which require long lines must somehow







Freed & Borenstein          Standards Track                     [Page 7]



RFC 2049                    MIME Conformance               November 1996





          differentiate between soft and hard line breaks.  (A

          simple way to do this is to use the quoted-printable

          encoding.)



    (6)   Trailing "white space" characters (SPACE, TAB (HT)) on

          a line may be discarded by some transport agents, while

          other transport agents may pad lines with these

          characters so that all lines in a mail file are of

          equal length.  The persistence of trailing white space,

          therefore, must not be relied on.



    (7)   Many mail domains use variations on the US-ASCII

          character set, or use character sets such as EBCDIC

          which contain most but not all of the US-ASCII

          characters.  The correct translation of characters not

          in the "invariant" set cannot be depended on across

          character converting gateways.  For example, this

          situation is a problem when sending uuencoded

          information across BITNET, an EBCDIC system.  Similar

          problems can occur without crossing a gateway, since

          many Internet hosts use character sets other than US-

          ASCII internally.  The definition of Printable Strings

          in X.400 adds further restrictions in certain special

          cases.  In particular, the only characters that are

          known to be consistent across all gateways are the 73

          characters that correspond to the upper and lower case

          letters A-Z and a-z, the 10 digits 0-9, and the

          following eleven special characters:



            "'"  (US-ASCII decimal value 39)

            "("  (US-ASCII decimal value 40)

            ")"  (US-ASCII decimal value 41)

            "+"  (US-ASCII decimal value 43)

            ","  (US-ASCII decimal value 44)

            "-"  (US-ASCII decimal value 45)

            "."  (US-ASCII decimal value 46)

            "/"  (US-ASCII decimal value 47)

            ":"  (US-ASCII decimal value 58)

            "="  (US-ASCII decimal value 61)

            "?"  (US-ASCII decimal value 63)



          A maximally portable mail representation will confine

          itself to relatively short lines of text in which the

          only meaningful characters are taken from this set of

          73 characters.  The base64 encoding follows this rule.



    (8)   Some mail transport agents will corrupt data that

          includes certain literal strings.  In particular, a







Freed & Borenstein          Standards Track                     [Page 8]



RFC 2049                    MIME Conformance               November 1996





          period (".") alone on a line is known to be corrupted

          by some (incorrect) SMTP implementations, and a line

          that starts with the five characters "From " (the fifth

          character is a SPACE) are commonly corrupted as well.

          A careful composition agent can prevent these

          corruptions by encoding the data (e.g., in the quoted-

          printable encoding using "=46rom " in place of "From "

          at the start of a line, and "=2E" in place of "." alone

          on a line).



   Please note that the above list is NOT a list of recommended

   practices for MTAs.  RFC 821 MTAs are prohibited from altering the

   character of white space or wrapping long lines.  These BAD and

   invalid practices are known to occur on established networks, and

   implementations should be robust in dealing with the bad effects they

   can cause.



4.  Canonical Encoding Model



   There was some confusion, in earlier versions of these documents,

   regarding the model for when email data was to be converted to

   canonical form and encoded, and in particular how this process would

   affect the treatment of CRLFs, given that the representation of

   newlines varies greatly from system to system.  For this reason, a

   canonical model for encoding is presented below.



   The process of composing a MIME entity can be modeled as being done

   in a number of steps.  Note that these steps are roughly similar to

   those steps used in PEM [RFC-1421] and are performed for each

   "innermost level" body:



    (1)   Creation of local form.



          The body to be transmitted is created in the system's

          native format.  The native character set is used and,

          where appropriate, local end of line conventions are

          used as well.  The body may be a UNIX-style text file,

          or a Sun raster image, or a VMS indexed file, or audio

          data in a system-dependent format stored only in

          memory, or anything else that corresponds to the local

          model for the representation of some form of

          information.  Fundamentally, the data is created in the

          "native" form that corresponds to the type specified by

          the media type.















Freed & Borenstein          Standards Track                     [Page 9]



RFC 2049                    MIME Conformance               November 1996





    (2)   Conversion to canonical form.



          The entire body, including "out-of-band" information

          such as record lengths and possibly file attribute

          information, is converted to a universal canonical

          form.  The specific media type of the body as well as

          its associated attributes dictate the nature of the

          canonical form that is used.  Conversion to the proper

          canonical form may involve character set conversion,

          transformation of audio data, compression, or various

          other operations specific to the various media types.

          If character set conversion is involved, however, care

          must be taken to understand the semantics of the media

          type, which may have strong implications for any

          character set conversion, e.g. with regard to

          syntactically meaningful characters in a text subtype

          other than "plain".



          For example, in the case of text/plain data, the text

          must be converted to a supported character set and

          lines must be delimited with CRLF delimiters in

          accordance with RFC 822.  Note that the restriction on

          line lengths implied by RFC 822 is eliminated if the

          next step employs either quoted-printable or base64

          encoding.



    (3)   Apply transfer encoding.



          A Content-Transfer-Encoding appropriate for this body

          is applied.  Note that there is no fixed relationship

          between the media type and the transfer encoding.  In

          particular, it may be appropriate to base the choice of

          base64 or quoted-printable on character frequency

          counts which are specific to a given instance of a

          body.



    (4)   Insertion into entity.



          The encoded body is inserted into a MIME entity with

          appropriate headers. The entity is then inserted into

          the body of a higher-level entity (message or

          multipart) as needed.



   Conversion from entity form to local form is accomplished by

   reversing these steps. Note that reversal of these steps may produce

   differing results since there is no guarantee that the original and

   final local forms are the same.









Freed & Borenstein          Standards Track                    [Page 10]



RFC 2049                    MIME Conformance               November 1996





   It is vital to note that these steps are only a model; they are

   specifically NOT a blueprint for how an actual system would be built.

   In particular, the model fails to account for two common designs:



    (1)   In many cases the conversion to a canonical form prior

          to encoding will be subsumed into the encoder itself,

          which understands local formats directly.  For example,

          the local newline convention for text bodies might be

          carried through to the encoder itself along with

          knowledge of what that format is.



    (2)   The output of the encoders may have to pass through one

          or more additional steps prior to being transmitted as

          a message.  As such, the output of the encoder may not

          be conformant with the formats specified by RFC 822.

          In particular, once again it may be appropriate for the

          converter's output to be expressed using local newline

          conventions rather than using the standard RFC 822 CRLF

          delimiters.



   Other implementation variations are conceivable as well.  The vital

   aspect of this discussion is that, in spite of any optimizations,

   collapsings of required steps, or insertion of additional processing,

   the resulting messages must be consistent with those produced by the

   model described here.  For example, a message with the following

   header fields:



     Content-type: text/foo; charset=bar

     Content-Transfer-Encoding: base64



   must be first represented in the text/foo form, then (if necessary)

   represented in the "bar" character set, and finally transformed via

   the base64 algorithm into a mail-safe form.



   NOTE: Some confusion has been caused by systems that represent

   messages in a format which uses local newline conventions which

   differ from the RFC822 CRLF convention.  It is important to note that

   these formats are not canonical RFC822/MIME.  These formats are

   instead *encodings* of RFC822, where CRLF sequences in the canonical

   representation of the message are encoded as the local newline

   convention.  Note that formats which encode CRLF sequences as, for

   example, LF are not capable of representing MIME messages containing

   binary data which contains LF octets not part of CRLF line separation

   sequences.















Freed & Borenstein          Standards Track                    [Page 11]



RFC 2049                    MIME Conformance               November 1996





5.  Summary



   This document defines what is meant by MIME Conformance. It also

   details various problems known to exist in the Internet email system

   and how to use MIME to overcome them. Finally, it describes MIME's

   canonical encoding model.



6.  Security Considerations



   Security issues are discussed in the second document in this set, RFC

   2046.



7.  Authors' Addresses



   For more information, the authors of this document are best contacted

   via Internet mail:



   Ned Freed

   Innosoft International, Inc.

   1050 East Garvey Avenue South

   West Covina, CA 91790

   USA



   Phone: +1 818 919 3600

   Fax:   +1 818 919 3614

   EMail: ned@innosoft.com



   Nathaniel S. Borenstein

   First Virtual Holdings

   25 Washington Avenue

   Morristown, NJ 07960

   USA



   Phone: +1 201 540 8967

   Fax:   +1 201 993 3032

   EMail: nsb@nsb.fv.com



   MIME is a result of the work of the Internet Engineering Task Force

   Working Group on RFC 822 Extensions.  The chairman of that group,

   Greg Vaudreuil, may be reached at:



   Gregory M. Vaudreuil

   Octel Network Services

   17080 Dallas Parkway

   Dallas, TX 75248-1905

   USA



   EMail: Greg.Vaudreuil@Octel.Com







Freed & Borenstein          Standards Track                    [Page 12]



RFC 2049                    MIME Conformance               November 1996





8.  Acknowledgements



   This document is the result of the collective effort of a large

   number of people, at several IETF meetings, on the IETF-SMTP and

   IETF-822 mailing lists, and elsewhere.  Although any enumeration

   seems doomed to suffer from egregious omissions, the following are

   among the many contributors to this effort:



     Harald Tveit Alvestrand       Marc Andreessen

     Randall Atkinson              Bob Braden

     Philippe Brandon              Brian Capouch

     Kevin Carosso                 Uhhyung Choi

     Peter Clitherow               Dave Collier-Brown

     Cristian Constantinof         John Coonrod

     Mark Crispin                  Dave Crocker

     Stephen Crocker               Terry Crowley

     Walt Daniels                  Jim Davis

     Frank Dawson                  Axel Deininger

     Hitoshi Doi                   Kevin Donnelly

     Steve Dorner                  Keith Edwards

     Chris Eich                    Dana S. Emery

     Johnny Eriksson               Craig Everhart

     Patrik Faltstrom              Erik E. Fair

     Roger Fajman                  Alain Fontaine

     Martin Forssen                James M. Galvin

     Stephen Gildea                Philip Gladstone

     Thomas Gordon                 Keld Simonsen

     Terry Gray                    Phill Gross

     James Hamilton                David Herron

     Mark Horton                   Bruce Howard

     Bill Janssen                  Olle Jarnefors

     Risto Kankkunen               Phil Karn

     Alan Katz                     Tim Kehres

     Neil Katin                    Steve Kille

     Kyuho Kim                     Anders Klemets

     John Klensin                  Valdis Kletniek

     Jim Knowles                   Stev Knowles

     Bob Kummerfeld                Pekka Kytolaakso

     Stellan Lagerstrom            Vincent Lau

     Timo Lehtinen                 Donald Lindsay

     Warner Losh                   Carlyn Lowery

     Laurence Lundblade            Charles Lynn

     John R. MacMillan             Larry Masinter

     Rick McGowan                  Michael J. McInerny

     Leo Mclaughlin                Goli Montaser-Kohsari

     Tom Moore                     John Gardiner Myers

     Erik Naggum                   Mark Needleman

     Chris Newman                  John Noerenberg







Freed & Borenstein          Standards Track                    [Page 13]



RFC 2049                    MIME Conformance               November 1996





     Mats Ohrman                   Julian Onions

     Michael Patton                David J. Pepper

     Erik van der Poel             Blake C. Ramsdell

     Christer Romson               Luc Rooijakkers

     Marshall T. Rose              Jonathan Rosenberg

     Guido van Rossum              Jan Rynning

     Harri Salminen                Michael Sanderson

     Yutaka Sato                   Markku Savela

     Richard Alan Schafer          Masahiro Sekiguchi

     Mark Sherman                  Bob Smart

     Peter Speck                   Henry Spencer

     Einar Stefferud               Michael Stein

     Klaus Steinberger             Peter Svanberg

     James Thompson                Steve Uhler

     Stuart Vance                  Peter Vanderbilt

     Greg Vaudreuil                Ed Vielmetti

     Larry W. Virden               Ryan Waldron

     Rhys Weatherly                Jay Weber

     Dave Wecker                   Wally Wedel

     Sven-Ove Westberg             Brian Wideen

     John Wobus                    Glenn Wright

     Rayan Zachariassen            David Zimmerman



   The authors apologize for any omissions from this list, which are

   certainly unintentional.





















































Freed & Borenstein          Standards Track                    [Page 14]



RFC 2049                    MIME Conformance               November 1996





Appendix A -- A Complex Multipart Example



   What follows is the outline of a complex multipart message.  This

   message contains five parts that are to be displayed serially:  two

   introductory plain text objects, an embedded multipart message, a

   text/enriched object, and a closing encapsulated text message in a

   non-ASCII character set.  The embedded multipart message itself

   contains two objects to be displayed in parallel, a picture and an

   audio fragment.



     MIME-Version: 1.0

     From: Nathaniel Borenstein <nsb@nsb.fv.com>

     To: Ned Freed <ned@innosoft.com>

     Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)

     Subject: A multipart example

     Content-Type: multipart/mixed;

                   boundary=unique-boundary-1



     This is the preamble area of a multipart message.

     Mail readers that understand multipart format

     should ignore this preamble.



     If you are reading this text, you might want to

     consider changing to a mail reader that understands

     how to properly display multipart messages.



     --unique-boundary-1



       ... Some text appears here ...



     [Note that the blank between the boundary and the start

      of the text in this part means no header fields were

      given and this is text in the US-ASCII character set.

      It could have been done with explicit typing as in the

      next part.]



     --unique-boundary-1

     Content-type: text/plain; charset=US-ASCII



     This could have been part of the previous part, but

     illustrates explicit versus implicit typing of body

     parts.



     --unique-boundary-1

     Content-Type: multipart/parallel; boundary=unique-boundary-2



     --unique-boundary-2

     Content-Type: audio/basic







Freed & Borenstein          Standards Track                    [Page 15]



RFC 2049                    MIME Conformance               November 1996





     Content-Transfer-Encoding: base64



       ... base64-encoded 8000 Hz single-channel

           mu-law-format audio data goes here ...



     --unique-boundary-2

     Content-Type: image/jpeg

     Content-Transfer-Encoding: base64



       ... base64-encoded image data goes here ...



     --unique-boundary-2--



     --unique-boundary-1

     Content-type: text/enriched



     This is <bold><italic>enriched.</italic></bold>

     <smaller>as defined in RFC 1896</smaller>



     Isn't it

     <bigger><bigger>cool?</bigger></bigger>



     --unique-boundary-1

     Content-Type: message/rfc822



     From: (mailbox in US-ASCII)

     To: (address in US-ASCII)

     Subject: (subject in US-ASCII)

     Content-Type: Text/plain; charset=ISO-8859-1

     Content-Transfer-Encoding: Quoted-printable



       ... Additional text in ISO-8859-1 goes here ...



     --unique-boundary-1--



Appendix B -- Changes from RFC 1521, 1522, and 1590



   These documents are a revision of RFC 1521, 1522, and 1590.  For the

   convenience of those familiar with the earlier documents, the changes

   from those documents are summarized in this appendix.  For further

   history, note that Appendix H in RFC 1521 specified how that document

   differed from its predecessor, RFC 1341.



    (1)   This document has been completely reformatted and split

          into multiple documents.  This was done to improve the

          quality of the plain text version of this document,

          which is required to be the reference copy.









Freed & Borenstein          Standards Track                    [Page 16]



RFC 2049                    MIME Conformance               November 1996





    (2)   BNF describing the overall structure of MIME object

          headers has been added. This is a documentation change

          only -- the underlying syntax has not changed in any

          way.



    (3)   The specific BNF for the seven media types in MIME has

          been removed.  This BNF was incorrect, incomplete, amd

          inconsistent with the type-indendependent BNF.  And

          since the type-independent BNF already fully specifies

          the syntax of the various MIME headers, the type-

          specific BNF was, in the final analysis, completely

          unnecessary and caused more problems than it solved.



    (4)   The more specific "US-ASCII" character set name has

          replaced the use of the informal term ASCII in many

          parts of these documents.



    (5)   The informal concept of a primary subtype has been

          removed.



    (6)   The term "object" was being used inconsistently.  The

          definition of this term has been clarified, along with

          the related terms "body", "body part", and "entity",

          and usage has been corrected where appropriate.



    (7)   The BNF for the multipart media type has been

          rearranged to make it clear that the CRLF preceeding

          the boundary marker is actually part of the marker

          itself rather than the preceeding body part.



    (8)   The prose and BNF describing the multipart media type

          have been changed to make it clear that the body parts

          within a multipart object MUST NOT contain any lines

          beginning with the boundary parameter string.



    (9)   In the rules on reassembling "message/partial" MIME

          entities, "Subject" is added to the list of headers to

          take from the inner message, and the example is

          modified to clarify this point.



    (10)  "Message/partial" fragmenters are restricted to

          splitting MIME objects only at line boundaries.



    (11)  In the discussion of the application/postscript type,

          an additional paragraph has been added warning about

          possible interoperability problems caused by embedding

          of binary data inside a PostScript MIME entity.









Freed & Borenstein          Standards Track                    [Page 17]



RFC 2049                    MIME Conformance               November 1996





    (12)  Added a clarifying note to the basic syntax rules for

          the Content-Type header field to make it clear that the

          following two forms:



            Content-type: text/plain; charset=us-ascii (comment)



            Content-type: text/plain; charset="us-ascii"



          are completely equivalent.



    (13)  The following sentence has been removed from the

          discussion of the MIME-Version header: "However,

          conformant software is encouraged to check the version

          number and at least warn the user if an unrecognized

          MIME-version is encountered."



    (14)  A typo was fixed that said "application/external-body"

          instead of "message/external-body".



    (15)  The definition of a character set has been reorganized

          to make the requirements clearer.



    (16)  The definition of the "image/gif" media type has been

          moved to a separate document. This change was made

          because of potential conflicts with IETF rules

          governing the standardization of patented technology.



    (17)  The definitions of "7bit" and "8bit" have been

          tightened so that use of bare CR, LF can only be used

          as end-of-line sequences.  The document also no longer

          requires that NUL characters be preserved, which brings

          MIME into alignment with real-world implementations.



    (18)  The definition of canonical text in MIME has been

          tightened so that line breaks must be represented by a

          CRLF sequence.  CR and LF characters are not allowed

          outside of this usage.  The definition of quoted-

          printable encoding has been altered accordingly.



    (19)  The definition of the quoted-printable encoding now

          includes a number of suggestions for how quoted-

          printable encoders might best handle improperly encoded

          material.



    (20)  Prose was added to clarify the use of the "7bit",

          "8bit", and "binary" transfer-encodings on multipart or

          message entities encapsulating "8bit" or "binary" data.









Freed & Borenstein          Standards Track                    [Page 18]



RFC 2049                    MIME Conformance               November 1996





    (21)  In the section on MIME Conformance, "multipart/digest"

          support was added to the list of requirements for

          minimal MIME conformance.  Also, the requirement for

          "message/rfc822" support were strengthened to clarify

          the importance of recognizing recursive structure.



    (22)  The various restrictions on subtypes of "message" are

          now specified entirely on a subtype by subtype basis.



    (23)  The definition of "message/rfc822" was changed to

          indicate that at least one of the "From", "Subject", or

          "Date" headers must be present.



    (24)  The required handling of unrecognized subtypes as

          "application/octet-stream" has been made more explicit

          in both the type definitions sections and the

          conformance guidelines.



    (25)  Examples using text/richtext were changed to

          text/enriched.



    (26)  The BNF definition of subtype has been changed to make

          it clear that either an IANA registered subtype or a

          nonstandard "X-" subtype must be used in a Content-Type

          header field.



    (27)  MIME media types that are simply registered for use and

          those that are standardized by the IETF are now

          distinguished in the MIME BNF.



    (28)  All of the various MIME registration procedures have

          been extensively revised. IANA registration procedures

          for character sets have been moved to a separate

          document that is no included in this set of documents.



    (29)  The use of escape and shift mechanisms in the US-ASCII

          and ISO-8859-X character sets these documents define

          have been clarified: Such mechanisms should never be

          used in conjunction with these character sets and their

          effect if they are used is undefined.



    (30)  The definition of the AFS access-type for

          message/external-body has been removed.



    (31)  The handling of the combination of

          multipart/alternative and message/external-body is now

          specifically addressed.









Freed & Borenstein          Standards Track                    [Page 19]



RFC 2049                    MIME Conformance               November 1996





    (32)  Security issues specific to message/external-body are

          now discussed in some detail.



Appendix C -- References



   [ATK]

        Borenstein, Nathaniel S., Multimedia Applications

        Development with the Andrew Toolkit, Prentice-Hall, 1990.



   [ISO-2022]

        International Standard -- Information Processing --

        Character Code Structure and Extension Techniques,

        ISO/IEC 2022:1994, 4th ed.



   [ISO-8859]

        International Standard -- Information Processing -- 8-bit

        Single-Byte Coded Graphic Character Sets

        - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.

        - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.

        - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.

        - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.

        - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st

        ed.

        - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.

        - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.

        - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.

        - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st

        ed.

        International Standard -- Information Technology -- 8-bit

        Single-Byte Coded Graphic Character Sets

        - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992,

        1st ed.



   [ISO-646]

        International Standard -- Information Technology -- ISO

        7-bit Coded Character Set for Information Interchange,

        ISO 646:1991, 3rd ed..



   [JPEG]

        JPEG Draft Standard ISO 10918-1 CD.



   [MPEG]

        Video Coding Draft Standard ISO 11172 CD, ISO

        IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May,

        1991.













Freed & Borenstein          Standards Track                    [Page 20]



RFC 2049                    MIME Conformance               November 1996





   [PCM]

        CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code

        Modulation (PCM) of Voice Frequencies", Geneva, 1972.



   [POSTSCRIPT]

        Adobe Systems, Inc., PostScript Language Reference

        Manual, Addison-Wesley, 1985.



   [POSTSCRIPT2]

        Adobe Systems, Inc., PostScript Language Reference

        Manual, Addison-Wesley, Second Ed., 1990.



   [RFC-783]

        Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,

        MIT, June 1981.



   [RFC-821]

        Postel, J.B., "Simple Mail Transfer Protocol", STD 10,

        RFC 821, USC/Information Sciences Institute, August 1982.



   [RFC-822]

        Crocker, D., "Standard for the Format of ARPA Internet

        Text Messages", STD 11, RFC 822, UDEL, August 1982.



   [RFC-934]

        Rose, M. and E. Stefferud, "Proposed Standard for Message

        Encapsulation", RFC 934, Delaware and NMA, January 1985.



   [RFC-959]

        Postel, J. and J. Reynolds, "File Transfer Protocol", STD

        9, RFC 959, USC/Information Sciences Institute, October

        1985.



   [RFC-1049]

        Sirbu, M., "Content-Type Header Field for Internet

        Messages", RFC 1049, CMU, March 1988.



   [RFC-1154]

        Robinson, D., and R. Ullmann, "Encoding Header Field for

        Internet Messages", RFC 1154, Prime Computer, Inc., April

        1990.



   [RFC-1341]

        Borenstein, N., and N.  Freed, "MIME (Multipurpose

        Internet Mail Extensions): Mechanisms for Specifying and

        Describing the Format of Internet Message Bodies", RFC

        1341, Bellcore, Innosoft, June 1992.









Freed & Borenstein          Standards Track                    [Page 21]



RFC 2049                    MIME Conformance               November 1996





   [RFC-1342]

        Moore, K., "Representation of Non-Ascii Text in Internet

        Message Headers", RFC 1342, University of Tennessee, June

        1992.



   [RFC-1344]

        Borenstein, N., "Implications of MIME for Internet Mail

        Gateways", RFC 1344, Bellcore, June 1992.



   [RFC-1345]

        Simonsen, K., "Character Mnemonics & Character Sets", RFC

        1345, Rationel Almen Planlaegning, June 1992.



   [RFC-1421]

        Linn, J., "Privacy Enhancement for Internet Electronic

        Mail:  Part I -- Message Encryption and Authentication

        Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG,

        February 1993.



   [RFC-1422]

        Kent, S., "Privacy Enhancement for Internet Electronic

        Mail:  Part II -- Certificate-Based Key Management", RFC

        1422, IAB IRTF PSRG, IETF PEM WG, February 1993.



   [RFC-1423]

        Balenson, D., "Privacy Enhancement for Internet

        Electronic Mail:  Part III -- Algorithms, Modes, and

        Identifiers",  IAB IRTF PSRG, IETF PEM WG, February 1993.



   [RFC-1424]

        Kaliski, B., "Privacy Enhancement for Internet Electronic

        Mail:  Part IV -- Key Certification and Related

        Services", IAB IRTF PSRG, IETF PEM WG, February 1993.



   [RFC-1521]

        Borenstein, N., and Freed, N., "MIME (Multipurpose

        Internet Mail Extensions): Mechanisms for Specifying and

        Describing the Format of Internet Message Bodies", RFC

        1521, Bellcore, Innosoft, September, 1993.



   [RFC-1522]

        Moore, K., "Representation of Non-ASCII Text in Internet

        Message Headers", RFC 1522, University of Tennessee,

        September 1993.















Freed & Borenstein          Standards Track                    [Page 22]



RFC 2049                    MIME Conformance               November 1996





   [RFC-1524]

        Borenstein, N., "A User Agent Configuration Mechanism for

        Multimedia Mail Format Information", RFC 1524, Bellcore,

        September 1993.



   [RFC-1543]

        Postel, J., "Instructions to RFC Authors", RFC 1543,

        USC/Information Sciences Institute, October 1993.



   [RFC-1556]

        Nussbacher, H., "Handling of Bi-directional Texts in

        MIME", RFC 1556, Israeli Inter-University Computer

        Center, December 1993.



   [RFC-1590]

        Postel, J., "Media Type Registration Procedure", RFC

        1590, USC/Information Sciences Institute, March 1994.



   [RFC-1602]

        Internet Architecture Board, Internet Engineering

        Steering Group, Huitema, C., Gross, P., "The Internet

        Standards Process -- Revision 2", March 1994.



   [RFC-1652]

        Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,

        Stefferud, E., and Crocker, D., "SMTP Service Extension

        for 8bit-MIME transport", RFC 1652, United Nations

        University, Innosoft, Dover Beach Consulting, Inc.,

        Network Management Associates, Inc., The Branch Office,

        March 1994.



   [RFC-1700]

        Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,

        RFC 1700, USC/Information Sciences Institute, October

        1994.



   [RFC-1741]

        Faltstrom, P., Crocker, D., and Fair, E., "MIME Content

        Type for BinHex Encoded Files", December 1994.



   [RFC-1896]

        Resnick, P., and A. Walker, "The text/enriched MIME

        Content-type", RFC 1896, February, 1996.

















Freed & Borenstein          Standards Track                    [Page 23]



RFC 2049                    MIME Conformance               November 1996





   [RFC-2045]

        Freed, N., and and N. Borenstein, "Multipurpose Internet Mail

        Extensions (MIME) Part One: Format of Internet Message

        Bodies", RFC 2045, Innosoft, First Virtual Holdings,

        November 1996.



   [RFC-2046]

        Freed, N., and N. Borenstein, "Multipurpose Internet Mail

        Extensions (MIME) Part Two: Media Types", RFC 2046,

        Innosoft, First Virtual Holdings, November 1996.



   [RFC-2047]

        Moore, K., "Multipurpose Internet Mail Extensions (MIME)

        Part Three: Representation of Non-ASCII Text in Internet

        Message Headers", RFC 2047, University of

        Tennessee, November 1996.



   [RFC-2048]

        Freed, N., Klensin, J., and J. Postel, "Multipurpose

        Internet Mail Extensions (MIME) Part Four: MIME

        Registration Procedures", RFC 2048, Innosoft, MCI,

        ISI, November 1996.



   [RFC-2049]

        Freed, N. and N. Borenstein, "Multipurpose Internet Mail

        Extensions (MIME) Part Five: Conformance Criteria and

        Examples", RFC 2049 (this document), Innosoft, First

        Virtual Holdings, November 1996.



   [US-ASCII]

        Coded Character Set -- 7-Bit American Standard Code for

        Information Interchange, ANSI X3.4-1986.



   [X400]

        Schicker, Pietro, "Message Handling Systems, X.400",

        Message Handling Systems and Distributed Applications, E.

        Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-

        Holland, 1989, pp. 3-41.



























Freed & Borenstein          Standards Track                    [Page 24]



