Multimedia Systems (1993) 1:29—36
`
`
`
`Multimedia Systems
`© Springer-Verlag 1993
`
`MIME: a portable and robust multimedia format for internet mail
`
`Nathaniel S. Borenstein
`
`Bellcore Room MRE 2D-296, 445 South St. Morristown, NJ 07960, USA
`e-mail: nsb@bellcore.com
`
`Received January 10, l993/Accepted April l0, 1993
`
`Abstract. Although multimedia systems are rapidly becom-
`ing more widely available and affordable, most present-day
`multimedia applications are not designed with interoperabil-
`ity in mind. Multimedia data from one application can be
`used in another only in relatively specialized circumstances
`or with special translator software, effort, and expense. While
`this situation is undesirable. it is not a critical impediment
`to the use of multimedia in many application domains. In
`others. however. the lack of interoperability is crucial, and
`nowhere is this more the case than for multimedia electronic
`
`the
`mail. MIME (Multipurpose Internet Mail Extensions),
`new standard format defined by an lntemet Engineering Task
`Force Working Group, offers a simple standardized way to
`represent and encode a wide variety of media types, includ-
`ing images, audio, video, and non-ASCII textual data, for
`transmission via Internet mail. MIME extends lntemet mail
`
`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-Intemet gate-
`ways. This paper describes the general approach and ratio-
`nale of the new mechanisms for Internet multimedia mail.
`
`Key words: MIME ~ Multimedia format - lntemet mail
`
`1 Motivation: interoperable multimedia mail
`
`Electronic mail is one of the most widely used services on
`almost every computer network, including the lntemet. The
`lntemet standard for message formats, RFC-822 (Crocker).
`is used widely beyond the boundaries of the Internet itself.
`However, the vast majority of electronic mail traffic is lim-
`ited 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. Even a relatively unso-
`phisticated computer user has little trouble understanding the
`concept and utility of enclosing pictures in a mail message,
`for example. This concept is easily extended to include virtu-
`ally any other type of digital data. Research systems, includ-
`ing Andrew (Borenstein and Thyberg 1991), Diamond/Slate
`
`(Forsdick et al. 1984) and many others, have demonstrated
`the feasability of much richer mail on top of RFC 822. How-
`ever, unlike other multimedia applications, electronic mail
`is critically dependent on standardization, as the utililty of
`a “standalone” mail system would be very low. What has
`been prominently missing, however, is format standards that
`would allow such systems to interoperate. For example, each
`of the research prototype multimedia mail systems allowed
`its users to send and receive images, but not in a format
`that would be recognized by any of the other systems. The
`recognition of this problem led gradually to a widespread
`consensus that a standardized format for multimedia mail
`
`exchange was necessary. The format devised by the lntemet
`community for this purpose became known as MIME, the
`Multipurpose lntemet Mail Extensions, and is the subject of
`this paper.
`Of course, electronic mail is not the only application that
`could benefit enormously from the widespread adoption of a
`standard format for multimedia data exchange. However, it
`is a logical application to pioneer the development of such
`a format To begin with, standards are more critical to mul-
`timedia mail than to other applications. Further, electronic
`mail systems operate under a huge and diverse set of con-
`straints. In particular, email needs to work interoperably on
`virtually every kind of computer ever built. This adds enor-
`mous complexity when one considers machines with unusual
`byte or word size, the need for ASCII-EBCDIC interopera—
`tion, the frequent limitation of 7-bit paths for data exchange,
`and so on. Beyond the technical problems posed by this
`kind of extreme heterogeneity, there are political problems.
`If one image format is commonly used on UNIX, for ex-
`ample, while another is commonly used on DOS, then the
`choice of a standardized image format can become a polit-
`ical issue that might be seen as favoring one platform over
`another. Because of all these constraints, it is far more likely
`that a mail-oriented multimedia interchange format will work
`for non—mail applications than vice versa.
`In fact, within a few months after the publication of the
`MIME standard, MIME was already in use as the basic mul-
`timedia format for a half dozen non-mail applications, and its
`use is being proposed in a wide range of other areas. Thus
`while the demands of electronic mail were critical to the
`
`Page 1 of 8
`
`AT&T EXHIBIT 1035
`
`

`

