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: [email protected]

  Nathaniel S. Borenstein
  First Virtual Holdings
  25 Washington Avenue
  Morristown, NJ 07960
  USA

  Phone: +1 201 540 8967
  Fax:   +1 201 993 3032
  EMail: [email protected]

  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: [email protected]



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 <[email protected]>
    To: Ned Freed <[email protected]>
    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]