\begindata{text,268788064}
\textdsversion{12}
\template{help}
\chapter{MIME:  Multipurpose Internet Mail Extensions

}
\section{What is MIME: 

}\leftindent{
The Andrew application \helptopic{messages} provides support for MIME 
extensions.  For more information on MIME use within Andrew, see the help 
files \helptopic{mime},  \helptopic{preferences},  \helptopic{metamail} and 
\helptopic{mmencode}.  


\quotation{The remainder of this document is excerpted from Nathaniel 
Borenstein's paper that was published in the ULPAA '92 Conference in 
Vancouver, May, 1992.}  


MIME (Multipurpose Internet Mail Extensions), a new standards-track Internet 
format defined by an Internet Engineering Task Force Working Group, offers a 
simple standardized way to represent and encode a wide variety of media types, 
including textual data in non-ASCII character sets, for transmission via 
Internet mail.  


MIME extends RFC 822 in a manner that is simple, completely 
backward-compatible, yet flexible and open to extension.  In addition to 
enhanced functionality for Internet mail, the new mechanism offers the promise 
of interconnecting X.400 "islands" without the loss of functionality currently 
found in X.400-to-Internet gateways.  This paper describes the general 
approach and rationale of the new mechanisms for Internet multimedia mail.


After years of experiments and non-standard, non-interoperating 
implementations, multimedia mail has yet to become widespread on the Internet 
or elsewhere, outside of isolated communities.  MIME (Multipurpose Internet 
Mail Extensions), a new standards-track Internet format defined by an Internet 
Engineering Task Force Working Group, offers a simple standardized way to 
represent and encode a wide variety of media types, including textual data in 
non-ASCII character sets, for transmission via Internet mail.  MIME extends 
RFC 822 in a manner that is simple, completely backward-compatible, yet 
flexible and open to extension.  In addition to enhanced functionality for 
Internet mail, the new mechanism offers the promise of interconnecting X.400 
"islands" without the loss of functionality currently found in 
X.400-to-Internet gateways.  This paper describes the general approach and 
rationale of the new mechanisms for Internet multimedia mail.


Background:  Why Extend Internet Mail?


Electronic mail is one of the most widely-used services on almost every 
computer network, including the Internet.  The Internet standard for message 
formats, RFC-822 [4], is used widely beyond the boundaries of the Internet 
itself.  However, the vast majority of electronic mail traffic is limited to 
US-ASCII text only.  Missing, for most users, is the ability to send pictures, 
audio, or even text in most non-English languages.


This limitation is not necessary.  Research and even commercial systems, 
including Andrew [2], Diamond/Slate [5], and many others, have demonstrated 
the feasability of much richer mail on top of RFC 822.  What has been 
prominently missing, however, is format standards that would allow such 
systems to interoperate.  Currently each of these systems allows its users to 
send multimedia mail in a readable format only to other users of the same 
software.


Increasingly, users are aware of the possibility of multimedia mail.  In the 
presence of FAX and voice mail services, it is easy for anyone to imagine a 
more integrated multimedia mail facility on their computer.  More and more, 
users are starting to request or even demand multimedia mail, and they expect 
such mail to interoperate.  If multimedia mail is to work on the Internet, 
some kind of extensions to RFC 822 are necessary.


The main alternative to Internet mail, of course, is X.400 [9], the 
international standard for mail transport.  Some have suggested that, since 
X.400 was designed for multimedia, the demand for multimedia should simply be 
used to force the transition to X.400.  This is an oversimplified view, 
however.  The established base of Internet mail users and the perceived 
complexity of X.400 create substantial resistance to such a transition, 
particularly in North America.  Moreover, X.400 systems currently exist mainly 
as islands in a sea of Internet mail.  In order to interoperate, X.400 mail 
must often be gatewayed into and then out of the Internet.  Such gatewaying, 
in the absence of Internet multimedia mail standards, loses information, 
because Internet mail has no standard representation for image, audio, or even 
non-ASCII textual data.  Thus standards for multimedia Internet mail will 
benefit X.400 users as well as X.400 opponents, and indeed both groups have 
cooperated in the creation of the new mechanisms.


In order to appreciate the design of the Internet multimedia mail facilities, 
one must first recognize some of the constraints.  First, there is a strong 
need for compatibility with existing practice in the Internet mail world. 
 That practice, as defined by RFC 822 (message format) and RFC 821 [7] (SMTP 
message transport), imposes several important limitations.  Both limit 
messages to 7 bit US-ASCII characters.  RFC 822 defines a message as a 
structured header followed by a single, monolithic text body, which creates 
problems for multipart mixed-media mail.  SMTP imposes further limits on the 
length of lines within message headers and bodies.


The 7 bit limitation is particularly critical.  There are two obvious 
approaches to alleviating this limitation:  one is to encode all data in 7 bit 
form, using a standard mechanism.  The other is to extend the standards to 
permit 8 bit data.  The work described here pursued the former path, on the 
grounds that backward-compatibility with 7-bit mail will be more easily and 
widely deployable, with less impact on existing implementations.  However, 
another group, with significantly overlapping membership, is pursuing the idea 
of 8-bit SMTP, and the groups have taken care to make sure that their work is 
compatible.


As stated before, there have been several successful but non-standard systems 
that overcame these limitations and provided multimedia mail.  The current 
work builds on those experiences, generalizing and standardizing their 
solutions.  In particular, it borrows from the work that resulted in RFC 1049 
[10], which defined a mechanism for single part non-text mail, and from RFC 
1154 [8], which provided a mechanism for multipart mail that, though 
problematic, demonstrated its feasability and desirability.


}
\enddata{text,268788064}