`30
`
`definition of MIME — and will play a prominent role in this
`paper in explaining the design of MIME — the applicability
`of MIME has a far broader potential range.
`
`2 Extending mail standards to support multimedia
`
`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 is X400 (Schicker
`
`the international standard for mail transport. Some
`1989),
`have suggested that, since X400 was designed with multi-
`media in mind, the demand for multimedia should simply
`be used to force the transition to X.400. This is an over-
`
`simplified view, however. To begin with, X400 has been
`extremely slow to win acceptance and deployment in the
`technical community. The established base of Internet mail
`users and the perceived complexity of X400 create sub—
`stantial 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,
`X400 mail must often be gatewayed into and then out of the
`Internet. Such gatewaying, in the absence of Internet mul-
`timedia mail standards, loses information, because Internet
`mail has no standard representation for image, audio, or even
`non—ASCII textual data. Finally, X.400’s support for multi-
`media data has proved to be far less complete than originally
`advertised. Overall, standards for multimedia Internet mail
`will benefit X400 users as well as X400 opponents, and
`indeed both groups have cooperated in the creation of the
`new mechanisms.
`
`In order to appreciate the design of the Internet multi—
`media 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 (Crocker 1982) (message format) and
`RFC 821 (Postel) (SMTP message transport),'imposes sev-
`eral important limitations. Both limit messages to T-bit US-
`ASCH 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 im—
`poses further limits on the length of lines within message
`headers and bodies.
`
`The 7-bit limitation is particuiarly 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
`
`Page 2 of 8
`
`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 (Sirbu 1988), which defined a mechanism for single-
`part non~text mail, and from RFC 1154 (Robinson and U1]-
`mann 1988) which provided a mechanism for multipart mail
`that,
`though problematic, demonstrated its feasability and
`desirability.
`
`3 Technical overview
`
`RFC 822 defines an Internet message as consisting of two
`parts: a header and a body. The header consists of a series of
`field names and field bodies, after which a blank line marks
`
`the end of the header and the beginning of the body, which
`(according to RFC 822) consists of only US ASCII text. The
`following message, for example, has a “From” header field
`with the author‘s name as the field body, a “Subject” header
`field with a descriptive field body, and a one-line message
`body:
`
`From: Nathaniel Borenstein
`
`Subject: Hello there
`
`"hello"
`Actually.
`I wanted to say.
`
`is all
`
`A major constraint of the working group charged with ex-
`tending RFC 822 was the imperative that this basic model
`not be changed. In particular, it was strorrgly and widely felt
`that nothing in the new document should cause existing mail
`systems to break. Not only was the headerfbody model left
`unchanged, but so too were the syntax and semantics of all
`of the standard header fields defined by RFC 822.
`Given these constraints, there were two basic models for
`
`extension. One was to add a single header field that described
`the structure and type of the body as a whole, no matter how
`many subparts it might have. This was the approach of RFC
`1154, but
`it had problems with describing the boundaries
`between parts and did not appear likely to scale up well
`to messages with very many subparts. Moreover, it did not
`permit the description of nested parts, a functionality that
`has proven very useful in systems such as Andrew.
`The other approach, chosen by the working group, was
`that introduced by RFC 1049. That document defined a
`header field, “Content—types," which marked the entire mes-
`sage body as being a certain type of data. In the absence of
`a Content-type field, the body was assumed to be US ASCII
`text, as before.
`
`Page 2 of 8
`
`

