Network Working Group
`Request for Comments: 1341
`
`N. Borenstein, Bellcore
`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]
`
`Ex. 1008 - Page 1 of 70
`
`Groupon, Inc.
`Exhibit 1008
`
`

`

`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-
`
`Borenstein & Freed
`
`[Page 1]
`
`Ex. 1008 - Page 2 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`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.
`
`textual
`2.a. A "text" Content-Type value, which can be used to represent
`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.
`
`Borenstein & Freed
`
`[Page 2]
`
`Ex. 1008 - Page 3 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`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.
`
`2
`
`Notations, Conventions, and Generic BNF Grammar
`
`This document is being published in two versions, one as plain ASCII text and one as
`PostScript. The latter is recommended, though 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.
`
`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", wherever it is used in this document, refers to a coded character
`set,
`in the sense of
`ISO character set standardization work, and must not be
`misinterpreted as meaning "a set of characters."
`
`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 3]
`
`Ex. 1008 - Page 4 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`Note : the previous four definitions are clearly circular. This is unavoidable, since the
`overal 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 compliant 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 a header
`field, with the following verbatim text:
`
`Borenstein & Freed
`
`[Page 4]
`
`Ex. 1008 - Page 5 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`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:
`
`MIME-Version := text
`
`Thus, future format specifiers, which might replace or extend "1.0", are (minimally)
`constrained by the definition of "text", which appears in RFC 822.
`
`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-compliant.
`
`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. 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
`
`Borenstein & Freed
`
`[Page 5]
`
`Ex. 1008 - Page 6 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`"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.
`
`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 Extended BNF notation of RFC 822, a Content-Type header field value is defined
`as follows:
`
`Content-Type := type "/" subtype *[";" parameter]
`
`type :=
`
`"application"
`/ "image"
`/ "multipart"
`/ "video"
`
`/ "audio"
`/ "message"
`/ "text"
`/ x-token
`
`x-token := <The two characters "X-" followed, with no
`intervening white space, by any token>
`
`subtype := token
`
`parameter := attribute "=" value
`
`attribute := token
`
`value := token / quoted-string
`
`token := 1*<any CHAR except SPACE, CTLs, or tspecials>
`
`tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
`/ "," / ";" / ":" / "\" / <"> ; quoted-string,
`/ "/" / "[" / "]" / "?" / "." ; to use within
`/ "="
`; parameter values
`
`Note that the definition of "tspecials" is the same as the RFC 822 definition of "specials"
`with the addition of the three characters "/", "?", and "=".
`
`Note also that a subtype specification is MANDATORY. There are no default subtypes.
`
`Borenstein & Freed
`
`[Page 6]
`
`Ex. 1008 - Page 7 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`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 F. 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 --
`
`indicates plain
`information. The primary subtype, "plain",
`textual
`(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 format. A very simple
`and portable subtype, richtext, is defined in this document.
`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
`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.
`
`Borenstein & Freed
`
`[Page 7]
`
`Ex. 1008 - Page 8 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`image --
`Image requires a display device (such as a graphical
`image data.
`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. Two additional subtypes, "ODA"
`and "PostScript", are defined for
`transporting ODA and 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 entails several
`securityconsiderations, 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, either by error or by an older user agent, 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.
`
`In the absence of any Content-Type header field or MIME-Version
`RATIONALE:
`header field, it is impossible to be certain that a message is actually text in the US-ASCII
`character set, since it might well be a message that, using the conventions that predate
`this document, includes text in another character set or non-textual data in a manner that
`cannot be automatically recognized (e.g., a uuencoded compressed UNIX tar file).
`Although there is no fully acceptable alternative to treating such untyped messages as
`"text/plain; charset=us-ascii", implementors should remain aware that if a message lacks
`both the MIME-Version and the Content-Type header fields, it may in practice contain
`almost anything.
`
`It should be noted that the list of Content-Type values given here may be augmented in
`time, via the mechanisms described above, and that the set of subtypes is expected to
`grow substantially.
`
`When a mail reader encounters mail with an unknown Content-type value, it should
`generally treat it as equivalent to "application/octet-stream", as described later in this
`document.
`
`Borenstein & Freed
`
`[Page 8]
`
`Ex. 1008 - Page 9 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`5
`
`The Content-Transfer-Encoding Header Field
`
`Many Content-Types which could usefully be transported via email are represented, in
`their "natural" format, as 8-bit character or binary data. Such data cannot be transmitted
`over some transport protocols. For example, RFC 821 restricts mail messages to 7-bit
`US-ASCII data with 1000 character lines.
`
`It is necessary, therefore, to define a standard mechanism for re-encoding such data into a
`7-bit short-line format. This document specifies that such encodings will be indicated by
`a new "Content-Transfer-Encoding" header field. The Content-Transfer-Encoding field
`is used to indicate the type of transformation that has been used in order to represent the
`body in an acceptable manner for transport.
`
`is
`a proliferation of Content-Transfer-Encoding values
`Unlike Content-Types,
`undesirable and unnecessary. However, establishing only a single Content-Transfer-
`Encoding mechanism does not seem possible. There is a tradeoff between the desire for
`a compact and efficient encoding of largely-binary data and the desire for a readable
`encoding of data that is mostly, but not entirely, 7-bit data. For this reason, at least two
`encoding mechanisms are necessary: a "readable" encoding and a "dense" encoding.
`
`The Content-Transfer-Encoding field is designed to specify an invertible mapping
`between the "native" representation of a type of data and a representation that can be
`readily exchanged using 7 bit mail transport protocols, such as those defined by RFC 821
`(SMTP). This field has not been defined by any previous standard. The field’s value is a
`single token specifying the type of encoding, as enumerated below. Formally:
`
`Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
`"8BIT"
`/ "7BIT" /
`"BINARY" / x-token
`
`These values are not case sensitive. That is, Base64 and BASE64 and bAsE64 are all
`equivalent. An encoding type of 7BIT requires that the body is already in a seven-bit
`mail-ready representation. This is the default value -- that
`is, "Content-Transfer-
`Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.
`
`The values "8bit", "7bit", and "binary" all imply that NO encoding has been performed.
`However, they are potentially useful as indications of the kind of data contained in the
`object, and therefore of the kind of encoding that might need to be performed for
`transmission in a given transport system. "7bit" means that the data is all represented as
`short lines of US-ASCII data. "8bit" means that the lines are short, but there may be
`non-ASCII characters (octets with the high-order bit set). "Binary" means that not only
`may non-ASCII characters be present, but also that the lines are not necessarily short
`enough for SMTP transport.
`
`The difference between "8bit" (or any other conceivable bit-width token) and the
`"binary" token is that "binary" does not require adherence to any limits on line length or
`to the SMTP CRLF semantics, while the bit-width tokens do require such adherence. If
`
`Borenstein & Freed
`
`[Page 9]
`
`Ex. 1008 - Page 10 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`the body contains data in any bit-width other than 7-bit, the appropriate bit-width
`Content-Transfer-Encoding token must be used (e.g., "8bit" for unencoded 8 bit wide
`data). If the body contains binary data, the "binary" Content-Transfer-Encoding token
`must be used.
`
`NOTE: The distinction between the Content-Transfer-Encoding values of "binary,"
`"8bit," etc. may seem unimportant, in that all of them really mean "none" -- that is, there
`has been no encoding of the data for transport. However, clear labeling will be of
`enormous value to gateways between future mail
`transport systems with differing
`capabilities in transporting data that do not meet the restrictions of RFC 821 transport.
`
`As of the publication of this document, there are no standardized Internet transports for
`which it is legitimate to include unencoded 8-bit or binary data in mail bodies. Thus there
`are no circumstances in which the "8bit" or "binary" Content-Transfer-Encoding is
`actually legal on the Internet. However, in the event that 8-bit or binary mail transport
`becomes a reality in Internet mail, or when this document is used in conjunction with any
`other 8-bit or binary-capable transport mechanism, 8-bit or binary bodies should be
`labeled as such using this mechanism.
`
`NOTE: The five values defined for the Content-Transfer-Encoding field imply nothing
`about the Content-Type other than the algorithm by which it was encoded or the transport
`system requirements if unencoded.
`
`Implementors may, if necessary, define new Content-Transfer-Encoding values, but must
`use an x-token, which is a name prefixed by "X-" to indicate its non-standard status, e.g.,
`"Content-Transfer-Encoding: x-my-new-encoding". However, unlike Content-Types
`and subtypes, the creation of new Content-Transfer-Encoding values is explicitly and
`strongly discouraged, as it seems likely to hinder interoperability with little potential
`benefit. Their use is allowed only as the result of an agreement between cooperating user
`agents.
`
`If a Content-Transfer-Encoding header field appears as part of a message header, it
`applies to the entire body of that message. If a Content-Transfer-Encoding header field
`appears as part of a body part’s headers, it applies only to the body of that body part. If
`an entity is of type "multipart" or "message", the Content-Transfer-Encoding is not
`permitted to have any value other than a bit width (e.g., "7bit", "8bit", etc.) or "binary".
`
`It should be noted that email is character-oriented, so that the mechanisms described here
`are mechanisms for encoding arbitrary byte streams, not bit streams. If a bit stream is to
`be encoded via one of these mechanisms, it must first be converted to an 8-bit byte
`stream using the network standard bit order ("big-endian"), in which the earlier bits in a
`stream become the higher-order bits in a byte. A bit stream not ending at an 8-bit
`boundary must be padded with zeroes. This document provides a mechanism for noting
`the addition of such padding in the case of the application Content-Type, which has a
`"padding" parameter.
`
`Borenstein & Freed
`
`[Page 10]
`
`Ex. 1008 - Page 11 of 70
`
`

`

