RFC 1341 (rfc1341) - Page 1 of 77
MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
Alternative Format: Original Text Document
Network Working Group N. Borenstein, Bellcore
Request for Comments: 1341 N. Freed, Innosoft
June 1992
MIME (Multipurpose Internet Mail Extensions):
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies
Status of this Memo
This RFC specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of
the "IAB Official Protocol Standards" for the
standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
RFC 822 defines a message representation protocol which
specifies considerable detail about message headers, but
which leaves the message content, or message body, as flat
ASCII text. This document redefines the format of message
bodies to allow multi-part textual and non-textual message
bodies to be represented and exchanged without loss of
information. This is based on earlier work documented in
RFC 934 and RFC 1049, but extends and revises that work.
Because RFC 822 said so little about message bodies, this
document is largely orthogonal to (rather than a revision
of) RFC 822.
In particular, this document is designed to provide
facilities to include multiple objects in a single message,
to represent body text in character sets other than US-
ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating
mail agents.
This document does NOT extend Internet mail header fields to
permit anything other than US-ASCII text data. It is
recognized that such extensions are necessary, and they are
the subject of a companion document [RFC -1342].
A table of contents appears at the end of this document.
Borenstein & Freed [Page i]
1 Introduction
Since its publication in 1982, RFC 822 [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 [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 [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 of
seven-bit ASCII. This forces users to convert any non-
textual data that they may wish to send into seven-bit bytes
representable as printable 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 1113,
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 body
parts within electronic mail messages. The current
standards for the mapping of X.400 messages to RFC 822
messages specify that either X.400 non-textual body parts
should be converted to (not encoded in) an ASCII format, or
that they should 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's UA may not have the capability of
dealing with the non-textual body part, the user might have
some mechanism external to the UA that can extract useful
information from the body part. 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.
Borenstein & Freed