`

`Although RFC 1049 had been used by several impler-
`nentations, it was not without problems. The most severe
`problem was its total lack of support for multipart mail. RFC
`1049 allowed a message body to be specified as containing
`something other than text, but only one such thing.
`MIME generalizes and extends RFC 1049 in several
`ways. Most important, it defines a new Content-type, “mul~
`tipart," which can be used to encapsulate several body parts
`within a single RFC 322 message body. It also goes far
`beyond RFC 1049 in explicitly describing the set of allow-
`able Content-types, which are relatively few, by defining
`a subtype mechanism for Content-types, by providing for
`standardized encoding of non-ASCII data, and by explicitly
`addressing the issue of non-ASCII character sets.
`This paper presents only a high—level overview and sum—
`mary of the new Internet mechanisms. Those interested in
`the technical details, and particularly implementors. should
`consult the official MIME document, RFC 1341 (Borenstein
`and Freed).
`
`In the following section, the MIME standard Content-
`types will each be discussed in turn. Before going into such
`details, however, it is worth noting that the very philosophy
`embodied in MIME’s Content—typer‘subtype mechanism is a
`substantial departure from earlier attempts to standardize in—
`terchange formats. For exarnple, one such attempt was Office
`Document Architecture or ODA (ISO). ODA is a single, in—
`tegrated format for representing enriched text, images, and
`a few other types of objects. The standard is large, specifies
`every detail of how data may he represented, is not easily ex—
`tended, and does not offer the ability to include data in other
`formats that have been found useful in certain communities
`or on certain platforms. In contrast, MIME was designed as
`a mechanism for encapsulating a wide variety of data types
`that have been found useful in different environments and
`
`was explicitly designed for easy extension to include new
`formats that have been found practical in other contexts. In-
`stead of a monolithic approach, MIME represents an attempt
`to design a universal format from the bottom up, by incor—
`porating those formats which have already won acceptance
`for specific media types.
`
`4 The seven mail Content-typos
`
`MIME defines precisely seven valid Content‘types and re-
`quires that any additions to this set be specified in a new,
`similarly formal standards document. This restrictiveness is
`a major change from RFC 1049, which allowed for much
`freer definition of new content types. Instead, the new mech-
`anism for extension is to define new subtypes of estab-
`lished Content-types. In general, implementors are required
`to register nevir subtypes with the Internet Assigned Numbers
`Authority (IANA) to avoid name conflicts. (However, “pri-
`vate” subtypes, beginning with the characters “X—” may be
`used freely and without registration.) The advantage of this
`scheme is that even if the subtype is unrecognized, a mail
`reader is more likely to be able to do something reasonable
`if it knows something about the basic type of data involved.
`
`Page 3 of 8
`
`31
`
`A separate part of the Content-type header field may be
`used to convey supplemental information that may be either
`optional or required, depending on the Content-type. Such
`“parameters” are given in keyword=value notation and are
`used, for example. to convey information about character sets
`for text objects. Thus, the default message type for Internet
`mail may be given a MIME Content-type of:
`
`Content—type:
`text/plain;
`
`charset=us—ascii
`
`The seven defined Content—type values are:
`
`1. Text: This is the default Contentvtype. The default sub—
`type is plain text, with subtypes associated with particular
`rich text formats. Thus a vendor might use “Content-type:
`textfproduct name” for “rich” textual mail, with the under-
`standing that recipients using other mail software might read
`the raw rich text representation. lmportantly, MIME defines
`a subtype of text, “enriched,” that provides a very simple
`lingua franca for those who wish to experiment in multifont
`formatted email. A critical parameter for text subtypes is
`mail reading “charset,” which specifies the character set in
`which the text is written.
`
`2. Image: This Content-type is for still images. Subtypes are
`image format names, two of which, “imagefgif’ and “im-
`agefjpeg", are defined by the core MIME standard. Software
`that does not recognize an image format will at least know
`that it is an image and that showing the raw data to the re
`cipient is not useful. GIF and JPEG were selected as the two
`primary image formats for very practical reasons: they are
`currently the most widely used image formats, with public
`domain software readily available for most major platforms.
`
`3. Audio: This Content-type is for audio information. Sub—
`types are audio format names, one of which is defined by the
`bare MME document. This subtype, “audiofbasic,” denotes
`single—channel 8000 HZ u-law audio data, an intended lingua
`franca for telephone—quality email audio. Again, this format
`was chosen for its ubiquity; it is easily interpreted on nearly
`any computer with audio facilities. It is expected, however,
`that one or more additional subtypes will eventually be de-
`fined for higher-quality compressed audio.
`
`lr’r'deo: Similarly, subtypes correspond to video format
`4.
`names, such as the one defined by MJME, “videofmpeg‘i
`Experimentation with digital video, and particularly video
`mail, is still in its infancy.
`
`5. Message: This Content-type is to be used to encapsu—
`late an entire Internet mail message. For example, it can be
`used in forwarding or rejecting mail. The standard defines
`two subtypes of message: “messagefpartial” can be used to
`break a large message into several pieces for transport, so
`that they may be put back together automatically on the
`other end, and “messagefextemal body” can he used to pass
`a very large message body by reference rather than including
`its entire contents. (The contents may be referred to using
`
`Page 3 of 8
`
`

`

