Network Working Group N. Borenstein
`Request for Comments: 1521 Bellcore
`Obsoletes: 1341 N. Freed
`Category: Standards Track Innosoft
` September 1993
`
` MIME (Multipurpose Internet Mail Extensions) Part One:
` Mechanisms for Specifying and Describing
` the Format of Internet Message Bodies
`
`Status of this Memo
`
` This RFC specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" for the standardization state and status
` of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
` STD 11, 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 STD 11, 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. Such extensions are the
` subject of a companion document [RFC-1522].
`
` This document is a revision of RFC 1341. Significant differences
` from RFC 1341 are summarized in Appendix H.
`
`Borenstein & Freed [Page 1]
`
`Page 1 of 81
`
`AT&T EXHIBIT 1018
`
`

`

`RFC 1521 MIME September 1993
`
`Table of Contents
`
` 1. Introduction....................................... 3
` 2. Notations, Conventions, and Generic BNF Grammar.... 6
` 3. The MIME-Version Header Field...................... 7
` 4. The Content-Type Header Field...................... 9
` 5. The Content-Transfer-Encoding Header Field......... 13
` 5.1. Quoted-Printable Content-Transfer-Encoding......... 18
` 5.2. Base64 Content-Transfer-Encoding................... 21
` 6. Additional Content-Header Fields................... 23
` 6.1. Optional Content-ID Header Field................... 23
` 6.2. Optional Content-Description Header Field.......... 24
` 7. The Predefined Content-Type Values................. 24
` 7.1. The Text Content-Type.............................. 24
` 7.1.1. The charset parameter.............................. 25
` 7.1.2. The Text/plain subtype............................. 28
` 7.2. The Multipart Content-Type......................... 28
` 7.2.1. Multipart: The common syntax...................... 29
` 7.2.2. The Multipart/mixed (primary) subtype.............. 34
` 7.2.3. The Multipart/alternative subtype.................. 34
` 7.2.4. The Multipart/digest subtype....................... 36
` 7.2.5. The Multipart/parallel subtype..................... 37
` 7.2.6. Other Multipart subtypes........................... 37
` 7.3. The Message Content-Type........................... 38
` 7.3.1. The Message/rfc822 (primary) subtype............... 38
` 7.3.2. The Message/Partial subtype........................ 39
` 7.3.3. The Message/External-Body subtype.................. 42
` 7.3.3.1. The "ftp" and "tftp" access-types............... 44
` 7.3.3.2. The "anon-ftp" access-type...................... 45
` 7.3.3.3. The "local-file" and "afs" access-types......... 45
` 7.3.3.4. The "mail-server" access-type................... 45
` 7.3.3.5. Examples and Further Explanations............... 46
` 7.4. The Application Content-Type....................... 49
` 7.4.1. The Application/Octet-Stream (primary) subtype..... 50
` 7.4.2. The Application/PostScript subtype................. 50
` 7.4.3. Other Application subtypes......................... 53
` 7.5. The Image Content-Type............................. 53
` 7.6. The Audio Content-Type............................. 54
` 7.7. The Video Content-Type............................. 54
` 7.8. Experimental Content-Type Values................... 54
` 8. Summary............................................ 56
` 9. Security Considerations............................ 56
` 10. Authors’ Addresses................................. 57
` 11. Acknowledgements................................... 58
` Appendix A -- Minimal MIME-Conformance.................... 60
` Appendix B -- General Guidelines For Sending Email Data... 63
` Appendix C -- A Complex Multipart Example................. 66
` Appendix D -- Collected Grammar........................... 68
`
`Borenstein & Freed [Page 2]
`
`Page 2 of 81
`
`

`

`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 [Page 3]
`
`Page 3 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` 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 another
` 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.
`
`Borenstein & Freed [Page 4]
`
`Page 4 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` 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 additional 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 E 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: Several of the mechanisms described in this
` document may seem somewhat strange or even baroque at first
` reading. It is important to note that compatibility with existing
` standards AND robustness across existing practice were two of the
` highest priorities of the working group that developed this
` document. In particular, compatibility was always favored over
` elegance.
`
` MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]
` [RFC-1342]. This document is a relatively minor updating of RFC
` 1341, and is intended to supersede it. The differences between this
` document and RFC 1341 are summarized in Appendix H. Please refer to
` the current edition of the "IAB Official Protocol Standards" for the
` standardization state and status of this protocol. Several other RFC
` documents will be of interest to the MIME implementor, in particular
` [RFC 1343], [RFC-1344], and [RFC-1345].
`
`Borenstein & Freed [Page 5]
`
`Page 5 of 81
`
`

`

