RFC 1521 (rfc1521) - Page 3 of 81
MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
Alternative Format: Original Text Document
RFC 1521 MIME September 1993
Appendix E -- IANA Registration Procedures................ 72
E.1 Registration of New Content-type/subtype Values...... 72
E.2 Registration of New Access-type Values
for Message/external-body............................ 73
Appendix F -- Summary of the Seven Content-types.......... 74
Appendix G -- Canonical Encoding Model.................... 76
Appendix H -- Changes from RFC 1341....................... 78
References................................................ 80
1. Introduction
Since its publication in 1982, STD 11, 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 STD 10, 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 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 body parts 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 body parts must be
converted to (not encoded in) an ASCII 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
Borenstein & Freed