`32
`
`one of a number of standard mechanisms, such as wide-area
`
`file systems or file transfer protocols.) It should be noted
`that a message with “Content-type: message” may contain
`a message that has its own, different Content-type field —
`that is, the message structure may be recursive. The use of
`the “message” type for encapsulation of partial or external
`data, therefore, provides an easy recursive mechanism for
`specifying the type of data in the partial or external entity.
`The various subtypes of “message” have much of their crit-
`ical data specified as parameters on the Content-type header
`field.
`
`6. Multiparr: This Content-type is used to pack several parts,
`of possibly differing types and subtypes, into a single mes-
`sage body. The Content-type field specifying type multipart
`also includes a “boundary” parameter, which is used to sep-
`arate each consecutive body part. Each body paint is itself
`structured more or less as an RFC 822 message in miniature
`
`— in particular, possibly containing its own Content-type field
`to describe the type of the part. Subtypes of multipart are
`specifically required to have the same syntax as the basic
`multipart type, thus guaranteeing that all implementations
`can successfully break a multipart message into its com-
`ponent parts. An expected use of subtypes of multipart is
`to add further structure to the parts to permit a more inte-
`grated structure of multipart messages among cooperating
`user agents. The multipartfaltemative subtype may be used
`to provide multiple representations of the same data.
`
`7. Application: This Content-type is to be used for most
`other kinds of data that do not fit into any of the above
`
`categories, such as Postscript list servers, mail-based infor—
`mation servers, and mail-based application languages such
`as Bellcore‘s ATOMICMAIL language [3].
`
`5 The Content-transfer-encoding field: binary data and
`seven-bit transport
`
`If Internet mail transport (SM’I‘P, as described by RFC 821)
`is ever upgraded to permit arbitrary binary data of unlimited
`line length in message bodies, the issue of encoding a mes—
`sage for transport will go away. However, even those who
`are working towards such changes to SMTP generally recog—
`nize that they will be slow in coming. In the meantime, there
`is wide perception of the need for a standardized mechanism
`for encoding arbitrary binary data for mail transport.
`MIME defines a new header field for this purpose,
`Content-nansfer-encoding, which can be used to specify the
`encoding technique that has been used to render binary data
`in short lines of seven bit data. After much debate, the work-
`
`ing group settled on two cncodings, either of which may be
`used. One of them,
`the “base64” encoding, encodes each
`three bytes of binary data as four bytes of 7—bit data, using
`a base 64 alphabet selected for maximum portability across
`mail systems, including ASCII to EBCDIC gateways. The
`other, the “quoted-printable" encoding, is a less efficient rep—
`resentation that preserves nearly all 7-bit ASCII characters
`as themselves. It is expected that base64 will be preferred
`
`Page 4 of 8
`
`for genuine binary data, while quoted-printable will be pre-
`ferred for data that is largely US—ASCII, but has scattered
`non-ASCH characters within it. In particular, this may be
`the preferred encoding for textual email in the national-use
`variants of ASCII, ISO 8859-X.
`
`If the Content-transfer—encoding field appears in the RFC
`822 message header, it refers to the body of the message.
`If it appears in the “header” area of one part of a multi—
`part message, it refers to the body area of that part only.
`The Content-transfer—encoding field is prohibited when the
`Content-type field has a value of “multipart” or “message.”
`This is necessary in order to prevent nested encodings, as
`described later in this paper.
`
`6 An example of a multipart message
`
`The following example shows the format of a multipart mes—
`sage. This message has three top-level parts, to be displayed
`serially: an introductory plain-text part, an embedded multi—
`part segment, and a closing text in a non-US-ASCII character
`set. The embedded multipart piece itself has two parts to be
`displayed in parallel (if possible), a picture and an audio
`fragment.
`
`From: Nathaniel Borenstein
`<nsb@bellcore.com>
`
`Subject: A MTME message
`MIME—Version: 1.0
`
`Content—type: multipart/mixed;
`boundaryztweedledum
`This text is in the multipart "prefix”
`area and might be invisible to many
`users.
`
`—-tweedledum
`
`This is a multipart measage. This is
`USeASCII text because it is not
`marked otherwise.
`—»tweedledum
`
`Content—type: multipart/parallel;
`boundaryztweedledee
`
`This text is in the mulcipart "prefix“
`area and might be invisible
`to many users.
`-’tweedledee
`
`audio/basic
`Content—type:
`Content—Transfer—Encoding: baseSd
`Content—Description:
`An Audio Message
`
`. basefis—enCOded audio data goes
`here
`——tweedledee
`
`image/git
`Content—type:
`Content—Transfer-Encoding: baseEs
`
`Page 4 of 8
`
`

`

