Multipurpose Internet Mail Extensions
(Every time you see this sign 
it means a default value) 
Introduction In 1992, a new standard was defined by an Internet Engineering Task Force Working Group in RFC 1521 & 1522 - called MIME.
MIME is a specification for enhancing the capabilities of standard Internet electronic mail. It offers a simple standardized way to represent and encode a wide variety of media types for transmission via Internet mail.
When using the MIME standard, messages can contain the following types:
MIME is defined to be completely backwards compatible, yet flexible and open to extensions. Therefore, it builds on the older standard by defining additional fields for the mail message header, that describes new content types, and a distinct organization of the message body.
Background The basic Internet standard for message format, defined in RFC 822, and the Simple Mail Transport Protocol (SMTP), defined in RFC 821, are widely used around the world these days (over 1,000,000 computers).
The main restrictions of these standards are:
In the presence of FAX and voice-mail services, anyone can easily imagine a more integrated multi-media mail facility on their computer.
There are some systems that demonstrate a richer mail on top of the basic Internet mail (RFC 822), but there was no standard that would allow such systems to interoperate.
Before MIME was defined the main alternative to Internet mail was the X.400 Message Handling System. Now, MIME and X.400 are competing for world dominance. Our impression is that MIME has a chance of winning the battle, due to the fact that it works.
Some more information about X.400 is available:
Technical Specifications Some of the most important innovations in the MIME standard are:
Those interested in the exact technical details,
and particularly implementors, should consult the official documents: RFC
1521
& 1522.
A major constraint when defining an extension to RFC 822 was the imperative that this basic model not be changed. In particular, nothing in the new document should cause existing mail systems to break. The header/body model and the syntax and semantics of all of the standard header fields defined by RFC 822 are left unchanged.
Given this constraint the approach chosen was to define a header field, "Content-type", which marks the entire message body as being a certain type of data. In the absence of a Content-type field, the body is assumed to be US-ASCII text, as before.
MIME defines the following new header fields:
Many Content-Types that could usefully be transported by e-mail are represented, in their "natural" format, as 8-bit character or binary data. Such data cannot be transmitted over some transport protocols, such as SMTP, which restricts mail messages to 7-bit ASCII data with lines no longer than 1000 characters.
MIME provides two mechanisms for re-encoding such data into 7-bit short-line format. The Content-Transfer-Encoding header field indicates the mechanism used to perform such an encoding.
Many, particularly those from non-English speaking countries, felt that it should be possible to use other character sets, in addition to the US-ASCII , in the header, particularly in human names and subject specification.
The second part of the MIME standard (RFC 1522) describes an extension to the message format, to allow representation of other character sets in message headers.
More details about the technical definitions
can be obtained by clicking here.
Examples In order to give the reader a general feeling of the MIME standard and usage we present several relatively common examples .
Purposeful Omissions During the definition of the standard for MIME, there have been several controversies and dilemmas. Presenting some of the discussions that led to the current structure might help understand the design approach better.
A few items discussed, but not included in the MIME standard, are:
MIME - Today & Tomorrow Following is a brief presentation of several ways MIME is used:
Mapping MIME types to external viewers is done through a configuration file called "mailcap". This is used in mosaic and netscape, among other applications.
A project on the Swedish Academic Network, SUNET, concerning Swedish characters in e-mail.
It is a message format converter for Internet messages. Emil V2.0 complies with both MIME RFCs. Emil's original purpose was to facilitate the official migration to MIME for Internet Mail.
Metamail is a package that can be used to convert virtually any mail-reading program (on UNIX, DOS, or Commodore Amiga) into a multi-media mail-reading program. It is an extremely generic implementation of MIME. The implementation is intended to be extremely flexible and extensible, using a "mailcap" file mechanism for adding support for new data formats when sent through the mail.
MHonArc is the successor of mail2html, a Perl mail-to-HTML converter. MHonArc works as an HTML mail archiving with index, mail thread linking, etc., but with much more capabilities including full support for MIME and powerful user customization features.
The MIME standard is written to allow todays standard to be extended in certain ways, without having to revise the standard.
Several issues have been left open, and will be defined when their use becomes clearer:
8-bit and binary are intended for compatibility with future Internet e-mail transport standards and with gateways to non-Internet environments. For the time being, there are no standardized Internet e-mail transports for which it is legitimate to include unencoded 8-bit or binary data in mail bodies. It is intended that the MIME mechanism will move gracefully into an 8-bit world should 8-bit transport become commonplace in accordance with the mechanisms that will be drafted by the SMTP extensions working group.
The working group settled on a relatively small set of "legal" character sets, and hopes to avoid the proliferation of an unnecessarily wide variety of character sets in international electronic mail. It is expected, however, that several more character sets will inevitably be added to the base set defined in MIME, as that set is fundamentally incomplete.
There have been proposals for a statement that certain encoding types are "preferred" for certain content-types. These have not yet been adopted, largely because it seems likely that common sense will suffice to encourage people to use, for example, base64 rather than quoted-printable when transmitting audio data. There have been proposals for a mechanism by which mail sent in the future 8-bit world could include a specification of a "preferred" encoding should the mail ever need to be passed off to a 7-bit mailer, but this can probably be done without.
Summary The new Internet mail standard - MIME (defined in RFCs 1521 & 1522) is an extension of the basic Internet mail standard (RFC 822).
MIME specifies mechanisms for including & encoding a variety of information types in mail, but remains flexible and open for future extensions. No restrictions imposed by either RFC 821 or RFC 822 are violated, so it is completely backwards compatible.
The MIME standard is a combined effort of making multipart, multi-character sets, multi-media e-mail widely available on the Internet, as opposed to the X.400 availability as we presented it.
In the technical specifications section, the header and body structure of MIME messages were defined. The "multipart" and "message" content-types presented in MIME allow mixing and hierarchical structuring of objects of different types in a single message.
Furthermore, to achieve a better understanding of MIME implementation, some examples were presented, and some implementations of MIME were discussed - to enable the curious reader to continue his/her inquiries on the subject.
Since MIME is not designed to cover all the requirements of electronic mail, some issues were omitted. Those issues were discussed to give the reader a better understanding of MIME's philosophy.
It should be noted that in order to promote interoperability between
user agents, the MIME standard specifies a minimal subset of MIME features
a user agent must support to be considered MIME conformant.
Further Readings & References
A list of more information
related to MIME and of references
is available.
This overview
was written for a course in "Protocols & Computer Networks"
by Dr. Debby Koren, at Tel-Aviv University, semester 2/1995.
Boxer Pazi (pazi@math.tau.ac.il),
Dascal Shlomit (sdascal@math.tau.ac.il),
Zadok Danny (zadok@math.tau.ac.il)