`RFC 1521 MIME September 1993
`
`2. Notations, Conventions, and Generic BNF Grammar
`
` This document is being published in two versions, one as plain ASCII
` text and one as PostScript (PostScript is a trademark of Adobe
` Systems Incorporated.). While the text version is the official
` specification, some will find the PostScript version easier to read.
` The textual contents are identical. An Andrew-format copy of this
` document is also available from the first author (Borenstein).
`
` Although the mechanisms specified in this document are all described
` in prose, most are also described formally in the modified BNF
` notation of RFC 822. Implementors will need to be familiar with this
` notation in order to understand this specification, and are referred
` to RFC 822 for a complete explanation of the modified BNF notation.
`
` Some of the modified BNF in this document makes reference to
` syntactic entities that are defined in RFC 822 and not in this
` document. A complete formal grammar, then, is obtained by combining
` the collected grammar appendix of this document with that of RFC 822
` plus the modifications to RFC 822 defined in RFC 1123, which
` specifically changes the syntax for ‘return’, ‘date’ and ‘mailbox’.
`
` The term CRLF, in this document, refers to the sequence of the two
` ASCII characters CR (13) and LF (10) which, taken together, in this
` order, denote a line break in RFC 822 mail.
`
` The term "character set" is used in this document to refer to a
` method used with one or more tables to convert encoded text to a
` series of octets. This definition is intended to allow various kinds
` of text encodings, from simple single-table mappings such as ASCII to
` complex table switching methods such as those that use ISO 2022’s
` techniques. However, a MIME character set name must fully specify
` the mapping to be performed.
`
` The term "message", when not further qualified, means either the
` (complete or "top-level") message being transferred on a network, or
` a message encapsulated in a body of type "message".
`
` The term "body part", in this document, means one of the parts of the
` body of a multipart entity. A body part has a header and a body, so
` it makes sense to speak about the body of a body part.
`
` The term "entity", in this document, means either a message or a body
` part. All kinds of entities share the property that they have a
` header and a body.
`
` The term "body", when not further qualified, means the body of an
` entity, that is the body of either a message or of a body part.
`
`Borenstein & Freed [Page 6]
`
`Page 6 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` NOTE: The previous four definitions are clearly circular. This is
` unavoidable, since the overall structure of a MIME message is
` indeed recursive.
`
` In this document, all numeric and octet values are given in decimal
` notation.
`
` It must be noted that Content-Type values, subtypes, and parameter
` names as defined in this document are case-insensitive. However,
` parameter values are case-sensitive unless otherwise specified for
` the specific parameter.
`
` FORMATTING NOTE: This document has been carefully formatted for
` ease of reading. The PostScript version of this document, in
` particular, places notes like this one, which may be skipped by
` the reader, in a smaller, italicized, font, and indents it as
` well. In the text version, only the indentation is preserved, so
` if you are reading the text version of this you might consider
` using the PostScript version instead. However, all such notes will
` be indented and preceded by "NOTE:" or some similar introduction,
` even in the text version.
`
` The primary purpose of these non-essential notes is to convey
` information about the rationale of this document, or to place this
` document in the proper historical or evolutionary context. Such
` information may be skipped by those who are focused entirely on
` building a conformant implementation, but may be of use to those
` who wish to understand why this document is written as it is.
`
` For ease of recognition, all BNF definitions have been placed in a
` fixed-width font in the PostScript version of this document.
`
`3. The MIME-Version Header Field
`
` Since RFC 822 was published in 1982, there has really been only one
` format standard for Internet messages, and there has been little
` perceived need to declare the format standard in use. This document
` is an independent document that complements RFC 822. Although the
` extensions in this document have been defined in such a way as to be
` compatible with RFC 822, there are still circumstances in which it
` might be desirable for a mail-processing agent to know whether a
` message was composed with the new standard in mind.
`
` Therefore, this document defines a new header field, "MIME-Version",
` which is to be used to declare the version of the Internet message
` body format standard in use.
`
` Messages composed in accordance with this document MUST include such
`
`Borenstein & Freed [Page 7]
`
`Page 7 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` a header field, with the following verbatim text:
`
` MIME-Version: 1.0
`
` The presence of this header field is an assertion that the message
` has been composed in compliance with this document.
`
` Since it is possible that a future document might extend the message
` format standard again, a formal BNF is given for the content of the
` MIME-Version field:
`
` version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
`
` Thus, future format specifiers, which might replace or extend "1.0",
` are constrained to be two integer fields, separated by a period. If
` a message is received with a MIME-version value other than "1.0", it
` cannot be assumed to conform with this specification.
`
` Note that the MIME-Version header field is required at the top level
` of a message. It is not required for each body part of a multipart
` entity. It is required for the embedded headers of a body of type
` "message" if and only if the embedded message is itself claimed to be
` MIME-conformant.
`
` It is not possible to fully specify how a mail reader that conforms
` with MIME as defined in this document should treat a message that
` might arrive in the future with some value of MIME-Version other than
` "1.0". However, conformant software is encouraged to check the
` version number and at least warn the user if an unrecognized MIME-
` version is encountered.
`
` It is also worth noting that version control for specific content-
` types is not accomplished using the MIME-Version mechanism. In
` particular, some formats (such as application/postscript) have
` version numbering conventions that are internal to the document
` format. Where such conventions exist, MIME does nothing to supersede
` them. Where no such conventions exist, a MIME type might use a
` "version" parameter in the content-type field if necessary.
`
` NOTE TO IMPLEMENTORS: All header fields defined in this document,
` including MIME-Version, Content-type, etc., are subject to the
` general syntactic rules for header fields specified in RFC 822. In
` particular, all can include comments, which means that the following
` two MIME-Version fields are equivalent:
`
` MIME-Version: 1.0
` MIME-Version: 1.0 (Generated by GBD-killer 3.7)
`
`Borenstein & Freed [Page 8]
`
`Page 8 of 81
`
`

`

`RFC 1521 MIME September 1993
`
`4. The Content-Type Header Field
`
` The purpose of the Content-Type field is to describe the data
` contained in the body fully enough that the receiving user agent can
` pick an appropriate agent or mechanism to present the data to the
` user, or otherwise deal with the data in an appropriate manner.
`
` HISTORICAL NOTE: The Content-Type header field was first defined in
` RFC 1049. RFC 1049 Content-types used a simpler and less powerful
` syntax, but one that is largely compatible with the mechanism given
` here.
`
` The Content-Type header field is used to specify the nature of the
` data in the body of an entity, by giving type and subtype
` identifiers, and by providing auxiliary information that may be
` required for certain types. After the type and subtype names, the
` remainder of the header field is simply a set of parameters,
` specified in an attribute/value notation. The set of meaningful
` parameters differs for the different types. In particular, there are
` NO globally-meaningful parameters that apply to all content-types.
` Global mechanisms are best addressed, in the MIME model, by the
` definition of additional Content-* header fields. The ordering of
` parameters is not significant. Among the defined parameters is a
` "charset" parameter by which the character set used in the body may
` be declared. Comments are allowed in accordance with RFC 822 rules
` for structured header fields.
`
` In general, the top-level Content-Type is used to declare the general
` type of data, while the subtype specifies a specific format for that
` type of data. Thus, a Content-Type of "image/xyz" is enough to tell
` a user agent that the data is an image, even if the user agent has no
` knowledge of the specific image format "xyz". Such information can
` be used, for example, to decide whether or not to show a user the raw
` data from an unrecognized subtype -- such an action might be
` reasonable for unrecognized subtypes of text, but not for
` unrecognized subtypes of image or audio. For this reason, registered
` subtypes of audio, image, text, and video, should not contain
` embedded information that is really of a different type. Such
` compound types should be represented using the "multipart" or
` "application" types.
`
` Parameters are modifiers of the content-subtype, and do not
` fundamentally affect the requirements of the host system. Although
` most parameters make sense only with certain content-types, others
` are "global" in the sense that they might apply to any subtype. For
` example, the "boundary" parameter makes sense only for the
` "multipart" content-type, but the "charset" parameter might make
` sense with several content-types.
`
`Borenstein & Freed [Page 9]
`
`Page 9 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` An initial set of seven Content-Types is defined by this document.
` This set of top-level names is intended to be substantially complete.
` It is expected that additions to the larger set of supported types
` can generally be accomplished by the creation of new subtypes of
` these initial types. In the future, more top-level types may be
` defined only by an extension to this standard. If another primary
` type is to be used for any reason, it must be given a name starting
` with "X-" to indicate its non-standard status and to avoid a
` potential conflict with a future official name.
`
` In the Augmented BNF notation of RFC 822, a Content-Type header field
` value is defined as follows:
`
` content := "Content-Type" ":" type "/" subtype *(";"
` parameter)
` ; case-insensitive matching of type and subtype
`
` type := "application" / "audio"
` / "image" / "message"
` / "multipart" / "text"
` / "video" / extension-token
` ; All values case-insensitive
`
` extension-token := x-token / iana-token
`
` iana-token := <a publicly-defined extension token,
` registered with IANA, as specified in
` appendix E>
`
` x-token := <The two characters "X-" or "x-" followed, with
` no intervening white space, by any token>
`
` subtype := token ; case-insensitive
`
` parameter := attribute "=" value
`
` attribute := token ; case-insensitive
`
` value := token / quoted-string
`
` token := 1*<any (ASCII) CHAR except SPACE, CTLs,
` or tspecials>
`
` tspecials := "(" / ")" / "<" / ">" / "@"
` / "," / ";" / ":" / "\" / <">
` / "/" / "[" / "]" / "?" / "="
` ; Must be in quoted-string,
` ; to use within parameter values
`
`Borenstein & Freed [Page 10]
`
`Page 10 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` Note that the definition of "tspecials" is the same as the RFC 822
` definition of "specials" with the addition of the three characters
` "/", "?", and "=", and the removal of ".".
`
` Note also that a subtype specification is MANDATORY. There are no
` default subtypes.
`
` The type, subtype, and parameter names are not case sensitive. For
` example, TEXT, Text, and TeXt are all equivalent. Parameter values
` are normally case sensitive, but certain parameters are interpreted
` to be case-insensitive, depending on the intended use. (For example,
` multipart boundaries are case-sensitive, but the "access-type" for
` message/External-body is not case-sensitive.)
`
` Beyond this syntax, the only constraint on the definition of subtype
` names is the desire that their uses must not conflict. That is, it
` would be undesirable to have two different communities using
` "Content-Type: application/foobar" to mean two different things. The
` process of defining new content-subtypes, then, is not intended to be
` a mechanism for imposing restrictions, but simply a mechanism for
` publicizing the usages. There are, therefore, two acceptable
` mechanisms for defining new Content-Type subtypes:
`
` 1. Private values (starting with "X-") may be
` defined bilaterally between two cooperating
` agents without outside registration or
` standardization.
`
` 2. New standard values must be documented,
` registered with, and approved by IANA, as
` described in Appendix E. Where intended for
` public use, the formats they refer to must
` also be defined by a published specification,
` and possibly offered for standardization.
`
` The seven standard initial predefined Content-Types are detailed in
` the bulk of this document. They are:
`
` text -- textual information. The primary subtype,
` "plain", indicates plain (unformatted) text. No
` special software is required to get the full
` meaning of the text, aside from support for the
` indicated character set. Subtypes are to be used
` for enriched text in forms where application
` software may enhance the appearance of the text,
` but such software must not be required in order to
` get the general idea of the content. Possible
` subtypes thus include any readable word processor
`
`Borenstein & Freed [Page 11]
`
`Page 11 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` format. A very simple and portable subtype,
` richtext, was defined in RFC 1341, with a future
` revision expected.
`
` multipart -- data consisting of multiple parts of
` independent data types. Four initial subtypes
` are defined, including the primary "mixed"
` subtype, "alternative" for representing the same
` data in multiple formats, "parallel" for parts
` intended to be viewed simultaneously, and "digest"
` for multipart entities in which each part is of
` type "message".
`
` message -- an encapsulated message. A body of
` Content-Type "message" is itself all or part of a
` fully formatted RFC 822 conformant message which
` may contain its own different Content-Type header
` field. The primary subtype is "rfc822". The
` "partial" subtype is defined for partial messages,
` to permit the fragmented transmission of bodies
` that are thought to be too large to be passed
` through mail transport facilities. Another
` subtype, "External-body", is defined for
` specifying large bodies by reference to an
` external data source.
`
` image -- image data. Image requires a display device
` (such as a graphical display, a printer, or a FAX
` machine) to view the information. Initial
` subtypes are defined for two widely-used image
` formats, jpeg and gif.
`
` audio -- audio data, with initial subtype "basic".
` Audio requires an audio output device (such as a
` speaker or a telephone) to "display" the contents.
`
` video -- video data. Video requires the capability to
` display moving images, typically including
` specialized hardware and software. The initial
` subtype is "mpeg".
`
` application -- some other kind of data, typically
` either uninterpreted binary data or information to
` be processed by a mail-based application. The
` primary subtype, "octet-stream", is to be used in
` the case of uninterpreted binary data, in which
` case the simplest recommended action is to offer
` to write the information into a file for the user.
`
`Borenstein & Freed [Page 12]
`
`Page 12 of 81
`
`

`

`RFC 1521 MIME September 1993
`
` An additional subtype, "PostScript", is defined
` for transporting PostScript documents in bodies.
` Other expected uses for "application" include
` spreadsheets, data for mail-based scheduling
` systems, and languages for "active"
` (computational) email. (Note that active email
` and other application data may entail several
` security considerations, which are discussed later
` in this memo, particularly in the context of
` application/PostScript.)
`
` Default RFC 822 messages are typed by this protocol as plain text in
` the US-ASCII character set, which can be explicitly specified as
` "Content-type: text/plain; charset=us-ascii". If no Content-Type is
` specified, this default is assumed. In the presence of a MIME-
` Version header field, a receiving User Agent can also assume that
` plain US-ASCII text was the sender’s intent. In the absence of a
` MIME-Version specification, plain US-ASCII text must still be
` assumed, but the sender’s intent might have been otherwise.
`
` RATIONALE: In the absence of any Content-Type header field or
` MIME-Version header field, it is impossible to be certain th