`. base64 encoded gif image data goes
`here
`——tweedledee——
`a—tweedledum
`
`text/plain;
`Content—type:
`Charset=ISO—8859—l
`
`Content~Transfer—Encoding:
`quoted—printable
`
`It's nice to be able to actually use a
`name like "LagerstrzFGm" in the mail!
`—— tweedledum——
`
`Figure 1 shows how an integrated MIME reader, the Andrew
`“messages” program displays this example message. Note
`that
`the audio fragment is displayed as a button the user
`clicks on to hear the audio. Figure 2 shows how a non-
`integrated MIME reader, the metamail program, views the
`same message. Note that the user was offered a chance to
`listen to the audio but declined, knowing that it would in
`any event not show up very well in Fig.2.
`
`7 The MJNIE extension mechanisms
`
`The authors of MIME recognized early on that they were
`unable to specify fully all the different types of data that
`would ultimately be needed and desired for use in electronic
`mail. Instead of attempting to do so — which was the basic
`approach taken in the definition of X400, ODA, and most
`other relevant approaches to standardization — they focused
`instead on ensuring that MIME would be easily extended to
`accomodate additional formats (typically as new subtypes) as
`they became relevant. Thus, for example, the lack of a high—
`quality audio subtype in MIME was not considered critical
`by the authors, as long as it
`is easy for audio experts to
`define such a subtype and have it added to MIME in the
`future.
`
`MIME extension works by a simple process. The inter-
`ested parties work together to define the format details of
`a new MIME subtype and publish those details as an In-
`ternet RFC, or “requests for comments”. Among the details
`they must specify are the typel’subtype name by which the
`new format will be known. This typelsubtype pair — along
`with any required or optional parameters for the Content-
`type header field — are registered with the lntemet Assigned
`Names Authority (IANA) to ensure that the typefsubtype
`names are unique identifiers for a given format. Such formats
`are considered “experimental” unless and until the RFCs that
`define them have passed through the Internet standards pro-
`cess and been declared to be official Internet standards.
`
`In general, it is expected that most of what will be reg-
`istered with IANA will be subtypes of the seven existing
`MIME types, but it is possible that the development of new
`media types (such as odor or virtual reality) might neces—
`sitate the addition of a few new top—level types eventually.
`
`Page 5 of 8
`
`33
`
`IANA will also register new values for certain critical MIME
`parameters such as character sets.
`
`8 Controversies and problems
`
`Not surprisingly, in an effort to devise a standard approach to
`a shared multipart multimedia mail facility, there have been
`a number of controversies and problems along the way. In
`order to understand the design of this approach, it is helpful
`to understand some of the discussions that led to its current
`structure.
`
`is that the
`One thing worth noting initially, however,
`MIME effort was largely able to avoid “holy wars" between
`advocates of two different formats. Not a lot of time was
`
`wasted, for example, on the question of the relative mer-
`its of GIF and JPEG as image formats. Instead, the MIME
`mechanisms allow the sender to use either format (or, using
`multipartfaltemative.
`to use both formats) and expect that
`mail readers will evolve to support all the formats that come
`into widespread use. Because MIME is an open-ended evolu-
`tionary framework for encapsulating data of multiple types,
`holy wars were largely avoided.
`Several other issues were less easily skirted, however.
`
`8.] Nested encoding
`
`In an early draft of MIME, encodings were permitted on an
`entire message or any of its sub—parts. Ultimately, however,
`encodings were forbidden when the Content-type was “mul-
`tipatt” or “message.” If messages or parts of those types
`were encoded, this would mean that the overall structure of
`
`a message — its breakdown into its smallest constituent parts
`- might not be visible without a decoding operation, a situa-
`tion which many people found unacceptable. Moreover, this
`could lead to nested encodings, where the same data were
`passed multiple times through an encoding algorithm and
`had to be decoded several times as well. The inefficiency of
`this possibility was distressing to many. One consequence
`of the ban on nested encoding may be somewhat increased
`complexity for gateways. A gateway between a hypotheti-
`cal future 8-bit SMTP mail world and a 7-bit world would
`
`presumably have to encode 8-bit messages; in the case of
`multipart messages, it will now have to parse the body and
`encode only the lowest-level parts, rather than simply pass-
`ing the whole message through an encoding. However, this
`was felt to be less troublesome than the consequences of per-
`mitting nested encodings, possibly because the discussants
`were generally more concerned with user agents than with
`hypothetical future gateways from a transport system that
`does not yet exist.
`
`8.2 Compression
`
`It was widely felt that, in addition to quoted-printable and
`base64, there should be a compressed encoding mechanism,
`possibly based on the UNIX compress facility. No such
`
`Page 5 of 8
`
`

`

`' greenbuah :1le 289 a ahmafl
`Fran; Nathaniel Borenateiri mammalian: com
`Subject: a m message
`
`This is a multipart manage.
`narlusd otherwise.
`
`Ibis is USarson text: because It a: not.
`
`Contont——Deacriptiorn: M hudio assuage
`
`This museum contains ‘audiofbasic‘ Jon-at. data.
`Do you want to view it using the ‘shnaaudin’ command tyfll)
`
`lyl ? n
`
`This message contains inagafgif‘ Jamar. data.
`no you want: to view it using the ‘shocpinture‘ command firm)
`———mcuting: show-picture
`HD'IE' TO m 1!! PICTURE VIN'DEIIT 00 A“? JUST TYPE q Ill IT.
`--) TO SAVE HIS IEB‘E. GOP? THE FILE ltarpflm. 3.06932 BEFORE EKI'HNG
`
`I!” 7 Y
`
`greanhush nab 290 x
`
`Bellcore
`
`———I:e outing: ahomnaacii
`
`It‘ a nice to be able to actually use a name like "Lagerstrtm in the
`naill
`
`2
`
`ma (M; a new at 21551
`rooo (Show-AllSuhsm'flied)
`recounts (Ask—Suhsuihed; No New}
`
`renown (Show—All Subsuibed; Empty)rd
`
`——Apt.‘93 Gefitwt‘ogeh’aerbym- Philip Bunotfilspscebbs. t: (1322.)
`r—93 AWEW— Nathaniel Bummteanhel [2579‘]
`
`Hum: Nadia-rid Bernstein msflbeflcurecmu:
`Subject: A MIME message
`MIM E — Version: 11]
`
`This is amultipert mess age This is US— ASCII texthecause Eris not marked otherwise.
`
`1
`
`it's ejects beahnmathueanmc'tagum-nn' inthe mall!
`
`Stamgprc—Eehch of TODD... clone.
`
`Fig. 1. How the multipart MIME example looks using the Andrew “messages" program, an integrated MIME reader
`Fig. 2. How the multipart MIME example looks using the meta mail program, a non—integrated MIME reader
`
`mechanism is currently specified. both because of a lack
`of compression expertise among the authors and because of
`the uncertain legallpatent situation regarding the commonly
`used compression algorithms.
`
`8.3 Uueucode
`
`Initially, many people questioned the use of the new base64
`scheme instead of the widely available “uuencode” mech-
`anism. Uuencodc was considered and rejected for several
`reasons.
`[I is nowhere well specified and in fact there are
`several uuencode implementations that do not interoperate.
`The output of uuencode is not robust across many mail gate-
`ways, owing to problems of character set and the cavalier
`way many relays treat “white space” in message bodies. It
`is not uncommon for uuencoded files to arrive at a remote
`
`site in a form from which they simply cannot be decoded.
`The base64 format was designed specifically to avoid the
`problems associated with uuencodc.
`
`8.4 Number of Content-types
`
`There was a significant initial controversy about the over—
`all numbcr of Content—types to be permitted. Some favored
`a “let a thousand flowers bloom” phi1030phy, while oth-
`ers wanted assurances that mail readers would have a good
`prospect of recognizing the Content—type. The subtype mech-
`anism was a very successful compromise that met the needs
`of both camps.
`
`Page 6 of 8
`
`8.5 Relation to X400
`
`As stated previously, the new Internet mechanisms are the
`result of a remarkable degree of cooperation between X400
`advocates, die—hard X400 opponents, and everyone in be—
`tween. Not surprisingly, many issues of X.400 gatewaying
`have arisen. but most of these have been deferred to a follow—
`
`up document that will specify how X400 gateways should
`use and interpret the new Internet mechanisms. However,
`such issues were discussed long enough to determine that
`the new mechanisms would not be too problematic for such
`gateways. Indeed, several aspects of MIME are expressly
`designed to facilitate the implementation of such gateways.
`
`8.6 Parts are not messages
`
`The alert reader may have wondered why the “message" type
`is necessary in the presence of “multipartf’ The answer is that
`the parts of multipart mechanisms are explicitly specified as
`not being actual RFC 822 messages, but rather a new type of
`object (parts) that have very similar syntax. This distinction,
`it turns out, is important for X400 gateways. In the absence
`of this distinction, it is impossible to tell the difference be-
`tween 3 multipart message containing an audio part and a
`multipart message containing an encapsulated message, the
`body of which is of Content-type audio. The partlmessage
`distinction allows a more precise semantic mapping between
`the Internet and X400 models.
`
`8. 7 Multipart boundaries
`
`The boundary delimiters that separate The parts of a multipart
`message have themselves been the subject of a remarkable
`amount of controversy. After much debate, MTMF. specifics
`
`Page 6 of 8
`
`

`

`that the area before the first delimiter and the area after the
`
`8..” Character set specification
`
`35
`
`last delimiter is to be ignored, and that gateways — partic—
`ularly gateways to X3400, which has no concept of such a
`“prefix” or “postscript” — are free to throw them away. It
`also specifies that a delimiter string appears as part of the
`“Content-type: multipart” header field and that the interpart
`delimiter will consist of two hyphens (“- -”) followed by
`that string, except that the last delimiter will end with an
`additional pair of hyphens. Moreover, no such delimiter line
`is permitted to appear in any of the parts, so that a com-
`posing agent must choose its delimiter with care. Although
`these requirements may seem somewhat baroque, they are
`not without their reasons.
`
`8.8 Implications of 8-bit or binary transports
`
`Those who worked on the extensions to RFC 822 were
`
`sharply divided in their opinions regarding the desirability
`and feasability of 8—bit or binary transport,
`i.e., extended
`SMTP. The group’s progress was made,
`in large part, by
`agreeing to disagree on this issue. The result is that the
`current mechanisms will work with 7—bit transport, but will
`move gracefully into an 8-bit world should 8—bit transport
`become commonplace in accordance with the mechanisms
`currently being drafted by the SMTP extensions working
`group. However, both groups are united in rejecting an alter—
`native approach that has been advocated in a recent Internet
`Draft (Ullmann) that essentially declares SMTP to permit
`8—bi