7. Content-ID Header Field ..............................   26
   8. Content-Description Header Field .....................   27
   9. Additional MIME Header Fields ........................   27
   10. Summary .............................................   27
   11. Security Considerations .............................   27
   12. Authors' Addresses ..................................   28
   A. Collected Grammar ....................................   29







 
RFC 2045                Internet Message Bodies            November 1996


1.  Introduction

   Since its publication in 1982, RFC 822 has defined the standard
   format of textual mail messages on the Internet.  Its success has
   been such that the RFC 822 format has been adopted, wholly or
   partially, well beyond the confines of the Internet and the Internet
   SMTP transport defined by RFC 821.  As the format has seen wider use,
   a number of limitations have proven increasingly restrictive for the
   user community.

   RFC 822 was intended to specify a format for text messages.  As such,
   non-text messages, such as multimedia messages that might include
   audio or images, are simply not mentioned.  Even in the case of text,
   however, RFC 822 is inadequate for the needs of mail users whose
   languages require the use of character sets richer than US-ASCII.
   Since RFC 822 does not specify mechanisms for mail containing audio,
   video, Asian language text, or even text in most European languages,
   additional specifications are needed.

   One of the notable limitations of RFC 821/822 based mail systems is
   the fact that they limit the contents of electronic mail messages to
   relatively short lines (e.g. 1000 characters or less [RFC-821]) of
   7bit US-ASCII.  This forces users to convert any non-textual data
   that they may wish to send into seven-bit bytes representable as
   printable US-ASCII characters before invoking a local mail UA (User
   Agent, a program with which human users send and receive mail).
   Examples of such encodings currently used in the Internet include
   pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
   RFC 1421, the Andrew Toolkit Representation [ATK], and many others.

   The limitations of RFC 822 mail become even more apparent as gateways
   are designed to allow for the exchange of mail messages between RFC
   822 hosts and X.400 hosts.  X.400 [X400] specifies mechanisms for the
   inclusion of non-textual material within electronic mail messages.
   The current standards for the mapping of X.400 messages to RFC 822
   messages specify either that X.400 non-textual material must be
   converted to (not encoded in) IA5Text format, or that they must be
   discarded, notifying the RFC 822 user that discarding has occurred.
   This is clearly undesirable, as information that a user may wish to
   receive is lost.  Even though a user agent may not have the
   capability of dealing with the non-textual material, the user might
   have some mechanism external to the UA that can extract useful
   information from the material.  Moreover, it does not allow for the
   fact that the message may eventually be gatewayed back into an X.400
   message handling system (i.e., the X.400 message is "tunneled"
   through Internet mail), where the non-textual information would
   definitely become useful again.





 
RFC 2045                Internet Message Bodies            November 1996


   This document describes several mechanisms that combine to solve most
   of these problems without introducing any serious incompatibilities
   with the existing world of RFC 822 mail.  In particular, it
   describes:

    (1)   A MIME-Version header field, which uses a version
          number to declare a message to be conformant with MIME
          and allows mail processing agents to distinguish
          between such messages and those generated by older or
          non-conformant software, which are presumed to lack
          such a field.

    (2)   A Content-Type header field, generalized from RFC 1049,
          which can be used to specify the media type and subtype
          of data in the body of a message and to fully specify
          the native representation (canonical form) of such
          data.

    (3)   A Content-Transfer-Encoding header field, which can be
          used to specify both the encoding transformation that
          was applied to the body and the domain of the result.
          Encoding transformations other than the identity
          transformation are usually applied to data in order to
          allow it to pass through mail transport mechanisms
          which may have data or character set limitations.