`RFC 1341
`
`MIME: Multipurpose Internet Mail Extensions
`
`June 1992
`
`The encoding mechanisms defined here explicitly encode all data in ASCII. Thus, for
`example, suppose an entity has header fields such as:
`
`Content-Type: text/plain; charset=ISO-8859-1
`Content-transfer-encoding: base64
`
`This should be interpreted to mean that the body is a base64 ASCII encoding of data that
`was originally in ISO-8859-1, and will be in that character set again after decoding.
`
`The following sections will define the two standard encoding mechanisms. The
`definition of new content-transfer-encodings is explicitly discouraged and should only
`occur when absolutely necessary. All content-transfer-encoding namespace except that
`beginning with "X-" is explicitly reserved to the IANA for future use. Private
`agreements about content-transfer-encodings are also explicitly discouraged.
`
`Certain Content-Transfer-Encoding values may only be used on certain Content-Types.
`In particular, it is expressly forbidden to use any encodings other than "7bit", "8bit",
`or "binary" with any Content-Type that recursively includes other Content-Type
`fields, notably the "multipart" and "message" Content-Types. All encodings that
`are desired for bodies of type multipart or message must be done at the innermost level,
`by encoding the actual body that needs to be encoded.
`
`NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using
`content-transfer-encodings on data of type multipart or message may seem overly
`restrictive, it is necessary to prevent nested encodings, in which data are passed through
`an encoding algorithm multiple times, and must be decoded multiple times in order to be
`properly viewed. Nested encodings add considerable complexity to user agents: aside
`from the obvious efficiency problems with such multiple encodings, they can obscure the
`basic structure of a message.
`In particular,
`they can imply that several decoding
`operations are necessary simply to find out what types of objects a message contains.
`Banning nested encodings may complicate the job of certain mail gateways, but this
`seems less of a problem than the effect of nested encodings on user agents.
`
`NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
`TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding could be
`inferred from the characteristics of the Content-Type that is to be encoded, or, at the very
`least, that certain Content-Transfer-Encodings could be mandated for use with specific
`Content-Types. There are several reasons why this is not the case. First, given the
`varying types of transports used for mail, some encodings may be appropriate for some
`Content-Type/transport combinations and not for others. (For example, in an 8-bit
`transport, no encoding would be required for text in certain character sets, while such
`encodings are clearly required for 7-bit SMTP.) Second, certain Content-Types may
`require different types of tran