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.
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 this
specification and allows
mail processing agents to
distinguish
between such messages and those
generated
by older or non-conformant
software, which is presumed
to
lack such a field.
- 2. A Content-Type header field
- generalized
from RFC 1049
[RFC-1049], which
can be used to specify the type
and
subtype of data in the body
of a message and to fully
specify
the native representation (encoding)
of such
data.
- 2.a. A "text" Content-Type value,
which can be used to
represent
textual information in a number
of
character sets and formatted
text description
languages in
a standardized manner.
- 2.b. A "multipart" Content-Type
value, which can be
used to
combine several body parts, possibly
of
differing types of data, into
a single message.
- 2.c. An "application" Content-Type
value, which can be
used
to transmit application data or
binary data,
and hence,
among other uses, to implement
an
electronic mail file
transfer service.
- 2.d. A "message" Content-Type value,
for encapsulating a mail message.
- 2.e An "image" Content-Type value,
for transmitting still image (picture)
data.
- 2.f. An "audio" Content-Type value,
for transmitting audio or voice
data.
- 2.g. A "video" Content-Type value,
for transmitting video or moving
image data, possibly with audio as
part of the composite video data
format.
- 3. A Content-Transfer-Encoding header
field
- which can be
used to specify
an auxiliary encoding that was applied
to the data in order to allow it
to pass through mail
transport
mechanisms which may have data
or character
set limitations.
- 4. Two optional header fields
- that
can be used to further
describe
the data in a message body, the Content-ID
and
Content-Description header
fields.
MIME has been carefully designed
as an extensible mechanism,
and
it is expected that the set
of content-type/subtype
pairs
and their associated parameters
will grow
significantly with
time. Several other MIME fields,
notably
including character set
names, are likely to have new values
defined over time. In order to
ensure that the set of such
values
is developed in an orderly,
well-specified, and
public manner,
MIME defines a registration process
which
uses the Internet Assigned
Numbers Authority (IANA) as a
central registry for such values.
Appendix F provides
details
about how IANA registration is accomplished.
Finally, to specify and promote interoperability,
Appendix A
of this document
provides a basic applicability statement
for a subset of the above mechanisms
that defines a minimal
level of
"conformance" with this document.
[HISTORICAL NOTE]: