summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1341.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1341.txt')
-rw-r--r--doc/rfc/rfc1341.txt5265
1 files changed, 5265 insertions, 0 deletions
diff --git a/doc/rfc/rfc1341.txt b/doc/rfc/rfc1341.txt
new file mode 100644
index 0000000..1be6f7d
--- /dev/null
+++ b/doc/rfc/rfc1341.txt
@@ -0,0 +1,5265 @@
+
+
+
+
+
+
+ Network Working Group N. Borenstein, Bellcore
+ Request for Comments: 1341 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]
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+ Borenstein & Freed [Page 1]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ This document describes several mechanisms that combine to
+ solve most of these problems without introducing any serious
+ incompatibilities with the existing world of RFC 822 mail.
+ In particular, it describes:
+
+ 1. A MIME-Version header field, which uses a version number
+ to declare a message to be conformant with this
+ specification and allows mail processing agents to
+ distinguish between such messages and those generated
+ by older or non-conformant software, which is presumed
+ to lack such a field.
+
+ 2. A Content-Type header field, generalized from RFC 1049
+ [RFC-1049], which can be used to specify the type and
+ subtype of data in the body of a message and to fully
+ specify the native representation (encoding) of such
+ data.
+
+ 2.a. A "text" Content-Type value, which can be used to
+ represent textual information in a number of
+ character sets and formatted text description
+ languages in a standardized manner.
+
+ 2.b. A "multipart" Content-Type value, which can be
+ used to combine several body parts, possibly of
+ differing types of data, into a single message.
+
+ 2.c. An "application" Content-Type value, which can be
+ used to transmit application data or binary data,
+ and hence, among other uses, to implement an
+ electronic mail file transfer service.
+
+ 2.d. A "message" Content-Type value, for encapsulating
+ a mail message.
+
+ 2.e An "image" Content-Type value, for transmitting
+ still image (picture) data.
+
+ 2.f. An "audio" Content-Type value, for transmitting
+ audio or voice data.
+
+ 2.g. A "video" Content-Type value, for transmitting
+ video or moving image data, possibly with audio as
+ part of the composite video data format.
+
+ 3. A Content-Transfer-Encoding header field, which can be
+ used to specify an auxiliary encoding that was applied
+ to the data in order to allow it to pass through mail
+ transport mechanisms which may have data or character
+ set limitations.
+
+ 4. Two optional header fields that can be used to further
+ describe the data in a message body, the Content-ID and
+ Content-Description header fields.
+
+
+
+ Borenstein & Freed [Page 2]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ MIME has been carefully designed as an extensible mechanism,
+ and it is expected that the set of content-type/subtype
+ pairs and their associated parameters will grow
+ significantly with time. Several other MIME fields, notably
+ including character set names, are likely to have new values
+ defined over time. In order to ensure that the set of such
+ values is developed in an orderly, well-specified, and
+ public manner, MIME defines a registration process which
+ uses the Internet Assigned Numbers Authority (IANA) as a
+ central registry for such values. Appendix F provides
+ details about how IANA registration is accomplished.
+
+ Finally, to specify and promote interoperability, Appendix A
+ of this document provides a basic applicability statement
+ for a subset of the above mechanisms that defines a minimal
+ level of "conformance" with this document.
+
+ HISTORICAL NOTE: 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
+
+
+
+ Borenstein & Freed [Page 3]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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.
+
+ 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.
+
+
+
+ Borenstein & Freed [Page 4]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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:
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 5]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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 "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
+
+
+
+ Borenstein & Freed [Page 6]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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" / "audio"
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / 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.
+
+ 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
+
+
+
+ Borenstein & Freed [Page 7]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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 -- 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
+ 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 8]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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.
+ 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.
+
+ RATIONALE: In the absence of any Content-Type header field
+ or MIME-Version 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.
+
+
+
+ Borenstein & Freed [Page 9]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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.
+
+ 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.
+
+ Unlike Content-Types, a proliferation of Content-Transfer-
+ Encoding values is 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,
+
+
+
+ Borenstein & Freed [Page 10]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ "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 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,
+
+
+
+ Borenstein & Freed [Page 11]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 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.
+
+ 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
+
+
+
+ Borenstein & Freed [Page 12]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ "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 transfer encoding under different circumstances.
+ For example, many PostScript bodies might consist entirely
+ of short lines of 7-bit data and hence require little or no
+ encoding. Other PostScript bodies (especially those using
+ Level 2 PostScript's binary encoding mechanism) may only be
+ reasonably represented using a binary transport encoding.
+ Finally, since Content-Type is intended to be an open-ended
+ specification mechanism, strict specification of an
+ association between Content-Types and encodings effectively
+ couples the specification of an application protocol with a
+ specific lower-level transport. This is not desirable since
+ the developers of a Content-Type should not have to be aware
+ of all the transports in use and what their limitations are.
+
+ NOTE ON TRANSLATING ENCODINGS: The quoted-printable and
+ base64 encodings are designed so that conversion between
+ them is possible. The only issue that arises in such a
+ conversion is the handling of line breaks. When converting
+ from quoted-printable to base64 a line break must be
+ converted into a CRLF sequence. Similarly, a CRLF sequence
+
+
+
+ Borenstein & Freed [Page 13]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ in base64 data should be converted to a quoted-printable
+ line break, but ONLY when converting text data.
+
+ NOTE ON CANONICAL ENCODING MODEL: There was some
+ confusion, in earlier drafts of this memo, regarding the
+ model for when email data was to be converted to canonical
+ form and encoded, and in particular how this process would
+ affect the treatment of CRLFs, given that the representation
+ of newlines varies greatly from system to system. For this
+ reason, a canonical model for encoding is presented as
+ Appendix H.
+
+ 5.1 Quoted-Printable Content-Transfer-Encoding
+
+ The Quoted-Printable encoding is intended to represent data
+ that largely consists of octets that correspond to printable
+ characters in the ASCII character set. It encodes the data
+ in such a way that the resulting octets are unlikely to be
+ modified by mail transport. If the data being encoded are
+ mostly ASCII text, the encoded form of the data remains
+ largely recognizable by humans. A body which is entirely
+ ASCII may also be encoded in Quoted-Printable to ensure the
+ integrity of the data should the message pass through a
+ character-translating, and/or line-wrapping gateway.
+
+ In this encoding, octets are to be represented as determined
+ by the following rules:
+
+ Rule #1: (General 8-bit representation) Any octet,
+ except those indicating a line break according to the
+ newline convention of the canonical form of the data
+ being encoded, may be represented by an "=" followed by
+ a two digit hexadecimal representation of the octet's
+ value. The digits of the hexadecimal alphabet, for this
+ purpose, are "0123456789ABCDEF". Uppercase letters must
+ be
+ used when sending hexadecimal data, though a robust
+ implementation may choose to recognize lowercase
+ letters on receipt. Thus, for example, the value 12
+ (ASCII form feed) can be represented by "=0C", and the
+ value 61 (ASCII EQUAL SIGN) can be represented by
+ "=3D". Except when the following rules allow an
+ alternative encoding, this rule is mandatory.
+
+ Rule #2: (Literal representation) Octets with decimal
+ values of 33 through 60 inclusive, and 62 through 126,
+ inclusive, MAY be represented as the ASCII characters
+ which correspond to those octets (EXCLAMATION POINT
+ through LESS THAN, and GREATER THAN through TILDE,
+ respectively).
+
+ Rule #3: (White Space): Octets with values of 9 and 32
+ MAY be represented as ASCII TAB (HT) and SPACE
+ characters, respectively, but MUST NOT be so
+
+
+
+ Borenstein & Freed [Page 14]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ represented at the end of an encoded line. Any TAB (HT)
+ or SPACE characters on an encoded line MUST thus be
+ followed on that line by a printable character. In
+ particular, an "=" at the end of an encoded line,
+ indicating a soft line break (see rule #5) may follow
+ one or more TAB (HT) or SPACE characters. It follows
+ that an octet with value 9 or 32 appearing at the end
+ of an encoded line must be represented according to
+ Rule #1. This rule is necessary because some MTAs
+ (Message Transport Agents, programs which transport
+ messages from one user to another, or perform a part of
+ such transfers) are known to pad lines of text with
+ SPACEs, and others are known to remove "white space"
+ characters from the end of a line. Therefore, when
+ decoding a Quoted-Printable body, any trailing white
+ space on a line must be deleted, as it will necessarily
+ have been added by intermediate transport agents.
+
+ Rule #4 (Line Breaks): A line break in a text body
+ part, independent of what its representation is
+ following the canonical representation of the data
+ being encoded, must be represented by a (RFC 822) line
+ break, which is a CRLF sequence, in the Quoted-
+ Printable encoding. If isolated CRs and LFs, or LF CR
+ and CR LF sequences are allowed to appear in binary
+ data according to the canonical form, they must be
+ represented using the "=0D", "=0A", "=0A=0D" and
+ "=0D=0A" notations respectively.
+
+ Note that many implementation may elect to encode the
+ local representation of various content types directly.
+ In particular, this may apply to plain text material on
+ systems that use newline conventions other than CRLF
+ delimiters. Such an implementation is permissible, but
+ the generation of line breaks must be generalized to
+ account for the case where alternate representations of
+ newline sequences are used.
+
+ Rule #5 (Soft Line Breaks): The Quoted-Printable
+ encoding REQUIRES that encoded lines be no more than 76
+ characters long. If longer lines are to be encoded with
+ the Quoted-Printable encoding, 'soft' line breaks must
+ be used. An equal sign as the last character on a
+ encoded line indicates such a non-significant ('soft')
+ line break in the encoded text. Thus if the "raw" form
+ of the line is a single unencoded line that says:
+
+ Now's the time for all folk to come to the aid of
+ their country.
+
+ This can be represented, in the Quoted-Printable
+ encoding, as
+
+
+
+
+
+ Borenstein & Freed [Page 15]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Now's the time =
+ for all folk to come=
+ to the aid of their country.
+
+ This provides a mechanism with which long lines are
+ encoded in such a way as to be restored by the user
+ agent. The 76 character limit does not count the
+ trailing CRLF, but counts all other characters,
+ including any equal signs.
+
+ Since the hyphen character ("-") is represented as itself in
+ the Quoted-Printable encoding, care must be taken, when
+ encapsulating a quoted-printable encoded body in a multipart
+ entity, to ensure that the encapsulation boundary does not
+ appear anywhere in the encoded body. (A good strategy is to
+ choose a boundary that includes a character sequence such as
+ "=_" which can never appear in a quoted-printable body. See
+ the definition of multipart messages later in this
+ document.)
+
+ NOTE: The quoted-printable encoding represents something of
+ a compromise between readability and reliability in
+ transport. Bodies encoded with the quoted-printable
+ encoding will work reliably over most mail gateways, but may
+ not work perfectly over a few gateways, notably those
+ involving translation into EBCDIC. (In theory, an EBCDIC
+ gateway could decode a quoted-printable body and re-encode
+ it using base64, but such gateways do not yet exist.) A
+ higher level of confidence is offered by the base64
+ Content-Transfer-Encoding. A way to get reasonably reliable
+ transport through EBCDIC gateways is to also quote the ASCII
+ characters
+
+ !"#$@[\]^`{|}~
+
+ according to rule #1. See Appendix B for more information.
+
+ Because quoted-printable data is generally assumed to be
+ line-oriented, it is to be expected that the breaks between
+ the lines of quoted printable data may be altered in
+ transport, in the same manner that plain text mail has
+ always been altered in Internet mail when passing between
+ systems with differing newline conventions. If such
+ alterations are likely to constitute a corruption of the
+ data, it is probably more sensible to use the base64
+ encoding rather than the quoted-printable encoding.
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 16]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 5.2 Base64 Content-Transfer-Encoding
+
+ The Base64 Content-Transfer-Encoding is designed to
+ represent arbitrary sequences of octets in a form that is
+ not humanly readable. The encoding and decoding algorithms
+ are simple, but the encoded data are consistently only about
+ 33 percent larger than the unencoded data. This encoding is
+ based on the one used in Privacy Enhanced Mail applications,
+ as defined in RFC 1113. The base64 encoding is adapted
+ from RFC 1113, with one change: base64 eliminates the "*"
+ mechanism for embedded clear text.
+
+ A 65-character subset of US-ASCII is used, enabling 6 bits
+ to be represented per printable character. (The extra 65th
+ character, "=", is used to signify a special processing
+ function.)
+
+ NOTE: This subset has the important property that it is
+ represented identically in all versions of ISO 646,
+ including US ASCII, and all characters in the subset are
+ also represented identically in all versions of EBCDIC.
+ Other popular encodings, such as the encoding used by the
+ UUENCODE utility and the base85 encoding specified as part
+ of Level 2 PostScript, do not share these properties, and
+ thus do not fulfill the portability requirements a binary
+ transport encoding for mail must meet.
+
+ The encoding process represents 24-bit groups of input bits
+ as output strings of 4 encoded characters. Proceeding from
+ left to right, a 24-bit input group is formed by
+ concatenating 3 8-bit input groups. These 24 bits are then
+ treated as 4 concatenated 6-bit groups, each of which is
+ translated into a single digit in the base64 alphabet. When
+ encoding a bit stream via the base64 encoding, the bit
+ stream must be presumed to be ordered with the most-
+ significant-bit first. That is, the first bit in the stream
+ will be the high-order bit in the first byte, and the eighth
+ bit will be the low-order bit in the first byte, and so on.
+
+ Each 6-bit group is used as an index into an array of 64
+ printable characters. The character referenced by the index
+ is placed in the output string. These characters, identified
+ in Table 1, below, are selected so as to be universally
+ representable, and the set excludes characters with
+ particular significance to SMTP (e.g., ".", "CR", "LF") and
+ to the encapsulation boundaries defined in this document
+ (e.g., "-").
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 17]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Table 1: The Base64 Alphabet
+
+ Value Encoding Value Encoding Value Encoding Value
+ Encoding
+ 0 A 17 R 34 i 51 z
+ 1 B 18 S 35 j 52 0
+ 2 C 19 T 36 k 53 1
+ 3 D 20 U 37 l 54 2
+ 4 E 21 V 38 m 55 3
+ 5 F 22 W 39 n 56 4
+ 6 G 23 X 40 o 57 5
+ 7 H 24 Y 41 p 58 6
+ 8 I 25 Z 42 q 59 7
+ 9 J 26 a 43 r 60 8
+ 10 K 27 b 44 s 61 9
+ 11 L 28 c 45 t 62 +
+ 12 M 29 d 46 u 63 /
+ 13 N 30 e 47 v
+ 14 O 31 f 48 w (pad) =
+ 15 P 32 g 49 x
+ 16 Q 33 h 50 y
+
+ The output stream (encoded bytes) must be represented in
+ lines of no more than 76 characters each. All line breaks
+ or other characters not found in Table 1 must be ignored by
+ decoding software. In base64 data, characters other than
+ those in Table 1, line breaks, and other white space
+ probably indicate a transmission error, about which a
+ warning message or even a message rejection might be
+ appropriate under some circumstances.
+
+ Special processing is performed if fewer than 24 bits are
+ available at the end of the data being encoded. A full
+ encoding quantum is always completed at the end of a body.
+ When fewer than 24 input bits are available in an input
+ group, zero bits are added (on the right) to form an
+ integral number of 6-bit groups. Output character positions
+ which are not required to represent actual input data are
+ set to the character "=". Since all base64 input is an
+ integral number of octets, only the following cases can
+ arise: (1) the final quantum of encoding input is an
+ integral multiple of 24 bits; here, the final unit of
+ encoded output will be an integral multiple of 4 characters
+ with no "=" padding, (2) the final quantum of encoding input
+ is exactly 8 bits; here, the final unit of encoded output
+ will be two characters followed by two "=" padding
+ characters, or (3) the final quantum of encoding input is
+ exactly 16 bits; here, the final unit of encoded output will
+ be three characters followed by one "=" padding character.
+
+ Care must be taken to use the proper octets for line breaks
+ if base64 encoding is applied directly to text material that
+ has not been converted to canonical form. In particular,
+ text line breaks should be converted into CRLF sequences
+
+
+
+ Borenstein & Freed [Page 18]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ prior to base64 encoding. The important thing to note is
+ that this may be done directly by the encoder rather than in
+ a prior canonicalization step in some implementations.
+
+ NOTE: There is no need to worry about quoting apparent
+ encapsulation boundaries within base64-encoded parts of
+ multipart entities because no hyphen characters are used in
+ the base64 encoding.
+
+ 6 Additional Optional Content- Header Fields
+
+ 6.1 Optional Content-ID Header Field
+
+ In constructing a high-level user agent, it may be desirable
+ to allow one body to make reference to another.
+ Accordingly, bodies may be labeled using the "Content-ID"
+ header field, which is syntactically identical to the
+ "Message-ID" header field:
+
+ Content-ID := msg-id
+
+ Like the Message-ID values, Content-ID values must be
+ generated to be as unique as possible.
+
+ 6.2 Optional Content-Description Header Field
+
+ The ability to associate some descriptive information with a
+ given body is often desirable. For example, it may be useful
+ to mark an "image" body as "a picture of the Space Shuttle
+ Endeavor." Such text may be placed in the Content-
+ Description header field.
+
+ Content-Description := *text
+
+ The description is presumed to be given in the US-ASCII
+ character set, although the mechanism specified in [RFC-
+ 1342] may be used for non-US-ASCII Content-Description
+ values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 19]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7 The Predefined Content-Type Values
+
+ This document defines seven initial Content-Type values and
+ an extension mechanism for private or experimental types.
+ Further standard types must be defined by new published
+ specifications. It is expected that most innovation in new
+ types of mail will take place as subtypes of the seven types
+ defined here. The most essential characteristics of the
+ seven content-types are summarized in Appendix G.
+
+ 7.1 The Text Content-Type
+
+ The text Content-Type is intended for sending material which
+ is principally textual in form. It is the default Content-
+ Type. A "charset" parameter may be used to indicate the
+ character set of the body text. The primary subtype of text
+ is "plain". This indicates plain (unformatted) text. The
+ default Content-Type for Internet mail is "text/plain;
+ charset=us-ascii".
+
+ Beyond plain text, there are many formats for representing
+ what might be known as "extended text" -- text with embedded
+ formatting and presentation information. An interesting
+ characteristic of many such representations is that they are
+ to some extent readable even without the software that
+ interprets them. It is useful, then, to distinguish them,
+ at the highest level, from such unreadable data as images,
+ audio, or text represented in an unreadable form. In the
+ absence of appropriate interpretation software, it is
+ reasonable to show subtypes of text to the user, while it is
+ not reasonable to do so with most nontextual data.
+
+ Such formatted textual data should be represented using
+ subtypes of text. Plausible subtypes of text are typically
+ given by the common name of the representation format, e.g.,
+ "text/richtext".
+
+ 7.1.1 The charset parameter
+
+ A critical parameter that may be specified in the Content-
+ Type field for text data is the character set. This is
+ specified with a "charset" parameter, as in:
+
+ Content-type: text/plain; charset=us-ascii
+
+ Unlike some other parameter values, the values of the
+ charset parameter are NOT case sensitive. The default
+ character set, which must be assumed in the absence of a
+ charset parameter, is US-ASCII.
+
+ An initial list of predefined character set names can be
+ found at the end of this section. Additional character sets
+ may be registered with IANA as described in Appendix F,
+ although the standardization of their use requires the usual
+
+
+
+ Borenstein & Freed [Page 20]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ IAB review and approval. Note that if the specified
+ character set includes 8-bit data, a Content-Transfer-
+ Encoding header field and a corresponding encoding on the
+ data are required in order to transmit the body via some
+ mail transfer protocols, such as SMTP.
+
+ The default character set, US-ASCII, has been the subject of
+ some confusion and ambiguity in the past. Not only were
+ there some ambiguities in the definition, there have been
+ wide variations in practice. In order to eliminate such
+ ambiguity and variations in the future, it is strongly
+ recommended that new user agents explicitly specify a
+ character set via the Content-Type header field. "US-ASCII"
+ does not indicate an arbitrary seven-bit character code, but
+ specifies that the body uses character coding that uses the
+ exact correspondence of codes to characters specified in
+ ASCII. National use variations of ISO 646 [ISO-646] are NOT
+ ASCII and their use in Internet mail is explicitly
+ discouraged. The omission of the ISO 646 character set is
+ deliberate in this regard. The character set name of "US-
+ ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
+ The character set name "ASCII" is reserved and must not be
+ used for any purpose.
+
+ NOTE: RFC 821 explicitly specifies "ASCII", and references
+ an earlier version of the American Standard. Insofar as one
+ of the purposes of specifying a Content-Type and character
+ set is to permit the receiver to unambiguously determine how
+ the sender intended the coded message to be interpreted,
+ assuming anything other than "strict ASCII" as the default
+ would risk unintentional and incompatible changes to the
+ semantics of messages now being transmitted. This also
+ implies that messages containing characters coded according
+ to national variations on ISO 646, or using code-switching
+ procedures (e.g., those of ISO 2022), as well as 8-bit or
+ multiple octet character encodings MUST use an appropriate
+ character set specification to be consistent with this
+ specification.
+
+ The complete US-ASCII character set is listed in [US-ASCII].
+ Note that the control characters including DEL (0-31, 127)
+ have no defined meaning apart from the combination CRLF
+ (ASCII values 13 and 10) indicating a new line. Two of the
+ characters have de facto meanings in wide use: FF (12) often
+ means "start subsequent text on the beginning of a new
+ page"; and TAB or HT (9) often (though not always) means
+ "move the cursor to the next available column after the
+ current position where the column number is a multiple of 8
+ (counting the first column as column 0)." Apart from this,
+ any use of the control characters or DEL in a body must be
+ part of a private agreement between the sender and
+ recipient. Such private agreements are discouraged and
+ should be replaced by the other capabilities of this
+ document.
+
+
+
+ Borenstein & Freed [Page 21]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ NOTE: Beyond US-ASCII, an enormous proliferation of
+ character sets is possible. It is the opinion of the IETF
+ working group that a large number of character sets is NOT a
+ good thing. We would prefer to specify a single character
+ set that can be used universally for representing all of the
+ world's languages in electronic mail. Unfortunately,
+ existing practice in several communities seems to point to
+ the continued use of multiple character sets in the near
+ future. For this reason, we define names for a small number
+ of character sets for which a strong constituent base
+ exists. It is our hope that ISO 10646 or some other
+ effort will eventually define a single world character set
+ which can then be specified for use in Internet mail, but in
+ the advance of that definition we cannot specify the use of
+ ISO 10646, Unicode, or any other character set whose
+ definition is, as of this writing, incomplete.
+
+ The defined charset values are:
+
+ US-ASCII -- as defined in [US-ASCII].
+
+ ISO-8859-X -- where "X" is to be replaced, as
+ necessary, for the parts of ISO-8859 [ISO-
+ 8859]. Note that the ISO 646 character sets
+ have deliberately been omitted in favor of
+ their 8859 replacements, which are the
+ designated character sets for Internet mail.
+ As of the publication of this document, the
+ legitimate values for "X" are the digits 1
+ through 9.
+
+ Note that the character set used, if anything other than
+ US-ASCII, must always be explicitly specified in the
+ Content-Type field.
+
+ No other character set name may be used in Internet mail
+ without the publication of a formal specification and its
+ registration with IANA as described in Appendix F, or by
+ private agreement, in which case the character set name must
+ begin with "X-".
+
+ Implementors are discouraged from defining new character
+ sets for mail use unless absolutely necessary.
+
+ The "charset" parameter has been defined primarily for the
+ purpose of textual data, and is described in this section
+ for that reason. However, it is conceivable that non-
+ textual data might also wish to specify a charset value for
+ some purpose, in which case the same syntax and values
+ should be used.
+
+ In general, mail-sending software should always use the
+ "lowest common denominator" character set possible. For
+ example, if a body contains only US-ASCII characters, it
+
+
+
+ Borenstein & Freed [Page 22]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ should be marked as being in the US-ASCII character set, not
+ ISO-8859-1, which, like all the ISO-8859 family of character
+ sets, is a superset of US-ASCII. More generally, if a
+ widely-used character set is a subset of another character
+ set, and a body contains only characters in the widely-used
+ subset, it should be labeled as being in that subset. This
+ will increase the chances that the recipient will be able to
+ view the mail correctly.
+
+ 7.1.2 The Text/plain subtype
+
+ The primary subtype of text is "plain". This indicates
+ plain (unformatted) text. The default Content-Type for
+ Internet mail, "text/plain; charset=us-ascii", describes
+ existing Internet practice, that is, it is the type of body
+ defined by RFC 822.
+
+ 7.1.3 The Text/richtext subtype
+
+ In order to promote the wider interoperability of simple
+ formatted text, this document defines an extremely simple
+ subtype of "text", the "richtext" subtype. This subtype was
+ designed to meet the following criteria:
+
+ 1. The syntax must be extremely simple to parse,
+ so that even teletype-oriented mail systems can
+ easily strip away the formatting information and
+ leave only the readable text.
+
+ 2. The syntax must be extensible to allow for new
+ formatting commands that are deemed essential.
+
+ 3. The capabilities must be extremely limited, to
+ ensure that it can represent no more than is
+ likely to be representable by the user's primary
+ word processor. While this limits what can be
+ sent, it increases the likelihood that what is
+ sent can be properly displayed.
+
+ 4. The syntax must be compatible with SGML, so
+ that, with an appropriate DTD (Document Type
+ Definition, the standard mechanism for defining a
+ document type using SGML), a general SGML parser
+ could be made to parse richtext. However, despite
+ this compatibility, the syntax should be far
+ simpler than full SGML, so that no SGML knowledge
+ is required in order to implement it.
+
+ The syntax of "richtext" is very simple. It is assumed, at
+ the top-level, to be in the US-ASCII character set, unless
+ of course a different charset parameter was specified in the
+ Content-type field. All characters represent themselves,
+ with the exception of the "<" character (ASCII 60), which is
+ used to mark the beginning of a formatting command.
+
+
+
+ Borenstein & Freed [Page 23]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Formatting instructions consist of formatting commands
+ surrounded by angle brackets ("<>", ASCII 60 and 62). Each
+ formatting command may be no more than 40 characters in
+ length, all in US-ASCII, restricted to the alphanumeric and
+ hyphen ("-") characters. Formatting commands may be preceded
+ by a forward slash or solidus ("/", ASCII 47), making them
+ negations, and such negations must always exist to balance
+ the initial opening commands, except as noted below. Thus,
+ if the formatting command "<bold>" appears at some point,
+ there must later be a "</bold>" to balance it. There are
+ only three exceptions to this "balancing" rule: First, the
+ command "<lt>" is used to represent a literal "<" character.
+ Second, the command "<nl>" is used to represent a required
+ line break. (Otherwise, CRLFs in the data are treated as
+ equivalent to a single SPACE character.) Finally, the
+ command "<np>" is used to represent a page break. (NOTE:
+ The 40 character limit on formatting commands does not
+ include the "<", ">", or "/" characters that might be
+ attached to such commands.)
+
+ Initially defined formatting commands, not all of which will
+ be implemented by all richtext implementations, include:
+
+ Bold -- causes the subsequent text to be in a bold
+ font.
+ Italic -- causes the subsequent text to be in an italic
+ font.
+ Fixed -- causes the subsequent text to be in a fixed
+ width font.
+ Smaller -- causes the subsequent text to be in a
+ smaller font.
+ Bigger -- causes the subsequent text to be in a bigger
+ font.
+ Underline -- causes the subsequent text to be
+ underlined.
+ Center -- causes the subsequent text to be centered.
+ FlushLeft -- causes the subsequent text to be left
+ justified.
+ FlushRight -- causes the subsequent text to be right
+ justified.
+ Indent -- causes the subsequent text to be indented at
+ the left margin.
+ IndentRight -- causes the subsequent text to be
+ indented at the right margin.
+ Outdent -- causes the subsequent text to be outdented
+ at the left margin.
+ OutdentRight -- causes the subsequent text to be
+ outdented at the right margin.
+ SamePage -- causes the subsequent text to be grouped,
+ if possible, on one page.
+ Subscript -- causes the subsequent text to be
+ interpreted as a subscript.
+
+
+
+
+
+ Borenstein & Freed [Page 24]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Superscript -- causes the subsequent text to be
+ interpreted as a superscript.
+ Heading -- causes the subsequent text to be interpreted
+ as a page heading.
+ Footing -- causes the subsequent text to be interpreted
+ as a page footing.
+ ISO-8859-X (for any value of X that is legal as a
+ "charset" parameter) -- causes the subsequent text
+ to be interpreted as text in the appropriate
+ character set.
+ US-ASCII -- causes the subsequent text to be
+ interpreted as text in the US-ASCII character set.
+ Excerpt -- causes the subsequent text to be interpreted
+ as a textual excerpt from another source.
+ Typically this will be displayed using indentation
+ and an alternate font, but such decisions are up
+ to the viewer.
+ Paragraph -- causes the subsequent text to be
+ interpreted as a single paragraph, with
+ appropriate paragraph breaks (typically blank
+ space) before and after.
+ Signature -- causes the subsequent text to be
+ interpreted as a "signature". Some systems may
+ wish to display signatures in a smaller font or
+ otherwise set them apart from the main text of the
+ message.
+ Comment -- causes the subsequent text to be interpreted
+ as a comment, and hence not shown to the reader.
+ No-op -- has no effect on the subsequent text.
+ lt -- <lt> is replaced by a literal "<" character. No
+ balancing </lt> is allowed.
+ nl -- <nl> causes a line break. No balancing </nl> is
+ allowed.
+ np -- <np> causes a page break. No balancing </np> is
+ allowed.
+
+ Each positive formatting command affects all subsequent text
+ until the matching negative formatting command. Such pairs
+ of formatting commands must be properly balanced and nested.
+ Thus, a proper way to describe text in bold italics is:
+
+ <bold><italic>the-text</italic></bold>
+
+ or, alternately,
+
+ <italic><bold>the-text</bold></italic>
+
+ but, in particular, the following is illegal
+ richtext:
+
+ <bold><italic>the-text</bold></italic>
+
+ NOTE: The nesting requirement for formatting commands
+ imposes a slightly higher burden upon the composers of
+
+
+
+ Borenstein & Freed [Page 25]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ richtext bodies, but potentially simplifies richtext
+ displayers by allowing them to be stack-based. The main
+ goal of richtext is to be simple enough to make multifont,
+ formatted email widely readable, so that those with the
+ capability of sending it will be able to do so with
+ confidence. Thus slightly increased complexity in the
+ composing software was deemed a reasonable tradeoff for
+ simplified reading software. Nonetheless, implementors of
+ richtext readers are encouraged to follow the general
+ Internet guidelines of being conservative in what you send
+ and liberal in what you accept. Those implementations that
+ can do so are encouraged to deal reasonably with improperly
+ nested richtext.
+
+ Implementations must regard any unrecognized formatting
+ command as equivalent to "No-op", thus facilitating future
+ extensions to "richtext". Private extensions may be defined
+ using formatting commands that begin with "X-", by analogy
+ to Internet mail header field names.
+
+ It is worth noting that no special behavior is required for
+ the TAB (HT) character. It is recommended, however, that, at
+ least when fixed-width fonts are in use, the common
+ semantics of the TAB (HT) character should be observed,
+ namely that it moves to the next column position that is a
+ multiple of 8. (In other words, if a TAB (HT) occurs in
+ column n, where the leftmost column is column 0, then that
+ TAB (HT) should be replaced by 8-(n mod 8) SPACE
+ characters.)
+
+ Richtext also differentiates between "hard" and "soft" line
+ breaks. A line break (CRLF) in the richtext data stream is
+ interpreted as a "soft" line break, one that is included
+ only for purposes of mail transport, and is to be treated as
+ white space by richtext interpreters. To include a "hard"
+ line break (one that must be displayed as such), the "<nl>"
+ or "<paragraph> formatting constructs should be used. In
+ general, a soft line break should be treated as white space,
+ but when soft line breaks immediately follow a <nl> or a
+ </paragraph> tag they should be ignored rather than treated
+ as white space.
+
+ Putting all this together, the following "text/richtext"
+ body fragment:
+
+ <bold>Now</bold> is the time for
+ <italic>all</italic> good men
+ <smaller>(and <lt>women>)</smaller> to
+ <ignoreme></ignoreme> come
+
+ to the aid of their
+ <nl>
+
+
+
+
+
+ Borenstein & Freed [Page 26]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ beloved <nl><nl>country. <comment> Stupid
+ quote! </comment> -- the end
+
+ represents the following formatted text (which will, no
+ doubt, look cryptic in the text-only version of this
+ document):
+
+ Now is the time for all good men (and <women>) to
+ come to the aid of their
+ beloved
+
+ country. -- the end
+
+ Richtext conformance: A minimal richtext implementation is
+ one that simply converts "<lt>" to "<", converts CRLFs to
+ SPACE, converts <nl> to a newline according to local newline
+ convention, removes everything between a <comment> command
+ and the next balancing </comment> command, and removes all
+ other formatting commands (all text enclosed in angle
+ brackets).
+
+ NOTE ON THE RELATIONSHIP OF RICHTEXT TO SGML: Richtext is
+ decidedly not SGML, and must not be used to transport
+ arbitrary SGML documents. Those who wish to use SGML
+ document types as a mail transport format must define a new
+ text or application subtype, e.g., "text/sgml-dtd-whatever"
+ or "application/sgml-dtd-whatever", depending on the
+ perceived readability of the DTD in use. Richtext is
+ designed to be compatible with SGML, and specifically so
+ that it will be possible to define a richtext DTD if one is
+ needed. However, this does not imply that arbitrary SGML
+ can be called richtext, nor that richtext implementors have
+ any need to understand SGML; the description in this
+ document is a complete definition of richtext, which is far
+ simpler than complete SGML.
+
+ NOTE ON THE INTENDED USE OF RICHTEXT: It is recognized that
+ implementors of future mail systems will want rich text
+ functionality far beyond that currently defined for
+ richtext. The intent of richtext is to provide a common
+ format for expressing that functionality in a form in which
+ much of it, at least, will be understood by interoperating
+ software. Thus, in particular, software with a richer
+ notion of formatted text than richtext can still use
+ richtext as its basic representation, but can extend it with
+ new formatting commands and by hiding information specific
+ to that software system in richtext comments. As such
+ systems evolve, it is expected that the definition of
+ richtext will be further refined by future published
+ specifications, but richtext as defined here provides a
+ platform on which evolutionary refinements can be based.
+
+ IMPLEMENTATION NOTE: In some environments, it might be
+ impossible to combine certain richtext formatting commands,
+
+
+
+ Borenstein & Freed [Page 27]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ whereas in others they might be combined easily. For
+ example, the combination of <bold> and <italic> might
+ produce bold italics on systems that support such fonts, but
+ there exist systems that can make text bold or italicized,
+ but not both. In such cases, the most recently issued
+ recognized formatting command should be preferred.
+
+ One of the major goals in the design of richtext was to make
+ it so simple that even text-only mailers will implement
+ richtext-to-plain-text translators, thus increasing the
+ likelihood that multifont text will become "safe" to use
+ very widely. To demonstrate this simplicity, an extremely
+ simple 35-line C program that converts richtext input into
+ plain text output is included in Appendix D.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 28]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.2 The Multipart Content-Type
+
+ In the case of multiple part messages, in which one or more
+ different sets of data are combined in a single body, a
+ "multipart" Content-Type field must appear in the entity's
+ header. The body must then contain one or more "body parts,"
+ each preceded by an encapsulation boundary, and the last one
+ followed by a closing boundary. Each part starts with an
+ encapsulation boundary, and then contains a body part
+ consisting of header area, a blank line, and a body area.
+ Thus a body part is similar to an RFC 822 message in syntax,
+ but different in meaning.
+
+ A body part is NOT to be interpreted as actually being an
+ RFC 822 message. To begin with, NO header fields are
+ actually required in body parts. A body part that starts
+ with a blank line, therefore, is allowed and is a body part
+ for which all default values are to be assumed. In such a
+ case, the absence of a Content-Type header field implies
+ that the encapsulation is plain US-ASCII text. The only
+ header fields that have defined meaning for body parts are
+ those the names of which begin with "Content-". All other
+ header fields are generally to be ignored in body parts.
+ Although they should generally be retained in mail
+ processing, they may be discarded by gateways if necessary.
+ Such other fields are permitted to appear in body parts but
+ should not be depended on. "X-" fields may be created for
+ experimental or private purposes, with the recognition that
+ the information they contain may be lost at some gateways.
+
+ The distinction between an RFC 822 message and a body part
+ is subtle, but important. A gateway between Internet and
+ X.400 mail, for example, must be able to tell the difference
+ between a body part that contains an image and a body part
+ that contains an encapsulated message, the body of which is
+ an image. In order to represent the latter, the body part
+ must have "Content-Type: message", and its body (after the
+ blank line) must be the encapsulated message, with its own
+ "Content-Type: image" header field. The use of similar
+ syntax facilitates the conversion of messages to body parts,
+ and vice versa, but the distinction between the two must be
+ understood by implementors. (For the special case in which
+ all parts actually are messages, a "digest" subtype is also
+ defined.)
+
+ As stated previously, each body part is preceded by an
+ encapsulation boundary. The encapsulation boundary MUST NOT
+ appear inside any of the encapsulated parts. Thus, it is
+ crucial that the composing agent be able to choose and
+ specify the unique boundary that will separate the parts.
+
+ All present and future subtypes of the "multipart" type must
+ use an identical syntax. Subtypes may differ in their
+ semantics, and may impose additional restrictions on syntax,
+
+
+
+ Borenstein & Freed [Page 29]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ but must conform to the required syntax for the multipart
+ type. This requirement ensures that all conformant user
+ agents will at least be able to recognize and separate the
+ parts of any multipart entity, even of an unrecognized
+ subtype.
+
+ As stated in the definition of the Content-Transfer-Encoding
+ field, no encoding other than "7bit", "8bit", or "binary" is
+ permitted for entities of type "multipart". The multipart
+ delimiters and header fields are always 7-bit ASCII in any
+ case, and data within the body parts can be encoded on a
+ part-by-part basis, with Content-Transfer-Encoding fields
+ for each appropriate body part.
+
+ Mail gateways, relays, and other mail handling agents are
+ commonly known to alter the top-level header of an RFC 822
+ message. In particular, they frequently add, remove, or
+ reorder header fields. Such alterations are explicitly
+ forbidden for the body part headers embedded in the bodies
+ of messages of type "multipart."
+
+ 7.2.1 Multipart: The common syntax
+
+ All subtypes of "multipart" share a common syntax, defined
+ in this section. A simple example of a multipart message
+ also appears in this section. An example of a more complex
+ multipart message is given in Appendix C.
+
+ The Content-Type field for multipart entities requires one
+ parameter, "boundary", which is used to specify the
+ encapsulation boundary. The encapsulation boundary is
+ defined as a line consisting entirely of two hyphen
+ characters ("-", decimal code 45) followed by the boundary
+ parameter value from the Content-Type header field.
+
+ NOTE: The hyphens are for rough compatibility with the
+ earlier RFC 934 method of message encapsulation, and for
+ ease of searching for the boundaries in some
+ implementations. However, it should be noted that multipart
+ messages are NOT completely compatible with RFC 934
+ encapsulations; in particular, they do not obey RFC 934
+ quoting conventions for embedded lines that begin with
+ hyphens. This mechanism was chosen over the RFC 934
+ mechanism because the latter causes lines to grow with each
+ level of quoting. The combination of this growth with the
+ fact that SMTP implementations sometimes wrap long lines
+ made the RFC 934 mechanism unsuitable for use in the event
+ that deeply-nested multipart structuring is ever desired.
+
+ Thus, a typical multipart Content-Type header field might
+ look like this:
+
+ Content-Type: multipart/mixed;
+
+
+
+
+ Borenstein & Freed [Page 30]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ boundary=gc0p4Jq0M2Yt08jU534c0p
+
+ This indicates that the entity consists of several parts,
+ each itself with a structure that is syntactically identical
+ to an RFC 822 message, except that the header area might be
+ completely empty, and that the parts are each preceded by
+ the line
+
+ --gc0p4Jq0M2Yt08jU534c0p
+
+ Note that the encapsulation boundary must occur at the
+ beginning of a line, i.e., following a CRLF, and that that
+ initial CRLF is considered to be part of the encapsulation
+ boundary rather than part of the preceding part. The
+ boundary must be followed immediately either by another CRLF
+ and the header fields for the next part, or by two CRLFs, in
+ which case there are no header fields for the next part (and
+ it is therefore assumed to be of Content-Type text/plain).
+
+ NOTE: The CRLF preceding the encapsulation line is
+ considered part of the boundary so that it is possible to
+ have a part that does not end with a CRLF (line break).
+ Body parts that must be considered to end with line breaks,
+ therefore, should have two CRLFs preceding the encapsulation
+ line, the first of which is part of the preceding body part,
+ and the second of which is part of the encapsulation
+ boundary.
+
+ The requirement that the encapsulation boundary begins with
+ a CRLF implies that the body of a multipart entity must
+ itself begin with a CRLF before the first encapsulation line
+ -- that is, if the "preamble" area is not used, the entity
+ headers must be followed by TWO CRLFs. This is indeed how
+ such entities should be composed. A tolerant mail reading
+ program, however, may interpret a body of type multipart
+ that begins with an encapsulation line NOT initiated by a
+ CRLF as also being an encapsulation boundary, but a
+ compliant mail sending program must not generate such
+ entities.
+
+ Encapsulation boundaries must not appear within the
+ encapsulations, and must be no longer than 70 characters,
+ not counting the two leading hyphens.
+
+ The encapsulation boundary following the last body part is a
+ distinguished delimiter that indicates that no further body
+ parts will follow. Such a delimiter is identical to the
+ previous delimiters, with the addition of two more hyphens
+ at the end of the line:
+
+ --gc0p4Jq0M2Yt08jU534c0p--
+
+ There appears to be room for additional information prior to
+ the first encapsulation boundary and following the final
+
+
+
+ Borenstein & Freed [Page 31]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ boundary. These areas should generally be left blank, and
+ implementations should ignore anything that appears before
+ the first boundary or after the last one.
+
+ NOTE: These "preamble" and "epilogue" areas are not used
+ because of the lack of proper typing of these parts and the
+ lack of clear semantics for handling these areas at
+ gateways, particularly X.400 gateways.
+
+ NOTE: Because encapsulation boundaries must not appear in
+ the body parts being encapsulated, a user agent must
+ exercise care to choose a unique boundary. The boundary in
+ the example above could have been the result of an algorithm
+ designed to produce boundaries with a very low probability
+ of already existing in the data to be encapsulated without
+ having to prescan the data. Alternate algorithms might
+ result in more 'readable' boundaries for a recipient with an
+ old user agent, but would require more attention to the
+ possibility that the boundary might appear in the
+ encapsulated part. The simplest boundary possible is
+ something like "---", with a closing boundary of "-----".
+
+ As a very simple example, the following multipart message
+ has two parts, both of them plain text, one of them
+ explicitly typed and one of them implicitly typed:
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: Sample message
+ MIME-Version: 1.0
+ Content-type: multipart/mixed; boundary="simple
+ boundary"
+
+ This is the preamble. It is to be ignored, though it
+ is a handy place for mail composers to include an
+ explanatory note to non-MIME compliant readers.
+ --simple boundary
+
+ This is implicitly typed plain ASCII text.
+ It does NOT end with a linebreak.
+ --simple boundary
+ Content-type: text/plain; charset=us-ascii
+
+ This is explicitly typed plain ASCII text.
+ It DOES end with a linebreak.
+
+ --simple boundary--
+ This is the epilogue. It is also to be ignored.
+
+ The use of a Content-Type of multipart in a body part within
+ another multipart entity is explicitly allowed. In such
+ cases, for obvious reasons, care must be taken to ensure
+ that each nested multipart entity must use a different
+ boundary delimiter. See Appendix C for an example of nested
+
+
+
+ Borenstein & Freed [Page 32]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ multipart entities.
+
+ The use of the multipart Content-Type with only a single
+ body part may be useful in certain contexts, and is
+ explicitly permitted.
+
+ The only mandatory parameter for the multipart Content-Type
+ is the boundary parameter, which consists of 1 to 70
+ characters from a set of characters known to be very robust
+ through email gateways, and NOT ending with white space.
+ (If a boundary appears to end with white space, the white
+ space must be presumed to have been added by a gateway, and
+ should be deleted.) It is formally specified by the
+ following BNF:
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
+ "_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ Overall, the body of a multipart entity may be specified as
+ follows:
+
+ multipart-body := preamble 1*encapsulation
+ close-delimiter epilogue
+
+ encapsulation := delimiter CRLF body-part
+
+ delimiter := CRLF "--" boundary ; taken from Content-Type
+ field.
+ ; when content-type is
+ multipart
+ ; There must be no space
+ ; between "--" and boundary.
+
+ close-delimiter := delimiter "--" ; Again, no space before
+ "--"
+
+ preamble := *text ; to be ignored upon
+ receipt.
+
+ epilogue := *text ; to be ignored upon
+ receipt.
+
+ body-part = <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere. Note that the
+
+
+
+
+
+ Borenstein & Freed [Page 33]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ semantics of a part differ from the semantics
+ of a message, as described in the text.>
+
+ NOTE: Conspicuously missing from the multipart type is a
+ notion of structured, related body parts. In general, it
+ seems premature to try to standardize interpart structure
+ yet. It is recommended that those wishing to provide a more
+ structured or integrated multipart messaging facility should
+ define a subtype of multipart that is syntactically
+ identical, but that always expects the inclusion of a
+ distinguished part that can be used to specify the structure
+ and integration of the other parts, probably referring to
+ them by their Content-ID field. If this approach is used,
+ other implementations will not recognize the new subtype,
+ but will treat it as the primary subtype (multipart/mixed)
+ and will thus be able to show the user the parts that are
+ recognized.
+
+ 7.2.2 The Multipart/mixed (primary) subtype
+
+ The primary subtype for multipart, "mixed", is intended for
+ use when the body parts are independent and intended to be
+ displayed serially. Any multipart subtypes that an
+ implementation does not recognize should be treated as being
+ of subtype "mixed".
+
+ 7.2.3 The Multipart/alternative subtype
+
+ The multipart/alternative type is syntactically identical to
+ multipart/mixed, but the semantics are different. In
+ particular, each of the parts is an "alternative" version of
+ the same information. User agents should recognize that the
+ content of the various parts are interchangeable. The user
+ agent should either choose the "best" type based on the
+ user's environment and preferences, or offer the user the
+ available alternatives. In general, choosing the best type
+ means displaying only the LAST part that can be displayed.
+ This may be used, for example, to send mail in a fancy text
+ format in such a way that it can easily be displayed
+ anywhere:
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: Formatted text mail
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative; boundary=boundary42
+
+
+ --boundary42
+ Content-Type: text/plain; charset=us-ascii
+
+ ...plain text version of message goes here....
+
+
+
+
+
+ Borenstein & Freed [Page 34]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ --boundary42
+ Content-Type: text/richtext
+
+ .... richtext version of same message goes here ...
+ --boundary42
+ Content-Type: text/x-whatever
+
+ .... fanciest formatted version of same message goes here
+ ...
+ --boundary42--
+
+ In this example, users whose mail system understood the
+ "text/x-whatever" format would see only the fancy version,
+ while other users would see only the richtext or plain text
+ version, depending on the capabilities of their system.
+
+ In general, user agents that compose multipart/alternative
+ entities should place the body parts in increasing order of
+ preference, that is, with the preferred format last. For
+ fancy text, the sending user agent should put the plainest
+ format first and the richest format last. Receiving user
+ agents should pick and display the last format they are
+ capable of displaying. In the case where one of the
+ alternatives is itself of type "multipart" and contains
+ unrecognized sub-parts, the user agent may choose either to
+ show that alternative, an earlier alternative, or both.
+
+ NOTE: From an implementor's perspective, it might seem more
+ sensible to reverse this ordering, and have the plainest
+ alternative last. However, placing the plainest alternative
+ first is the friendliest possible option when
+ mutlipart/alternative entities are viewed using a non-MIME-
+ compliant mail reader. While this approach does impose some
+ burden on compliant mail readers, interoperability with
+ older mail readers was deemed to be more important in this
+ case.
+
+ It may be the case that some user agents, if they can
+ recognize more than one of the formats, will prefer to offer
+ the user the choice of which format to view. This makes
+ sense, for example, if mail includes both a nicely-formatted
+ image version and an easily-edited text version. What is
+ most critical, however, is that the user not automatically
+ be shown multiple versions of the same data. Either the
+ user should be shown the last recognized version or should
+ explicitly be given the choice.
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 35]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.2.4 The Multipart/digest subtype
+
+ This document defines a "digest" subtype of the multipart
+ Content-Type. This type is syntactically identical to
+ multipart/mixed, but the semantics are different. In
+ particular, in a digest, the default Content-Type value for
+ a body part is changed from "text/plain" to
+ "message/rfc822". This is done to allow a more readable
+ digest format that is largely compatible (except for the
+ quoting convention) with RFC 934.
+
+ A digest in this format might, then, look something like
+ this:
+
+ From: Moderator-Address
+ MIME-Version: 1.0
+ Subject: Internet Digest, volume 42
+ Content-Type: multipart/digest;
+ boundary="---- next message ----"
+
+
+ ------ next message ----
+
+ From: someone-else
+ Subject: my opinion
+
+ ...body goes here ...
+
+ ------ next message ----
+
+ From: someone-else-again
+ Subject: my different opinion
+
+ ... another body goes here...
+
+ ------ next message ------
+
+ 7.2.5 The Multipart/parallel subtype
+
+ This document defines a "parallel" subtype of the multipart
+ Content-Type. This type is syntactically identical to
+ multipart/mixed, but the semantics are different. In
+ particular, in a parallel entity, all of the parts are
+ intended to be presented in parallel, i.e., simultaneously,
+ on hardware and software that are capable of doing so.
+ Composing agents should be aware that many mail readers will
+ lack this capability and will show the parts serially in any
+ event.
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 36]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.3 The Message Content-Type
+
+ It is frequently desirable, in sending mail, to encapsulate
+ another mail message. For this common operation, a special
+ Content-Type, "message", is defined. The primary subtype,
+ message/rfc822, has no required parameters in the Content-
+ Type field. Additional subtypes, "partial" and "External-
+ body", do have required parameters. These subtypes are
+ explained below.
+
+ NOTE: It has been suggested that subtypes of message might
+ be defined for forwarded or rejected messages. However,
+ forwarded and rejected messages can be handled as multipart
+ messages in which the first part contains any control or
+ descriptive information, and a second part, of type
+ message/rfc822, is the forwarded or rejected message.
+ Composing rejection and forwarding messages in this manner
+ will preserve the type information on the original message
+ and allow it to be correctly presented to the recipient, and
+ hence is strongly encouraged.
+
+ As stated in the definition of the Content-Transfer-Encoding
+ field, no encoding other than "7bit", "8bit", or "binary" is
+ permitted for messages or parts of type "message". The
+ message header fields are always US-ASCII in any case, and
+ data within the body can still be encoded, in which case the
+ Content-Transfer-Encoding header field in the encapsulated
+ message will reflect this. Non-ASCII text in the headers of
+ an encapsulated message can be specified using the
+ mechanisms described in [RFC-1342].
+
+ Mail gateways, relays, and other mail handling agents are
+ commonly known to alter the top-level header of an RFC 822
+ message. In particular, they frequently add, remove, or
+ reorder header fields. Such alterations are explicitly
+ forbidden for the encapsulated headers embedded in the
+ bodies of messages of type "message."
+
+ 7.3.1 The Message/rfc822 (primary) subtype
+
+ A Content-Type of "message/rfc822" indicates that the body
+ contains an encapsulated message, with the syntax of an RFC
+ 822 message.
+
+ 7.3.2 The Message/Partial subtype
+
+ A subtype of message, "partial", is defined in order to
+ allow large objects to be delivered as several separate
+ pieces of mail and automatically reassembled by the
+ receiving user agent. (The concept is similar to IP
+ fragmentation/reassembly in the basic Internet Protocols.)
+ This mechanism can be used when intermediate transport
+ agents limit the size of individual messages that can be
+ sent. Content-Type "message/partial" thus indicates that
+
+
+
+ Borenstein & Freed [Page 37]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ the body contains a fragment of a larger message.
+
+ Three parameters must be specified in the Content-Type field
+ of type message/partial: The first, "id", is a unique
+ identifier, as close to a world-unique identifier as
+ possible, to be used to match the parts together. (In
+ general, the identifier is essentially a message-id; if
+ placed in double quotes, it can be any message-id, in
+ accordance with the BNF for "parameter" given earlier in
+ this specification.) The second, "number", an integer, is
+ the part number, which indicates where this part fits into
+ the sequence of fragments. The third, "total", another
+ integer, is the total number of parts. This third subfield
+ is required on the final part, and is optional on the
+ earlier parts. Note also that these parameters may be given
+ in any order.
+
+ Thus, part 2 of a 3-part message may have either of the
+ following header fields:
+
+ Content-Type: Message/Partial;
+ number=2; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
+
+ Content-Type: Message/Partial;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
+ number=2
+
+ But part 3 MUST specify the total number of parts:
+
+ Content-Type: Message/Partial;
+ number=3; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
+
+ Note that part numbering begins with 1, not 0.
+
+ When the parts of a message broken up in this manner are put
+ together, the result is a complete RFC 822 format message,
+ which may have its own Content-Type header field, and thus
+ may contain any other data type.
+
+ Message fragmentation and reassembly: The semantics of a
+ reassembled partial message must be those of the "inner"
+ message, rather than of a message containing the inner
+ message. This makes it possible, for example, to send a
+ large audio message as several partial messages, and still
+ have it appear to the recipient as a simple audio message
+ rather than as an encapsulated message containing an audio
+ message. That is, the encapsulation of the message is
+ considered to be "transparent".
+
+ When generating and reassembling the parts of a
+ message/partial message, the headers of the encapsulated
+ message must be merged with the headers of the enclosing
+
+
+
+ Borenstein & Freed [Page 38]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ entities. In this process the following rules must be
+ observed:
+
+ (1) All of the headers from the initial enclosing
+ entity (part one), except those that start with
+ "Content-" and "Message-ID", must be copied, in
+ order, to the new message.
+
+ (2) Only those headers in the enclosed message
+ which start with "Content-" and "Message-ID" must
+ be appended, in order, to the headers of the new
+ message. Any headers in the enclosed message
+ which do not start with "Content-" (except for
+ "Message-ID") will be ignored.
+
+ (3) All of the headers from the second and any
+ subsequent messages will be ignored.
+
+ For example, if an audio message is broken into two parts,
+ the first part might look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ Message-ID: id1@host.com
+ MIME-Version: 1.0
+ Content-type: message/partial;
+ id="ABC@host.com";
+ number=1; total=2
+
+ X-Weird-Header-1: Bar
+ X-Weird-Header-2: Hello
+ Message-ID: anotherid@foo.com
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+
+ and the second half might look something like this:
+
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ MIME-Version: 1.0
+ Message-ID: id2@host.com
+ Content-type: message/partial;
+ id="ABC@host.com"; number=2; total=2
+
+ ... second half of encoded audio data goes here...
+
+ Then, when the fragmented message is reassembled, the
+ resulting message to be displayed to the user should look
+ something like this:
+
+
+
+ Borenstein & Freed [Page 39]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ Message-ID: anotherid@foo.com
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+ ... second half of encoded audio data goes here...
+
+ It should be noted that, because some message transfer
+ agents may choose to automatically fragment large messages,
+ and because such agents may use different fragmentation
+ thresholds, it is possible that the pieces of a partial
+ message, upon reassembly, may prove themselves to comprise a
+ partial message. This is explicitly permitted.
+
+ It should also be noted that the inclusion of a "References"
+ field in the headers of the second and subsequent pieces of
+ a fragmented message that references the Message-Id on the
+ previous piece may be of benefit to mail readers that
+ understand and track references. However, the generation of
+ such "References" fields is entirely optional.
+
+ 7.3.3 The Message/External-Body subtype
+
+ The external-body subtype indicates that the actual body
+ data are not included, but merely referenced. In this case,
+ the parameters describe a mechanism for accessing the
+ external data.
+
+ When a message body or body part is of type
+ "message/external-body", it consists of a header, two
+ consecutive CRLFs, and the message header for the
+ encapsulated message. If another pair of consecutive CRLFs
+ appears, this of course ends the message header for the
+ encapsulated message. However, since the encapsulated
+ message's body is itself external, it does NOT appear in the
+ area that follows. For example, consider the following
+ message:
+
+ Content-type: message/external-body; access-
+ type=local-file;
+ name=/u/nsb/Me.gif
+
+ Content-type: image/gif
+
+ THIS IS NOT REALLY THE BODY!
+
+ The area at the end, which might be called the "phantom
+ body", is ignored for most external-body messages. However,
+ it may be used to contain auxilliary information for some
+
+
+
+ Borenstein & Freed [Page 40]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ such messages, as indeed it is when the access-type is
+ "mail-server". Of the access-types defined by this
+ document, the phantom body is used only when the access-type
+ is "mail-server". In all other cases, the phantom body is
+ ignored.
+
+ The only always-mandatory parameter for message/external-
+ body is "access-type"; all of the other parameters may be
+ mandatory or optional depending on the value of access-type.
+
+ ACCESS-TYPE -- One or more case-insensitive words,
+ comma-separated, indicating supported access
+ mechanisms by which the file or data may be
+ obtained. Values include, but are not limited to,
+ "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE",
+ and "MAIL-SERVER". Future values, except for
+ experimental values beginning with "X-", must be
+ registered with IANA, as described in Appendix F .
+
+ In addition, the following two parameters are optional for
+ ALL access-types:
+
+ EXPIRATION -- The date (in the RFC 822 "date-time"
+ syntax, as extended by RFC 1123 to permit 4 digits
+ in the date field) after which the existence of
+ the external data is not guaranteed.
+
+ SIZE -- The size (in octets) of the data. The
+ intent of this parameter is to help the recipient
+ decide whether or not to expend the necessary
+ resources to retrieve the external data.
+
+ PERMISSION -- A field that indicates whether or
+ not it is expected that clients might also attempt
+ to overwrite the data. By default, or if
+ permission is "read", the assumption is that they
+ are not, and that if the data is retrieved once,
+ it is never needed again. If PERMISSION is "read-
+ write", this assumption is invalid, and any local
+ copy must be considered no more than a cache.
+ "Read" and "Read-write" are the only defined
+ values of permission.
+
+ The precise semantics of the access-types defined here are
+ described in the sections that follow.
+
+ 7.3.3.1 The "ftp" and "tftp" access-types
+
+ An access-type of FTP or TFTP indicates that the message
+ body is accessible as a file using the FTP [RFC-959] or TFTP
+ [RFC-783] protocols, respectively. For these access-types,
+ the following additional parameters are mandatory:
+
+
+
+
+
+ Borenstein & Freed [Page 41]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ NAME -- The name of the file that contains the
+ actual body data.
+
+ SITE -- A machine from which the file may be
+ obtained, using the given protocol
+
+ Before the data is retrieved, using these protocols, the
+ user will generally need to be asked to provide a login id
+ and a password for the machine named by the site parameter.
+
+ In addition, the following optional parameters may also
+ appear when the access-type is FTP or ANON-FTP:
+
+ DIRECTORY -- A directory from which the data named
+ by NAME should be retrieved.
+
+ MODE -- A transfer mode for retrieving the
+ information, e.g. "image".
+
+ 7.3.3.2 The "anon-ftp" access-type
+
+ The "anon-ftp" access-type is identical to the "ftp" access
+ type, except that the user need not be asked to provide a
+ name and password for the specified site. Instead, the ftp
+ protocol will be used with login "anonymous" and a password
+ that corresponds to the user's email address.
+
+ 7.3.3.3 The "local-file" and "afs" access-types
+
+ An access-type of "local-file" indicates that the actual
+ body is accessible as a file on the local machine. An
+ access-type of "afs" indicates that the file is accessible
+ via the global AFS file system. In both cases, only a
+ single parameter is required:
+
+ NAME -- The name of the file that contains the
+ actual body data.
+
+ The following optional parameter may be used to describe the
+ locality of reference for the data, that is, the site or
+ sites at which the file is expected to be visible:
+
+ SITE -- A domain specifier for a machine or set of
+ machines that are known to have access to the data
+ file. Asterisks may be used for wildcard matching
+ to a part of a domain name, such as
+ "*.bellcore.com", to indicate a set of machines on
+ which the data should be directly visible, while a
+ single asterisk may be used to indicate a file
+ that is expected to be universally available,
+ e.g., via a global file system.
+
+ 7.3.3.4 The "mail-server" access-type
+
+
+
+
+ Borenstein & Freed [Page 42]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ The "mail-server" access-type indicates that the actual body
+ is available from a mail server. The mandatory parameter
+ for this access-type is:
+
+ SERVER -- The email address of the mail server
+ from which the actual body data can be obtained.
+
+ Because mail servers accept a variety of syntax, some of
+ which is multiline, the full command to be sent to a mail
+ server is not included as a parameter on the content-type
+ line. Instead, it may be provided as the "phantom body"
+ when the content-type is message/external-body and the
+ access-type is mail-server.
+
+ Note that MIME does not define a mail server syntax.
+ Rather, it allows the inclusion of arbitrary mail server
+ commands in the phantom body. Implementations should
+ include the phantom body in the body of the message it sends
+ to the mail server address to retrieve the relevant data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 43]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.3.3.5 Examples and Further Explanations
+
+ With the emerging possibility of very wide-area file
+ systems, it becomes very hard to know in advance the set of
+ machines where a file will and will not be accessible
+ directly from the file system. Therefore it may make sense
+ to provide both a file name, to be tried directly, and the
+ name of one or more sites from which the file is known to be
+ accessible. An implementation can try to retrieve remote
+ files using FTP or any other protocol, using anonymous file
+ retrieval or prompting the user for the necessary name and
+ password. If an external body is accessible via multiple
+ mechanisms, the sender may include multiple parts of type
+ message/external-body within an entity of type
+ multipart/alternative.
+
+ However, the external-body mechanism is not intended to be
+ limited to file retrieval, as shown by the mail-server
+ access-type. Beyond this, one can imagine, for example,
+ using a video server for external references to video clips.
+
+ If an entity is of type "message/external-body", then the
+ body of the entity will contain the header fields of the
+ encapsulated message. The body itself is to be found in the
+ external location. This means that if the body of the
+ "message/external-body" message contains two consecutive
+ CRLFs, everything after those pairs is NOT part of the
+ message itself. For most message/external-body messages,
+ this trailing area must simply be ignored. However, it is a
+ convenient place for additional data that cannot be included
+ in the content-type header field. In particular, if the
+ "access-type" value is "mail-server", then the trailing area
+ must contain commands to be sent to the mail server at the
+ address given by NAME@SITE, where NAME and SITE are the
+ values of the NAME and SITE parameters, respectively.
+
+ The embedded message header fields which appear in the body
+ of the message/external-body data can be used to declare the
+ Content-type of the external body. Thus a complete
+ message/external-body message, referring to a document in
+ PostScript format, might look like this:
+
+ From: Whomever
+ Subject: whatever
+ MIME-Version: 1.0
+ Message-ID: id1@host.com
+ Content-Type: multipart/alternative; boundary=42
+
+
+ --42
+ Content-Type: message/external-body;
+ name="BodyFormats.ps";
+
+
+
+
+
+ Borenstein & Freed [Page 44]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ site="thumper.bellcore.com";
+ access-type=ANON-FTP;
+ directory="pub";
+ mode="image";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+
+ --42
+ Content-Type: message/external-body;
+ name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
+ site="thumper.bellcore.com";
+ access-type=AFS
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+
+ --42
+ Content-Type: message/external-body;
+ access-type=mail-server
+ server="listserv@bogus.bitnet";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+
+ get rfc-xxxx doc
+
+ --42--
+
+ Like the message/partial type, the message/external-body
+ type is intended to be transparent, that is, to convey the
+ data type in the external body rather than to convey a
+ message with a body of that type. Thus the headers on the
+ outer and inner parts must be merged using the same rules as
+ for message/partial. In particular, this means that the
+ Content-type header is overridden, but the From and Subject
+ headers are preserved.
+
+ Note that since the external bodies are not transported as
+ mail, they need not conform to the 7-bit and line length
+ requirements, but might in fact be binary files. Thus a
+ Content-Transfer-Encoding is not generally necessary, though
+ it is permitted.
+
+ Note that the body of a message of type "message/external-
+ body" is governed by the basic syntax for an RFC 822
+ message. In particular, anything before the first
+ consecutive pair of CRLFs is header information, while
+ anything after it is body information, which is ignored for
+ most access-types.
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 45]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.4 The Application Content-Type
+
+ The "application" Content-Type is to be used for data which
+ do not fit in any of the other categories, and particularly
+ for data to be processed by mail-based uses of application
+ programs. This is information which must be processed by an
+ application before it is viewable or usable to a user.
+ Expected uses for Content-Type application include mail-
+ based file transfer, spreadsheets, data for mail-based
+ scheduling systems, and languages for "active"
+ (computational) email. (The latter, in particular, can pose
+ security problems which should be understood by
+ implementors, and are considered in detail in the discussion
+ of the application/PostScript content-type.)
+
+ For example, a meeting scheduler might define a standard
+ representation for information about proposed meeting dates.
+ An intelligent user agent would use this information to
+ conduct a dialog with the user, and might then send further
+ mail based on that dialog. More generally, there have been
+ several "active" messaging languages developed in which
+ programs in a suitably specialized language are sent through
+ the mail and automatically run in the recipient's
+ environment.
+
+ Such applications may be defined as subtypes of the
+ "application" Content-Type. This document defines three
+ subtypes: octet-stream, ODA, and PostScript.
+
+ In general, the subtype of application will often be the
+ name of the application for which the data are intended.
+ This does not mean, however, that any application program
+ name may be used freely as a subtype of application. Such
+ usages must be registered with IANA, as described in
+ Appendix F.
+
+ 7.4.1 The Application/Octet-Stream (primary) subtype
+
+ The primary subtype of application, "octet-stream", may be
+ used to indicate that a body contains binary data. The set
+ of possible parameters includes, but is not limited to:
+
+ NAME -- a suggested name for the binary data if
+ stored as a file.
+
+ TYPE -- the general type or category of binary
+ data. This is intended as information for the
+ human recipient rather than for any automatic
+ processing.
+
+ CONVERSIONS -- the set of operations that have
+ been performed on the data before putting it in
+ the mail (and before any Content-Transfer-Encoding
+ that might have been applied). If multiple
+
+
+
+ Borenstein & Freed [Page 46]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ conversions have occurred, they must be separated
+ by commas and specified in the order they were
+ applied -- that is, the leftmost conversion must
+ have occurred first, and conversions are undone
+ from right to left. Note that NO conversion
+ values are defined by this document. Any
+ conversion values that that do not begin with "X-"
+ must be preceded by a published specification and
+ by registration with IANA, as described in
+ Appendix F.
+
+ PADDING -- the number of bits of padding that were
+ appended to the bitstream comprising the actual
+ contents to produce the enclosed byte-oriented
+ data. This is useful for enclosing a bitstream in
+ a body when the total number of bits is not a
+ multiple of the byte size.
+
+ The values for these attributes are left undefined at
+ present, but may require specification in the future. An
+ example of a common (though UNIX-specific) usage might be:
+
+ Content-Type: application/octet-stream;
+ name=foo.tar.Z; type=tar;
+ conversions="x-encrypt,x-compress"
+
+ However, it should be noted that the use of such conversions
+ is explicitly discouraged due to a lack of portability and
+ standardization. The use of uuencode is particularly
+ discouraged, in favor of the Content-Transfer-Encoding
+ mechanism, which is both more standardized and more portable
+ across mail boundaries.
+
+ The recommended action for an implementation that receives
+ application/octet-stream mail is to simply offer to put the
+ data in a file, with any Content-Transfer-Encoding undone,
+ or perhaps to use it as input to a user-specified process.
+
+ To reduce the danger of transmitting rogue programs through
+ the mail, it is strongly recommended that implementations
+ NOT implement a path-search mechanism whereby an arbitrary
+ program named in the Content-Type parameter (e.g., an
+ "interpreter=" parameter) is found and executed using the
+ mail body as input.
+
+ 7.4.2 The Application/PostScript subtype
+
+ A Content-Type of "application/postscript" indicates a
+ PostScript program. The language is defined in
+ [POSTSCRIPT]. It is recommended that Postscript as sent
+ through email should use Postscript document structuring
+ conventions if at all possible, and correctly.
+
+
+
+
+
+ Borenstein & Freed [Page 47]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ The execution of general-purpose PostScript interpreters
+ entails serious security risks, and implementors are
+ discouraged from simply sending PostScript email bodies to
+ "off-the-shelf" interpreters. While it is usually safe to
+ send PostScript to a printer, where the potential for harm
+ is greatly constrained, implementors should consider all of
+ the following before they add interactive display of
+ PostScript bodies to their mail readers.
+
+ The remainder of this section outlines some, though probably
+ not all, of the possible problems with sending PostScript
+ through the mail.
+
+ Dangerous operations in the PostScript language include, but
+ may not be limited to, the PostScript operators deletefile,
+ renamefile, filenameforall, and file. File is only
+ dangerous when applied to something other than standard
+ input or output. Implementations may also define additional
+ nonstandard file operators; these may also pose a threat to
+ security. Filenameforall, the wildcard file search
+ operator, may appear at first glance to be harmless. Note,
+ however, that this operator has the potential to reveal
+ information about what files the recipient has access to,
+ and this information may itself be sensitive. Message
+ senders should avoid the use of potentially dangerous file
+ operators, since these operators are quite likely to be
+ unavailable in secure PostScript implementations. Message-
+ receiving and -displaying software should either completely
+ disable all potentially dangerous file operators or take
+ special care not to delegate any special authority to their
+ operation. These operators should be viewed as being done by
+ an outside agency when interpreting PostScript documents.
+ Such disabling and/or checking should be done completely
+ outside of the reach of the PostScript language itself; care
+ should be taken to insure that no method exists for
+ reenabling full-function versions of these operators.
+
+ The PostScript language provides facilities for exiting the
+ normal interpreter, or server, loop. Changes made in this
+ "outer" environment are customarily retained across
+ documents, and may in some cases be retained semipermanently
+ in nonvolatile memory. The operators associated with exiting
+ the interpreter loop have the potential to interfere with
+ subsequent document processing. As such, their unrestrained
+ use constitutes a threat of service denial. PostScript
+ operators that exit the interpreter loop include, but may
+ not be limited to, the exitserver and startjob operators.
+ Message-sending software should not generate PostScript that
+ depends on exiting the interpreter loop to operate. The
+ ability to exit will probably be unavailable in secure
+ PostScript implementations. Message-receiving and
+ -displaying software should, if possible, disable the
+ ability to make retained changes to the PostScript
+ environment. Eliminate the startjob and exitserver commands.
+
+
+
+ Borenstein & Freed [Page 48]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ If these commands cannot be eliminated, at least set the
+ password associated with them to a hard-to-guess value.
+
+ PostScript provides operators for setting system-wide and
+ device-specific parameters. These parameter settings may be
+ retained across jobs and may potentially pose a threat to
+ the correct operation of the interpreter. The PostScript
+ operators that set system and device parameters include, but
+ may not be limited to, the setsystemparams and setdevparams
+ operators. Message-sending software should not generate
+ PostScript that depends on the setting of system or device
+ parameters to operate correctly. The ability to set these
+ parameters will probably be unavailable in secure PostScript
+ implementations. Message-receiving and -displaying software
+ should, if possible, disable the ability to change system
+ and device parameters. If these operators cannot be
+ disabled, at least set the password associated with them to
+ a hard-to-guess value.
+
+ Some PostScript implementations provide nonstandard
+ facilities for the direct loading and execution of machine
+ code. Such facilities are quite obviously open to
+ substantial abuse. Message-sending software should not
+ make use of such features. Besides being totally hardware-
+ specific, they are also likely to be unavailable in secure
+ implementations of PostScript. Message-receiving and
+ -displaying software should not allow such operators to be
+ used if they exist.
+
+ PostScript is an extensible language, and many, if not most,
+ implementations of it provide a number of their own
+ extensions. This document does not deal with such extensions
+ explicitly since they constitute an unknown factor.
+ Message-sending software should not make use of nonstandard
+ extensions; they are likely to be missing from some
+ implementations. Message-receiving and -displaying software
+ should make sure that any nonstandard PostScript operators
+ are secure and don't present any kind of threat.
+
+ It is possible to write PostScript that consumes huge
+ amounts of various system resources. It is also possible to
+ write PostScript programs that loop infinitely. Both types
+ of programs have the potential to cause damage if sent to
+ unsuspecting recipients. Message-sending software should
+ avoid the construction and dissemination of such programs,
+ which is antisocial. Message-receiving and -displaying
+ software should provide appropriate mechanisms to abort
+ processing of a document after a reasonable amount of time
+ has elapsed. In addition, PostScript interpreters should be
+ limited to the consumption of only a reasonable amount of
+ any given system resource.
+
+ Finally, bugs may exist in some PostScript interpreters
+ which could possibly be exploited to gain unauthorized
+
+
+
+ Borenstein & Freed [Page 49]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ access to a recipient's system. Apart from noting this
+ possibility, there is no specific action to take to prevent
+ this, apart from the timely correction of such bugs if any
+ are found.
+
+ 7.4.3 The Application/ODA subtype
+
+ The "ODA" subtype of application is used to indicate that a
+ body contains information encoded according to the Office
+ Document Architecture [ODA] standards, using the ODIF
+ representation format. For application/oda, the Content-
+ Type line should also specify an attribute/value pair that
+ indicates the document application profile (DAP), using the
+ key word "profile". Thus an appropriate header field might
+ look like this:
+
+ Content-Type: application/oda; profile=Q112
+
+ Consult the ODA standard [ODA] for further information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 50]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.5 The Image Content-Type
+
+ A Content-Type of "image" indicates that the bodycontains an
+ image. The subtype names the specific image format. These
+ names are case insensitive. Two initial subtypes are "jpeg"
+ for the JPEG format, JFIF encoding, and "gif" for GIF format
+ [GIF].
+
+ The list of image subtypes given here is neither exclusive
+ nor exhaustive, and is expected to grow as more types are
+ registered with IANA, as described in Appendix F.
+
+ 7.6 The Audio Content-Type
+
+ A Content-Type of "audio" indicates that the body contains
+ audio data. Although there is not yet a consensus on an
+ "ideal" audio format for use with computers, there is a
+ pressing need for a format capable of providing
+ interoperable behavior.
+
+ The initial subtype of "basic" is specified to meet this
+ requirement by providing an absolutely minimal lowest common
+ denominator audio format. It is expected that richer
+ formats for higher quality and/or lower bandwidth audio will
+ be defined by a later document.
+
+ The content of the "audio/basic" subtype is audio encoded
+ using 8-bit ISDN u-law [PCM]. When this subtype is present,
+ a sample rate of 8000 Hz and a single channel is assumed.
+
+ 7.7 The Video Content-Type
+
+ A Content-Type of "video" indicates that the body contains a
+ time-varying-picture image, possibly with color and
+ coordinated sound. The term "video" is used extremely
+ generically, rather than with reference to any particular
+ technology or format, and is not meant to preclude subtypes
+ such as animated drawings encoded compactly. The subtype
+ "mpeg" refers to video coded according to the MPEG standard
+ [MPEG].
+
+ Note that although in general this document strongly
+ discourages the mixing of multiple media in a single body,
+ it is recognized that many so-called "video" formats include
+ a representation for synchronized audio, and this is
+ explicitly permitted for subtypes of "video".
+
+ 7.8 Experimental Content-Type Values
+
+ A Content-Type value beginning with the characters "X-" is a
+ private value, to be used by consenting mail systems by
+ mutual agreement. Any format without a rigorous and public
+ definition must be named with an "X-" prefix, and publicly
+ specified values shall never begin with "X-". (Older
+
+
+
+ Borenstein & Freed [Page 51]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ versions of the widely-used Andrew system use the "X-BE2"
+ name, so new systems should probably choose a different
+ name.)
+
+ In general, the use of "X-" top-level types is strongly
+ discouraged. Implementors should invent subtypes of the
+ existing types whenever possible. The invention of new
+ types is intended to be restricted primarily to the
+ development of new media types for email, such as digital
+ odors or holography, and not for new data formats in
+ general. In many cases, a subtype of application will be
+ more appropriate than a new top-level type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 52]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Summary
+
+ Using the MIME-Version, Content-Type, and Content-Transfer-
+ Encoding header fields, it is possible to include, in a
+ standardized way, arbitrary types of data objects with RFC
+ 822 conformant mail messages. No restrictions imposed by
+ either RFC 821 or RFC 822 are violated, and care has been
+ taken to avoid problems caused by additional restrictions
+ imposed by the characteristics of some Internet mail
+ transport mechanisms (see Appendix B). The "multipart" and
+ "message" Content-Types allow mixing and hierarchical
+ structuring of objects of different types in a single
+ message. Further Content-Types provide a standardized
+ mechanism for tagging messages or body parts as audio,
+ image, or several other kinds of data. A distinguished
+ parameter syntax allows further specification of data format
+ details, particularly the specification of alternate
+ character sets. Additional optional header fields provide
+ mechanisms for certain extensions deemed desirable by many
+ implementors. Finally, a number of useful Content-Types are
+ defined for general use by consenting user agents, notably
+ text/richtext, message/partial, and message/external-body.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 53]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Acknowledgements
+
+ This document is the result of the collective effort of a
+ large number of people, at several IETF meetings, on the
+ IETF-SMTP and IETF-822 mailing lists, and elsewhere.
+ Although any enumeration seems doomed to suffer from
+ egregious omissions, the following are among the many
+ contributors to this effort:
+
+ Harald Tveit Alvestrand Timo Lehtinen
+ Randall Atkinson John R. MacMillan
+ Philippe Brandon Rick McGowan
+ Kevin Carosso Leo Mclaughlin
+ Uhhyung Choi Goli Montaser-Kohsari
+ Cristian Constantinof Keith Moore
+ Mark Crispin Tom Moore
+ Dave Crocker Erik Naggum
+ Terry Crowley Mark Needleman
+ Walt Daniels John Noerenberg
+ Frank Dawson Mats Ohrman
+ Hitoshi Doi Julian Onions
+ Kevin Donnelly Michael Patton
+ Keith Edwards David J. Pepper
+ Chris Eich Blake C. Ramsdell
+ Johnny Eriksson Luc Rooijakkers
+ Craig Everhart Marshall T. Rose
+ Patrik Faeltstroem Jonathan Rosenberg
+ Erik E. Fair Jan Rynning
+ Roger Fajman Harri Salminen
+ Alain Fontaine Michael Sanderson
+ James M. Galvin Masahiro Sekiguchi
+ Philip Gladstone Mark Sherman
+ Thomas Gordon Keld Simonsen
+ Phill Gross Bob Smart
+ James Hamilton Peter Speck
+ Steve Hardcastle-Kille Henry Spencer
+ David Herron Einar Stefferud
+ Bruce Howard Michael Stein
+ Bill Janssen Klaus Steinberger
+ Olle Jaernefors Peter Svanberg
+ Risto Kankkunen James Thompson
+ Phil Karn Steve Uhler
+ Alan Katz Stuart Vance
+ Tim Kehres Erik van der Poel
+ Neil Katin Guido van Rossum
+ Kyuho Kim Peter Vanderbilt
+ Anders Klemets Greg Vaudreuil
+ John Klensin Ed Vielmetti
+ Valdis Kletniek Ryan Waldron
+ Jim Knowles Wally Wedel
+ Stev Knowles Sven-Ove Westberg
+ Bob Kummerfeld Brian Wideen
+
+
+
+
+
+ Borenstein & Freed [Page 54]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Pekka Kytolaakso John Wobus
+ Stellan Lagerstr.m Glenn Wright
+ Vincent Lau Rayan Zachariassen
+ Donald Lindsay David Zimmerman
+ The authors apologize for any omissions from this list,
+ which are certainly unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 55]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix A -- Minimal MIME-Conformance
+
+ The mechanisms described in this document are open-ended.
+ It is definitely not expected that all implementations will
+ support all of the Content-Types described, nor that they
+ will all share the same extensions. In order to promote
+ interoperability, however, it is useful to define the
+ concept of "MIME-conformance" to define a certain level of
+ implementation that allows the useful interworking of
+ messages with content that differs from US ASCII text. In
+ this section, we specify the requirements for such
+ conformance.
+
+ A mail user agent that is MIME-conformant MUST:
+
+ 1. Always generate a "MIME-Version: 1.0" header
+ field.
+
+ 2. Recognize the Content-Transfer-Encoding header
+ field, and decode all received data encoded with
+ either the quoted-printable or base64
+ implementations. Encode any data sent that is
+ not in seven-bit mail-ready representation using
+ one of these transformations and include the
+ appropriate Content-Transfer-Encoding header
+ field, unless the underlying transport mechanism
+ supports non-seven-bit data, as SMTP does not.
+
+ 3. Recognize and interpret the Content-Type
+ header field, and avoid showing users raw data
+ with a Content-Type field other than text. Be
+ able to send at least text/plain messages, with
+ the character set specified as a parameter if it
+ is not US-ASCII.
+
+ 4. Explicitly handle the following Content-Type
+ values, to at least the following extents:
+
+ Text:
+ -- Recognize and display "text" mail
+ with the character set "US-ASCII."
+ -- Recognize other character sets at
+ least to the extent of being able
+ to inform the user about what
+ character set the message uses.
+ -- Recognize the "ISO-8859-*" character
+ sets to the extent of being able to
+ display those characters that are
+ common to ISO-8859-* and US-ASCII,
+ namely all characters represented
+ by octet values 0-127.
+ -- For unrecognized subtypes, show or
+ offer to show the user the "raw"
+ version of the data. An ability at
+
+
+
+ Borenstein & Freed [Page 56]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ least to convert "text/richtext" to
+ plain text, as shown in Appendix D,
+ is encouraged, but not required for
+ conformance.
+ Message:
+ --Recognize and display at least the
+ primary (822) encapsulation.
+ Multipart:
+ -- Recognize the primary (mixed)
+ subtype. Display all relevant
+ information on the message level
+ and the body part header level and
+ then display or offer to display
+ each of the body parts
+ individually.
+ -- Recognize the "alternative" subtype,
+ and avoid showing the user
+ redundant parts of
+ multipart/alternative mail.
+ -- Treat any unrecognized subtypes as if
+ they were "mixed".
+ Application:
+ -- Offer the ability to remove either of
+ the two types of Content-Transfer-
+ Encoding defined in this document
+ and put the resulting information
+ in a user file.
+
+ 5. Upon encountering any unrecognized Content-
+ Type, an implementation must treat it as if it had
+ a Content-Type of "application/octet-stream" with
+ no parameter sub-arguments. How such data are
+ handled is up to an implementation, but likely
+ options for handling such unrecognized data
+ include offering the user to write it into a file
+ (decoded from its mail transport format) or
+ offering the user to name a program to which the
+ decoded data should be passed as input.
+ Unrecognized predefined types, which in a MIME-
+ conformant mailer might still include audio,
+ image, or video, should also be treated in this
+ way.
+
+ A user agent that meets the above conditions is said to be
+ MIME-conformant. The meaning of this phrase is that it is
+ assumed to be "safe" to send virtually any kind of
+ properly-marked data to users of such mail systems, because
+ such systems will at least be able to treat the data as
+ undifferentiated binary, and will not simply splash it onto
+ the screen of unsuspecting users. There is another sense
+ in which it is always "safe" to send data in a format that
+ is MIME-conformant, which is that such data will not break
+ or be broken by any known systems that are conformant with
+ RFC 821 and RFC 822. User agents that are MIME-conformant
+
+
+
+ Borenstein & Freed [Page 57]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ have the additional guarantee that the user will not be
+ shown data that were never intended to be viewed as text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 58]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix B -- General Guidelines For Sending Email Data
+
+ Internet email is not a perfect, homogeneous system. Mail
+ may become corrupted at several stages in its travel to a
+ final destination. Specifically, email sent throughout the
+ Internet may travel across many networking technologies.
+ Many networking and mail technologies do not support the
+ full functionality possible in the SMTP transport
+ environment. Mail traversing these systems is likely to be
+ modified in such a way that it can be transported.
+
+ There exist many widely-deployed non-conformant MTAs in the
+ Internet. These MTAs, speaking the SMTP protocol, alter
+ messages on the fly to take advantage of the internal data
+ structure of the hosts they are implemented on, or are just
+ plain broken.
+
+ The following guidelines may be useful to anyone devising a
+ data format (Content-Type) that will survive the widest
+ range of networking technologies and known broken MTAs
+ unscathed. Note that anything encoded in the base64
+ encoding will satisfy these rules, but that some well-known
+ mechanisms, notably the UNIX uuencode facility, will not.
+ Note also that anything encoded in the Quoted-Printable
+ encoding will survive most gateways intact, but possibly not
+ some gateways to systems that use the EBCDIC character set.
+
+ (1) Under some circumstances the encoding used for
+ data may change as part of normal gateway or user
+ agent operation. In particular, conversion from
+ base64 to quoted-printable and vice versa may be
+ necessary. This may result in the confusion of
+ CRLF sequences with line breaks in text body
+ parts. As such, the persistence of CRLF as
+ something other than a line break should not be
+ relied on.
+
+ (2) Many systems may elect to represent and store
+ text data using local newline conventions. Local
+ newline conventions may not match the RFC822 CRLF
+ convention -- systems are known that use plain CR,
+ plain LF, CRLF, or counted records. The result is
+ that isolated CR and LF characters are not well
+ tolerated in general; they may be lost or
+ converted to delimiters on some systems, and hence
+ should not be relied on.
+
+ (3) TAB (HT) characters may be misinterpreted or
+ may be automatically converted to variable numbers
+ of spaces. This is unavoidable in some
+ environments, notably those not based on the ASCII
+ character set. Such conversion is STRONGLY
+ DISCOURAGED, but it may occur, and mail formats
+ should not rely on the persistence of TAB (HT)
+
+
+
+ Borenstein & Freed [Page 59]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ characters.
+
+ (4) Lines longer than 76 characters may be wrapped
+ or truncated in some environments. Line wrapping
+ and line truncation are STRONGLY DISCOURAGED, but
+ unavoidable in some cases. Applications which
+ require long lines should somehow differentiate
+ between soft and hard line breaks. (A simple way
+ to do this is to use the quoted-printable
+ encoding.)
+
+ (5) Trailing "white space" characters (SPACE, TAB
+ (HT)) on a line may be discarded by some transport
+ agents, while other transport agents may pad lines
+ with these characters so that all lines in a mail
+ file are of equal length. The persistence of
+ trailing white space, therefore, should not be
+ relied on.
+
+ (6) Many mail domains use variations on the ASCII
+ character set, or use character sets such as
+ EBCDIC which contain most but not all of the US-
+ ASCII characters. The correct translation of
+ characters not in the "invariant" set cannot be
+ depended on across character converting gateways.
+ For example, this situation is a problem when
+ sending uuencoded information across BITNET, an
+ EBCDIC system. Similar problems can occur without
+ crossing a gateway, since many Internet hosts use
+ character sets other than ASCII internally. The
+ definition of Printable Strings in X.400 adds
+ further restrictions in certain special cases. In
+ particular, the only characters that are known to
+ be consistent across all gateways are the 73
+ characters that correspond to the upper and lower
+ case letters A-Z and a-z, the 10 digits 0-9, and
+ the following eleven special characters:
+
+ "'" (ASCII code 39)
+ "(" (ASCII code 40)
+ ")" (ASCII code 41)
+ "+" (ASCII code 43)
+ "," (ASCII code 44)
+ "-" (ASCII code 45)
+ "." (ASCII code 46)
+ "/" (ASCII code 47)
+ ":" (ASCII code 58)
+ "=" (ASCII code 61)
+ "?" (ASCII code 63)
+
+ A maximally portable mail representation, such as
+ the base64 encoding, will confine itself to
+ relatively short lines of text in which the only
+ meaningful characters are taken from this set of
+
+
+
+ Borenstein & Freed [Page 60]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 73 characters.
+
+ Please note that the above list is NOT a list of recommended
+ practices for MTAs. RFC 821 MTAs are prohibited from
+ altering the character of white space or wrapping long
+ lines. These BAD and illegal practices are known to occur
+ on established networks, and implementions should be robust
+ in dealing with the bad effects they can cause.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 61]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix C -- A Complex Multipart Example
+
+ What follows is the outline of a complex multipart message.
+ This message has five parts to be displayed serially: two
+ introductory plain text parts, an embedded multipart
+ message, a richtext part, and a closing encapsulated text
+ message in a non-ASCII character set. The embedded
+ multipart message has two parts to be displayed in parallel,
+ a picture and an audio fragment.
+
+ MIME-Version: 1.0
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ Subject: A multipart example
+ Content-Type: multipart/mixed;
+ boundary=unique-boundary-1
+
+ This is the preamble area of a multipart message.
+ Mail readers that understand multipart format
+ should ignore this preamble.
+ If you are reading this text, you might want to
+ consider changing to a mail reader that understands
+ how to properly display multipart messages.
+ --unique-boundary-1
+
+ ...Some text appears here...
+ [Note that the preceding blank line means
+ no header fields were given and this is text,
+ with charset US ASCII. It could have been
+ done with explicit typing as in the next part.]
+
+ --unique-boundary-1
+ Content-type: text/plain; charset=US-ASCII
+
+ This could have been part of the previous part,
+ but illustrates explicit versus implicit
+ typing of body parts.
+
+ --unique-boundary-1
+ Content-Type: multipart/parallel;
+ boundary=unique-boundary-2
+
+
+ --unique-boundary-2
+ Content-Type: audio/basic
+ Content-Transfer-Encoding: base64
+
+ ... base64-encoded 8000 Hz single-channel
+ u-law-format audio data goes here....
+
+ --unique-boundary-2
+ Content-Type: image/gif
+ Content-Transfer-Encoding: Base64
+
+
+
+
+
+ Borenstein & Freed [Page 62]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ ... base64-encoded image data goes here....
+
+ --unique-boundary-2--
+
+ --unique-boundary-1
+ Content-type: text/richtext
+
+ This is <bold><italic>richtext.</italic></bold>
+ <nl><nl>Isn't it
+ <bigger><bigger>cool?</bigger></bigger>
+
+ --unique-boundary-1
+ Content-Type: message/rfc822
+
+ From: (name in US-ASCII)
+ Subject: (subject in US-ASCII)
+ Content-Type: Text/plain; charset=ISO-8859-1
+ Content-Transfer-Encoding: Quoted-printable
+
+ ... Additional text in ISO-8859-1 goes here ...
+
+ --unique-boundary-1--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 63]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix D -- A Simple Richtext-to-Text Translator in C
+
+ One of the major goals in the design of the richtext subtype
+ of the text Content-Type is to make formatted text so simple
+ that even text-only mailers will implement richtext-to-
+ plain-text translators, thus increasing the likelihood that
+ multifont text will become "safe" to use very widely. To
+ demonstrate this simplicity, what follows is an extremely
+ simple 44-line C program that converts richtext input into
+ plain text output:
+
+ #include <stdio.h>
+ #include <ctype.h>
+ main() {
+ int c, i;
+ char token[50];
+
+ while((c = getc(stdin)) != EOF) {
+ if (c == '<') {
+ for (i=0; (i<49 && (c = getc(stdin)) != '>'
+ && c != EOF); ++i) {
+ token[i] = isupper(c) ? tolower(c) : c;
+ }
+ if (c == EOF) break;
+ if (c != '>') while ((c = getc(stdin)) !=
+ '>'
+ && c != EOF) {;}
+ if (c == EOF) break;
+ token[i] = '\0';
+ if (!strcmp(token, "lt")) {
+ putc('<', stdout);
+ } else if (!strcmp(token, "nl")) {
+ putc('\n', stdout);
+ } else if (!strcmp(token, "/paragraph")) {
+ fputs("\n\n", stdout);
+ } else if (!strcmp(token, "comment")) {
+ int commct=1;
+ while (commct > 0) {
+ while ((c = getc(stdin)) != '<'
+ && c != EOF) ;
+ if (c == EOF) break;
+ for (i=0; (c = getc(stdin)) != '>'
+ && c != EOF; ++i) {
+ token[i] = isupper(c) ?
+ tolower(c) : c;
+ }
+ if (c== EOF) break;
+ token[i] = NULL;
+ if (!strcmp(token, "/comment")) --
+ commct;
+ if (!strcmp(token, "comment"))
+ ++commct;
+
+
+
+
+
+ Borenstein & Freed [Page 64]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ }
+ } /* Ignore all other tokens */
+ } else if (c != '\n') putc(c, stdout);
+ }
+ putc('\n', stdout); /* for good measure */
+ }
+ It should be noted that one can do considerably better than
+ this in displaying richtext data on a dumb terminal. In
+ particular, one can replace font information such as "bold"
+ with textual emphasis (like *this* or _T_H_I_S_). One can
+ also properly handle the richtext formatting commands
+ regarding indentation, justification, and others. However,
+ the above program is all that is necessary in order to
+ present richtext on a dumb terminal.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 65]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix E -- Collected Grammar
+
+ This appendix contains the complete BNF grammar for all the
+ syntax specified by this document.
+
+ By itself, however, this grammar is incomplete. It refers
+ to several entities that are defined by RFC 822. Rather
+ than reproduce those definitions here, and risk
+ unintentional differences between the two, this document
+ simply refers the reader to RFC 822 for the remaining
+ definitions. Wherever a term is undefined, it refers to the
+ RFC 822 definition.
+
+ attribute := token
+
+ body-part = <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere.>
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
+ "_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ close-delimiter := delimiter "--"
+
+ Content-Description := *text
+
+ Content-ID := msg-id
+
+ Content-Transfer-Encoding := "BASE64" / "QUOTED-
+ PRINTABLE" /
+ "8BIT" / "7BIT" /
+ "BINARY" / x-token
+
+ Content-Type := type "/" subtype *[";" parameter]
+
+ delimiter := CRLF "--" boundary ; taken from Content-Type
+ field.
+ ; when content-type is
+ multipart
+ ; There should be no space
+ ; between "--" and boundary.
+
+ encapsulation := delimiter CRLF body-part
+
+ epilogue := *text ; to be ignored upon
+ receipt.
+
+
+
+
+ Borenstein & Freed [Page 66]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ MIME-Version := 1*text
+
+ multipart-body := preamble 1*encapsulation close-delimiter
+ epilogue
+
+ parameter := attribute "=" value
+
+ preamble := *text ; to be ignored upon
+ receipt.
+
+ subtype := token
+
+ token := 1*<any CHAR except SPACE, CTLs, or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
+ / "," / ";" / ":" / "\" / <"> ; quoted-string,
+ / "/" / "[" / "]" / "?" / "." ; to use within
+ / "=" ; parameter values
+
+
+ type := "application" / "audio" ; case-
+ insensitive
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / x-token
+
+ value := token / quoted-string
+
+ x-token := <The two characters "X-" followed, with no
+ intervening white space, by any token>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 67]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix F -- IANA Registration Procedures
+
+ MIME has been carefully designed to have extensible
+ mechanisms, 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
+ character set names, access-type parameters for the
+ message/external-body type, conversions parameters for the
+ application type, and possibly even Content-Transfer-
+ Encoding values, 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.
+
+ In general, parameters in the content-type header field are
+ used to convey supplemental information for various content
+ types, and their use is defined when the content-type and
+ subtype are defined. New parameters should not be defined
+ as a way to introduce new functionality.
+
+ In order to simplify and standardize the registration
+ process, this appendix gives templates for the registration
+ of new values with IANA. Each of these is given in the form
+ of an email message template, to be filled in by the
+ registering party.
+
+ F.1 Registration of New Content-type/subtype Values
+
+ Note that MIME is generally expected to be extended by
+ subtypes. If a new fundamental top-level type is needed,
+ its specification should be published as an RFC or
+ submitted in a form suitable to become an RFC, and be
+ subject to the Internet standards process.
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME content-type/subtype
+
+ MIME type name:
+
+ (If the above is not an existing top-level MIME type,
+ please explain why an existing type cannot be used.)
+
+ MIME subtype name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Encoding considerations:
+
+ Security considerations:
+
+
+
+
+ Borenstein & Freed [Page 68]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be if a new top-level type is being defined, and
+ must be a publicly available specification in any
+ case.)
+
+ Person & email address to contact for further
+ information:
+ F.2 Registration of New Character Set Values
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME character set value
+
+ MIME character set name:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be or an international standard.)
+
+ Person & email address to contact for further
+ information:
+
+ F.3 Registration of New Access-type Values for
+ Message/external-body
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME Access-type for
+ Message/external-body content-type
+
+ MIME access-type name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be.)
+
+ Person & email address to contact for further
+ information:
+
+
+ F.4 Registration of New Conversions Values for Application
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME Conversions value
+ for Application content-type
+
+ MIME Conversions name:
+
+
+
+
+ Borenstein & Freed [Page 69]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be.)
+
+ Person & email address to contact for further
+ information:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 70]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix G -- Summary of the Seven Content-types
+
+ Content-type: text
+
+ Subtypes defined by this document: plain, richtext
+
+ Important Parameters: charset
+
+ Encoding notes: quoted-printable generally preferred if an
+ encoding is needed and the character set is mostly an
+ ASCII superset.
+
+ Security considerations: Rich text formats such as TeX and
+ Troff often contain mechanisms for executing arbitrary
+ commands or file system operations, and should not be
+ used automatically unless these security problems have
+ been addressed. Even plain text may contain control
+ characters that can be used to exploit the capabilities
+ of "intelligent" terminals and cause security
+ violations. User interfaces designed to run on such
+ terminals should be aware of and try to prevent such
+ problems.
+ ________________________________________________________________
+
+ Content-type: multipart
+
+ Subtypes defined by this document: mixed, alternative,
+ digest, parallel.
+
+ Important Parameters: boundary
+
+ Encoding notes: No content-transfer-encoding is permitted.
+
+ ________________________________________________________________
+
+ Content-type: message
+
+ Subtypes defined by this document: rfc822, partial,
+ external-body
+
+ Important Parameters: id, number, total
+
+ Encoding notes: No content-transfer-encoding is permitted.
+
+ ________________________________________________________________
+
+ Content-type: application
+
+ Subtypes defined by this document: octet-stream,
+ postscript, oda
+
+ Important Parameters: profile
+
+
+
+
+
+ Borenstein & Freed [Page 71]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Encoding notes: base64 generally preferred for octet-stream
+ or other unreadable subtypes.
+
+ Security considerations: This type is intended for the
+ transmission of data to be interpreted by locally-installed
+ programs. If used, for example, to transmit executable
+ binary programs or programs in general-purpose interpreted
+ languages, such as LISP programs or shell scripts, severe
+ security problems could result. In general, authors of
+ mail-reading agents are cautioned against giving their
+ systems the power to execute mail-based application data
+ without carefully considering the security implications.
+ While it is certainly possible to define safe application
+ formats and even safe interpreters for unsafe formats, each
+ interpreter should be evaluated separately for possible
+ security problems.
+ ________________________________________________________________
+
+ Content-type: image
+
+ Subtypes defined by this document: jpeg, gif
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+ ________________________________________________________________
+
+ Content-type: audio
+
+ Subtypes defined by this document: basic
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+ ________________________________________________________________
+
+ Content-type: video
+
+ Subtypes defined by this document: mpeg
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 72]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix H -- Canonical Encoding Model
+
+
+
+ There was some confusion, in earlier drafts of this memo,
+ regarding the model for when email data was to be converted
+ to canonical form and encoded, and in particular how this
+ process would affect the treatment of CRLFs, given that the
+ representation of newlines varies greatly from system to
+ system. For this reason, a canonical model for encoding is
+ presented below.
+
+ The process of composing a MIME message part can be modelled
+ as being done in a number of steps. Note that these steps
+ are roughly similar to those steps used in RFC1113:
+
+ Step 1. Creation of local form.
+
+ The body part to be transmitted is created in the system's
+ native format. The native character set is used, and where
+ appropriate local end of line conventions are used as well.
+ The may be a UNIX-style text file, or a Sun raster image, or
+ a VMS indexed file, or audio data in a system-dependent
+ format stored only in memory, or anything else that
+ corresponds to the local model for the representation of
+ some form of information.
+
+ Step 2. Conversion to canonical form.
+
+ The entire body part, including "out-of-band" information
+ such as record lengths and possibly file attribute
+ information, is converted to a universal canonical form.
+ The specific content type of the body part as well as its
+ associated attributes dictate the nature of the canonical
+ form that is used. Conversion to the proper canonical form
+ may involve character set conversion, transformation of
+ audio data, compression, or various other operations
+ specific to the various content types.
+
+ For example, in the case of text/plain data, the text must
+ be converted to a supported character set and lines must be
+ delimited with CRLF delimiters in accordance with RFC822.
+ Note that the restriction on line lengths implied by RFC822
+ is eliminated if the next step employs either quoted-
+ printable or base64 encoding.
+
+ Step 3. Apply transfer encoding.
+
+ A Content-Transfer-Encoding appropriate for this body part
+ is applied. Note that there is no fixed relationship
+ between the content type and the transfer encoding. In
+ particular, it may be appropriate to base the choice of
+ base64 or quoted-printable on character frequency counts
+ which are specific to a given instance of body part.
+
+
+
+ Borenstein & Freed [Page 73]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Step 4. Insertion into message.
+
+ The encoded object is inserted into a MIME message with
+ appropriate body part headers and boundary markers.
+
+ It is vital to note that these steps are only a model; they
+ are specifically NOT a blueprint for how an actual system
+ would be built. In particular, the model fails to account
+ for two common designs:
+
+ 1. In many cases the conversion to a canonical
+ form prior to encoding will be subsumed into the
+ encoder itself, which understands local formats
+ directly. For example, the local newline
+ convention for text bodyparts might be carried
+ through to the encoder itself along with knowledge
+ of what that format is.
+
+ 2. The output of the encoders may have to pass
+ through one or more additional steps prior to
+ being transmitted as a message. As such, the
+ output of the encoder may not be compliant with
+ the formats specified by RFC822. In particular,
+ once again it may be appropriate for the
+ converter's output to be expressed using local
+ newline conventions rather than using the standard
+ RFC822 CRLF delimiters.
+
+ Other implementation variations are conceivable as well.
+ The only important aspect of this discussion is that the
+ resulting messages are consistent with those produced by the
+ model described here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 74]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ References
+
+ [US-ASCII] Coded Character Set--7-Bit American Standard Code
+ for Information Interchange, ANSI X3.4-1986.
+
+ [ATK] Borenstein, Nathaniel S., Multimedia Applications
+ Development with the Andrew Toolkit, Prentice-Hall, 1990.
+
+ [GIF] Graphics Interchange Format (Version 89a), Compuserve,
+ Inc., Columbus, Ohio, 1990.
+
+ [ISO-2022] International Standard--Information Processing--
+ ISO 7-bit and 8-bit coded character sets--Code extension
+ techniques, ISO 2022:1986.
+
+ [ISO-8859] Information Processing -- 8-bit Single-Byte Coded
+ Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO
+ 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2,
+ 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part
+ 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
+ Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
+ Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
+ Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
+ Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
+ alphabet No. 5, ISO 8859-9, 1990.
+
+ [ISO-646] International Standard--Information Processing--
+ ISO 7-bit coded character set for information interchange,
+ ISO 646:1983.
+
+ [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO
+ IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.
+
+ [ODA] ISO 8613; Information Processing: Text and Office
+ System; Office Document Architecture (ODA) and Interchange
+ Format (ODIF), Part 1-8, 1989.
+
+ [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva,
+ 1972, "Pulse Code Modulation (PCM) of Voice Frequencies".
+
+ [POSTSCRIPT] Adobe Systems, Inc., PostScript Language
+ Reference Manual, Addison-Wesley, 1985.
+
+ [X400] Schicker, Pietro, "Message Handling Systems, X.400",
+ Message Handling Systems and Distributed Applications, E.
+ Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-
+ Holland, 1989, pp. 3-41.
+
+ [RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June,
+ 1981, MIT, RFC-783.
+
+ [RFC-821] Postel, J.B. Simple Mail Transfer Protocol.
+ August, 1982, USC/Information Sciences Institute, RFC-821.
+
+
+
+
+ Borenstein & Freed [Page 75]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ [RFC-822] Crocker, D. Standard for the format of ARPA
+ Internet text messages. August, 1982, UDEL, RFC-822.
+
+ [RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard
+ for message encapsulation. January, 1985, Delaware
+ and NMA, RFC-934.
+
+ [RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer
+ Protocol. October, 1985, USC/Information Sciences
+ Institute, RFC-959.
+
+ [RFC-1049] Sirbu, M.A. Content-Type header field for
+ Internet messages. March, 1988, CMU, RFC-1049.
+
+ [RFC-1113] Linn, J. Privacy enhancement for Internet
+ electronic mail: Part I - message encipherment and
+ authentication procedures. August, 1989, IAB Privacy Task
+ Force, RFC-1113.
+
+ [RFC-1154] Robinson, D.; Ullmann, R. Encoding header field
+ for Internet messages. April, 1990, Prime Computer,
+ Inc., RFC-1154.
+
+ [RFC-1342] Moore, Keith, Representation of Non-Ascii Text in
+ Internet Message Headers. June, 1992, University of
+ Tennessee, RFC-1342.
+
+ Security Considerations
+
+ Security issues are discussed in Section 7.4.2 and in
+ Appendix G. Implementors should pay special attention to
+ the security implications of any mail content-types that can
+ cause the remote execution of any actions in the recipient's
+ environment. In such cases, the discussion of the
+ applicaton/postscript content-type in Section 7.4.2 may
+ serve as a model for considering other content-types with
+ remote execution capabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 76]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Authors' Addresses
+
+ For more information, the authors of this document may be
+ contacted via Internet mail:
+
+ Nathaniel S. Borenstein
+ MRE 2D-296, Bellcore
+ 445 South St.
+ Morristown, NJ 07962-1910
+
+ Phone: +1 201 829 4270
+ Fax: +1 201 829 7019
+ Email: nsb@bellcore.com
+
+
+ Ned Freed
+ Innosoft International, Inc.
+ 250 West First Street
+ Suite 240
+ Claremont, CA 91711
+
+ Phone: +1 714 624 7907
+ Fax: +1 714 621 5319
+ Email: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 77]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+
+
+
+ THIS PAGE INTENTIONALLY LEFT BLANK.
+
+ Please discard this page and place the following table of
+ contents after the title page.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page i]
+
+
+
+
+
+
+
+
+ Table of Contents
+
+
+ 1 Introduction....................................... 1
+ 2 Notations, Conventions, and Generic BNF Grammar.... 3
+ 3 The MIME-Version Header Field...................... 5
+ 4 The Content-Type Header Field...................... 6
+ 5 The Content-Transfer-Encoding Header Field......... 10
+ 5.1 Quoted-Printable Content-Transfer-Encoding......... 14
+ 5.2 Base64 Content-Transfer-Encoding................... 17
+ 6 Additional Optional Content- Header Fields......... 19
+ 6.1 Optional Content-ID Header Field................... 19
+ 6.2 Optional Content-Description Header Field.......... 19
+ 7 The Predefined Content-Type Values................. 20
+ 7.1 The Text Content-Type.............................. 20
+ 7.1.1 The charset parameter.............................. 20
+ 7.1.2 The Text/plain subtype............................. 23
+ 7.1.3 The Text/richtext subtype.......................... 23
+ 7.2 The Multipart Content-Type......................... 29
+ 7.2.1 Multipart: The common syntax...................... 30
+ 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..................... 36
+ 7.3 The Message Content-Type........................... 37
+ 7.3.1 The Message/rfc822 (primary) subtype............... 37
+ 7.3.2 The Message/Partial subtype........................ 37
+ 7.3.3 The Message/External-Body subtype.................. 40
+ 7.4 The Application Content-Type....................... 46
+ 7.4.1 The Application/Octet-Stream (primary) subtype..... 46
+ 7.4.2 The Application/PostScript subtype................. 47
+ 7.4.3 The Application/ODA subtype........................ 50
+ 7.5 The Image Content-Type............................. 51
+ 7.6 The Audio Content-Type............................. 51
+ 7.7 The Video Content-Type............................. 51
+ 7.8 Experimental Content-Type Values................... 51
+ Summary............................................ 53
+ Acknowledgements................................... 54
+ Appendix A -- Minimal MIME-Conformance............. 56
+ Appendix B -- General Guidelines For Sending Email Data59
+ Appendix C -- A Complex Multipart Example.......... 62
+ Appendix D -- A Simple Richtext-to-Text Translator in C64
+ Appendix E -- Collected Grammar.................... 66
+ Appendix F -- IANA Registration Procedures......... 68
+ F.1 Registration of New Content-type/subtype Values..68
+ F.2 Registration of New Character Set Values...... 69
+ F.3 Registration of New Access-type Values for Message/external-body69
+ F.4 Registration of New Conversions Values for Application69
+ Appendix G -- Summary of the Seven Content-types... 71
+ Appendix H -- Canonical Encoding Model............. 73
+ References......................................... 75
+ Security Considerations............................ 76
+ Authors' Addresses................................. 77
+
+
+
+ Borenstein & Freed [Page ii]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page iii]
+