RFC relevance of parameter

As per Relevance of the word parameter, we have this rfc below:

Network Working Group N.
Request for Comments: 2046
Obsoletes: 1521, 1522, 1590 N.
Category: Standards Track First
November 1996

Multipurpose Internet Mail
(MIME) Part Two
Media

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

STD 11, RFC 822 defines a message representation protocol
considerable detail about US-ASCII message headers, but which
the message content, or message body, as flat US-ASCII text.
set of documents, collectively called the Multipurpose Internet
Extensions, or MIME, redefines the format of messages to allow

(1) textual message bodies in character sets other
US-ASCII

(2) an extensible set of different formats for non-
message bodies

(3) multi-part message bodies,

(4) textual header information in character sets other
US-ASCII

These documents are based on earlier work documented in RFC 934,
11, and RFC 1049, but extends and revises them. Because RFC 822
so little about message bodies, these documents are
orthogonal to (rather than a revision of) RFC 822.

The initial document in this set, RFC 2045, specifies the
headers used to describe the structure of MIME messages. This
document defines the general structure of the MIME media
system and defines an initial set of media types. The third document
RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII

Freed & Borenstein Standards Track [Page 1]

RFC 2046 Media Types November 1996

data in Internet mail header fields. The fourth document, RFC 2048,
specifies various IANA registration procedures for MIME-
facilities. The fifth and final document, RFC 2049, describes
conformance criteria as well as providing some illustrative
of MIME message formats, acknowledgements, and the bibliography

These documents are revisions of RFCs 1521 and 1522, which
were revisions of RFCs 1341 and 1342. An appendix in RFC 2049
describes differences and changes from previous versions

Table of

1. Introduction ......................................... 3
2. Definition of a Top-Level Media Type ................. 4
3. Overview Of The Initial Top-Level Media Types ........ 4
4. Discrete Media Type Values ........................... 6
4.1 Text Media Type ..................................... 6
4.1.1 Representation of Line Breaks ..................... 7
4.1.2 Charset Parameter ................................. 7
4.1.3 Plain Subtype ..................................... 11
4.1.4 Unrecognized Subtypes ............................. 11
4.2 Image Media Type .................................... 11
4.3 Audio Media Type .................................... 11
4.4 Video Media Type .................................... 12
4.5 Application Media Type .............................. 12
4.5.1 Octet-Stream Subtype .............................. 13
4.5.2 PostScript Subtype ................................ 14
4.5.3 Other Application Subtypes ........................ 17
5. Composite Media Type Values .......................... 17
5.1 Multipart Media Type ................................ 17
5.1.1 Common Syntax ..................................... 19
5.1.2 Handling Nested Messages and Multiparts ........... 24
5.1.3 Mixed Subtype ..................................... 24
5.1.4 Alternative Subtype ............................... 24
5.1.5 Digest Subtype .................................... 26
5.1.6 Parallel Subtype .................................. 27
5.1.7 Other Multipart Subtypes .......................... 28
5.2 Message Media Type .................................. 28
5.2.1 RFC822 Subtype .................................... 28
5.2.2 Partial Subtype ................................... 29
5.2.2.1 Message Fragmentation and Reassembly ............ 30
5.2.2.2 Fragmentation and Reassembly Example ............ 31
5.2.3 External-Body Subtype ............................. 33
5.2.4 Other Message Subtypes ............................ 40
6. Experimental Media Type Values ....................... 40
7. Summary .............................................. 41
8. Security Considerations .............................. 41
9. Authors' Addresses ................................... 42

Freed & Borenstein Standards Track [Page 2]

RFC 2046 Media Types November 1996

A. Collected Grammar .................................... 43

1.

The first document in this set, RFC 2045, defines a number of
fields, including Content-Type. The Content-Type field is used
specify the nature of the data in the body of a MIME entity,
giving media type and subtype identifiers, and by providing
information that may be required for certain media types. After
type and subtype names, the remainder of the header field is simply
set of parameters, specified in an attribute/value notation.
ordering of parameters is not significant

In general, the top-level media type is used to declare the
type of data, while the subtype specifies a specific format for
type of data. Thus, a media type of "image/xyz" is enough to tell
user agent that the data is an image, even if the user agent has
knowledge of the specific image format "xyz". Such information
be used, for example, to decide whether or not to show a user the
data from an unrecognized subtype -- such an action might
reasonable for unrecognized subtypes of "text", but not
unrecognized subtypes of "image" or "audio". For this reason
registered subtypes of "text", "image", "audio", and "video"
not contain embedded information that is really of a different type
Such compound formats should be represented using the "multipart"
"application" types

Parameters are modifiers of the media subtype, and as such do
fundamentally affect the nature of the content. The set
meaningful parameters depends on the media type and subtype.
parameters are associated with a single specific subtype. However,
given top-level media type may define parameters which are
to any subtype of that type. Parameters may be required by
defining media type or subtype or they may be optional.
implementations must also ignore any parameters whose names they
not recognize

MIME's Content-Type header field and media type mechanism has
carefully designed to be extensible, and it is expected that the
of media type/subtype pairs and their associated parameters will
significantly over time. Several other MIME facilities, such
transfer encodings and "message/external-body" access types,
likely to have new values defined over time. In order to ensure
the set of such values is developed in an orderly, well-specified
and public manner, MIME sets up a registration process which uses
Internet Assigned Numbers Authority (IANA) as a central registry
MIME's various areas of extensibility. The registration process
these areas is described in a companion document, RFC 2048.

Freed & Borenstein Standards Track [Page 3]

RFC 2046 Media Types November 1996

The initial seven standard top-level media type are defined
described in the remainder of this document

2. Definition of a Top-Level Media

The definition of a top-level media type consists of

(1) a name and a description of the type,
criteria for whether a particular type would
under that type

(2) the names and definitions of parameters, if any,
are defined for all subtypes of that type (
whether such parameters are required or optional),

(3) how a user agent and/or gateway should handle
subtypes of this type

(4) general considerations on gatewaying entities of
top-level type, if any,

(5) any restrictions on content-transfer-encodings
entities of this top-level type

3. Overview Of The Initial Top-Level Media

The five discrete top-level media types are

(1) text -- textual information. The subtype "plain"
particular indicates plain text containing
formatting commands or directives of any sort.
text is intended to be displayed "as-is". No
software is required to get the full meaning of
text, aside from support for the indicated
set. Other subtypes are to be used for enriched text
forms where application software may enhance
appearance of the text, but such software must not
required in order to get the general idea of
content. Possible subtypes of "text" thus include
word processor format that can be read
resorting to software that understands the format.
particular, formats that employ embeddded
formatting information are not considered
readable. A very simple and portable subtype
"richtext", was defined in RFC 1341, with a
revision in RFC 1896 under the name "enriched".

Freed & Borenstein Standards Track [Page 4]

RFC 2046 Media Types November 1996

(2) image -- image data. "Image" requires a display
(such as a graphical display, a graphics printer, or
FAX machine) to view the information. An
subtype is defined for the widely-used image
JPEG. . subtypes are defined for two widely-used
formats, jpeg and gif

(3) audio -- audio data. "Audio" requires an audio
device (such as a speaker or a telephone) to "display
the contents. An initial subtype "basic" is defined
this document

(4) video -- video data. "Video" requires the
to display moving images, typically
specialized hardware and software. An initial
"mpeg" is defined in this document

(5) application -- some other kind of data,
either uninterpreted binary data or information to
processed by an application. The subtype "octet
stream" is to be used in the case of
binary data, in which case the simplest
action is to offer to write the information into a
for the user. The "PostScript" subtype is also
for the transport of PostScript material.
expected uses for "application" include spreadsheets
data for mail-based scheduling systems, and
for "active" (computational) messaging, and
processing formats that are not directly readable
Note that security considerations may exist for
types of application data, most
"application/PostScript" and any form of
messaging. These issues are discussed later in
document

The two composite top-level media types are

(1) multipart -- data consisting of multiple entities
independent data types. Four subtypes are
defined, including the basic "mixed" subtype
a generic mixed set of parts, "alternative"
representing the same data in multiple formats
"parallel" for parts intended to be
simultaneously, and "digest" for multipart entities
which each part has a default type of "message/rfc822".

Freed & Borenstein Standards Track [Page 5]

RFC 2046 Media Types November 1996

(2) message -- an encapsulated message. A body of
type "message" is itself all or a portion of some
of message object. Such objects may or may not in
contain other entities. The "rfc822" subtype is
when the encapsulated content is itself an RFC 822
message. The "partial" subtype is defined for
RFC 822 messages, to permit the fragmented
of bodies that are thought to be too large to be
through transport facilities in one piece.
subtype, "external-body", is defined for
large bodies by reference to an external data source

It should be noted that the list of media type values given here
be augmented in time, via the mechanisms described above, and
the set of subtypes is expected to grow substantially

4. Discrete Media Type

Five of the seven initial media type values refer to discrete bodies
The content of these types must be handled by non-MIME mechanisms
they are opaque to MIME processors

4.1. Text Media

The "text" media type is intended for sending material which
principally textual in form. A "charset" parameter may be used
indicate the character set of the body text for "text" subtypes
notably including the subtype "text/plain", which is a
subtype for plain text. Plain text does not provide for or
formatting commands, font attribute specifications,
instructions, interpretation directives, or content markup.
text is seen simply as a linear sequence of characters,
interrupted by line breaks or page breaks. Plain text may allow
stacking of several characters in the same position in the text
Plain text in scripts like Arabic and Hebrew may also
facilitites that allow the arbitrary mixing of text segments
opposite writing directions

Beyond plain text, there are many formats for representing what
be known as "rich text". An interesting characteristic of many
representations is that they are to some extent readable even
the software that interprets them. It is useful, then,
distinguish them, at the highest level, from such unreadable data
images, audio, or text represented in an unreadable form. In
absence of appropriate interpretation software, it is reasonable
show subtypes of "text" to the user, while it is not reasonable to
so with most nontextual data. Such formatted textual data should
represented using subtypes of "text".

Freed & Borenstein Standards Track [Page 6]

RFC 2046 Media Types November 1996

4.1.1. Representation of Line

The canonical form of any MIME "text" subtype MUST always represent
line break as a CRLF sequence. Similarly, any occurrence of CRLF
MIME "text" MUST represent a line break. Use of CR and LF outside
line break sequences is also forbidden

This rule applies regardless of format or character set or
involved

NOTE: The proper interpretation of line breaks when a body
displayed depends on the media type. In particular, while it
appropriate to treat a line break as a transition to a new line
displaying a "text/plain" body, this treatment is actually
for other subtypes of "text" like "text/enriched" [RFC-1896].
Similarly, whether or not line breaks should be added during
operations is also a function of the media type. It should not
necessary to add any line breaks to display "text/plain" correctly
whereas proper display of "text/enriched" requires the
addition of line breaks

NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC
821] allows a maximum of 998 octets before the next CRLF sequence
To be transported by such protocols, data which includes too
segments without CRLF sequences must be encoded with a
content-transfer-encoding

4.1.2. Charset

A critical parameter that may be specified in the Content-Type
for "text/plain" data is the character set. This is specified with
"charset" parameter, as in

Content-type: text/plain; charset=iso-8859-1

Unlike some other parameter values, the values of the
parameter are NOT case sensitive. The default character set,
must be assumed in the absence of a charset parameter, is US-ASCII

The specification for any future subtypes of "text" must
whether or not they will also utilize a "charset" parameter, and
possibly restrict its values as well. For other subtypes of "text
than "text/plain", the semantics of the "charset" parameter should
defined to be identical to those specified here for "text/plain",
i.e., the body consists entirely of characters in the given charset
In particular, definers of future "text" subtypes should pay
attention to the implications of multioctet character sets for
subtype definitions

Freed & Borenstein Standards Track [Page 7]

RFC 2046 Media Types November 1996

The charset parameter for subtypes of "text" gives a name of
character set, as "character set" is defined in RFC 2045. The
regarding line breaks detailed in the previous section must also
observed -- a character set whose definition does not conform
these rules cannot be used in a MIME "text" subtype

An initial list of predefined character set names can be found at
end of this section. Additional character sets may be
with IANA

Other media types than subtypes of "text" might choose to employ
charset parameter as defined here, but with the CRLF/line
restriction removed. Therefore, all character sets that conform
the general definition of "character set" in RFC 2045 can
registered for MIME use

Note that if the specified character set includes 8-bit
and such characters are used in the body, a Content-Transfer-
header field and a corresponding encoding on the data are required
order to transmit the body via some mail transfer protocols, such
SMTP [RFC-821].

The default character set, US-ASCII, has been the subject of
confusion and ambiguity in the past. Not only were there
ambiguities in the definition, there have been wide variations
practice. In order to eliminate such ambiguity and variations in
future, it is strongly recommended that new user agents
specify a character set as a media type parameter in the Content-
header field. "US-ASCII" does not indicate an arbitrary 7-
character set, but specifies that all octets in the body must
interpreted as characters according to the US-ASCII character set
National and application-oriented versions of ISO 646 [ISO-646]
usually NOT identical to US-ASCII, and in that case their use
Internet mail is explicitly discouraged. The omission of the ISO 646
character set from this document is deliberate in this regard.
character set name of "US-ASCII" explicitly refers to the
set defined in ANSI X3.4-1986 [US- ASCII]. The new
reference version (IRV) of the 1991 edition of ISO 646 is
to US-ASCII. The character set name "ASCII" is reserved and must
be used for any purpose

NOTE: RFC 821 explicitly specifies "ASCII", and references an
version of the American Standard. Insofar as one of the purposes
specifying a media type and character set is to permit the
to unambiguously determine how the sender intended the coded
to be interpreted, assuming anything other than "strict ASCII" as
default would risk unintentional and incompatible changes to
semantics of messages now being transmitted. This also implies

Freed & Borenstein Standards Track [Page 8]

RFC 2046 Media Types November 1996

messages containing characters coded according to other versions
ISO 646 than US-ASCII and the 1991 IRV, or using code-
procedures (e.g., those of ISO 2022), as well as 8bit or
octet character encodings MUST use an appropriate character
specification to be consistent with MIME

The complete US-ASCII character set is listed in ANSI X3.4- 1986.
Note that the control characters including DEL (0-31, 127) have
defined meaning in apart from the combination CRLF (US-ASCII
13 and 10) indicating a new line. Two of the characters have
facto meanings in wide use: FF (12) often means "start
text on the beginning of a new page"; and TAB or HT (9) often (
not always) means "move the cursor to the next available column
the current position where the column number is a multiple of 8
(counting the first column as column 0)." Aside from
conventions, any use of the control characters or DEL in a body
either

(1) because a subtype of text other than "plain
specifically assigns some additional meaning,

(2) within the context of a private agreement between
sender and recipient. Such private agreements
discouraged and should be replaced by the
capabilities of this document

NOTE: An enormous proliferation of character sets exist beyond US
ASCII. A large number of partially or totally overlapping
sets is NOT a good thing. A SINGLE character set that can be
universally for representing all of the world's languages in
mail would be preferrable. Unfortunately, existing practice
several communities seems to point to the continued use of
character sets in the near future. A small number of
character sets are, therefore, defined for Internet use in
document

The defined charset values are

(1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].

(2) ISO-8859-X -- where "X" is to be replaced,
necessary, for the parts of ISO-8859 [ISO-8859].
that the ISO 646 character sets have deliberately
omitted in favor of their 8859 replacements, which
the designated character sets for Internet mail. As
the publication of this document, the legitimate
for "X" are the digits 1 through 10.

Freed & Borenstein Standards Track [Page 9]

RFC 2046 Media Types November 1996

Characters in the range 128-159 has no assigned meaning in ISO-8859-
X. Characters with values below 128 in ISO-8859-X have the
assigned meaning as they do in US-ASCII

Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/
alphabet) includes both characters for which the normal
direction is right to left and characters for which it is left
right, but do not define a canonical ordering method for
bi-directional text. The charset values "ISO-8859-6" and "ISO-8859-
8", however, specify that the visual method is used [RFC-1556].

All of these character sets are used as pure 7bit or 8bit
without any shift or escape functions. The meaning of shift
escape sequences in these character sets is not defined

The character sets specified above are the ones that were
uncontroversial during the drafting of MIME. This document does
endorse the use of any particular character set other than US-ASCII
and recognizes that the future evolution of world character
remains unclear

Note that the character set used, if anything other than US- ASCII
must always be explicitly specified in the Content-Type field

No character set name other than those defined above may be used
Internet mail without the publication of a formal specification
its registration with IANA, or by private agreement, in which
the character set name must begin with "X-".

Implementors are discouraged from defining new character sets
absolutely necessary

The "charset" parameter has been defined primarily for the purpose
textual data, and is described in this section for that reason
However, it is conceivable that non-textual data might also wish
specify a charset value for some purpose, in which case the
syntax and values should be used

In general, composition software should always use the "lowest
denominator" character set possible. For example, if a body
only US-ASCII characters, it 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,
should be labelled as being in that subset. This will increase
chances that the recipient will be able to view the resulting
correctly

Freed & Borenstein Standards Track [Page 10]

RFC 2046 Media Types November 1996

4.1.3. Plain

The simplest and most important subtype of "text" is "plain".
indicates plain text that does not contain any formatting commands
directives. Plain text is intended to be displayed "as-is", that is
no interpretation of embedded formatting commands, font
specifications, processing instructions, interpretation directives
or content markup should be necessary for proper display.
default media type of "text/plain; charset=us-ascii" for
mail describes existing Internet practice. That is, it is the
of body defined by RFC 822.

No other "text" subtype is defined by this document

4.1.4. Unrecognized

Unrecognized subtypes of "text" should be treated as subtype "plain
as long as the MIME implementation knows how to handle the charset
Unrecognized subtypes which also specify an unrecognized
should be treated as "application/octet- stream".

4.2. Image Media

A media type of "image" indicates that the body contains an image
The subtype names the specific image format. These names are
case sensitive. An initial subtype is "jpeg" for the JPEG
using JFIF encoding [JPEG].

The list of "image" subtypes given here is neither exclusive
exhaustive, and is expected to grow as more types are registered
IANA, as described in RFC 2048.

Unrecognized subtypes of "image" should at a miniumum be treated
"application/octet-stream". Implementations may optionally elect
pass subtypes of "image" that they do not specifically recognize to
secure and robust general-purpose image viewing application, if
an application is available

NOTE: Using of a generic-purpose image viewing application this
inherits the security problems of the most dangerous type
by the application

4.3. Audio Media

A media type of "audio" indicates that the body contains audio data
Although there is not yet a consensus on an "ideal" audio format
use with computers, there is a pressing need for a format capable
providing interoperable behavior

Freed & Borenstein Standards Track [Page 11]

RFC 2046 Media Types November 1996

The initial subtype of "basic" is specified to meet this
by providing an absolutely minimal lowest common denominator
format. It is expected that richer formats for higher quality and/
lower bandwidth audio will be defined by a later document

The content of the "audio/basic" subtype is single channel
encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz

Unrecognized subtypes of "audio" should at a miniumum be treated
"application/octet-stream". Implementations may optionally elect
pass subtypes of "audio" that they do not specifically recognize to
robust general-purpose audio playing application, if such
application is available

4.4. Video Media

A media type of "video" indicates that the body contains a time
varying-picture image, possibly with color and coordinated sound
The term 'video' is used in its most generic sense, rather than
reference to any particular technology or format, and is not meant
preclude subtypes such as animated drawings encoded compactly.
subtype "mpeg" refers to video coded according to the MPEG
[MPEG].

Note that although in general this document strongly discourages
mixing of multiple media in a single body, it is recognized that
so-called video formats include a representation for
audio, and this is explicitly permitted for subtypes of "video".

Unrecognized subtypes of "video" should at a minumum be treated
"application/octet-stream". Implementations may optionally elect
pass subtypes of "video" that they do not specifically recognize to
robust general-purpose video display application, if such
application is available

4.5. Application Media

The "application" media type is to be used for discrete data which
not fit in any of the other categories, and particularly for data
be processed by some type of application program. This
information which must be processed by an application before it
viewable or usable by a user. Expected uses for the "application
media type include file transfer, spreadsheets, data for mail-
scheduling systems, and languages for "active" (computational
material. (The latter, in particular, can pose security
which must be understood by implementors, and are considered
detail in the discussion of the "application/PostScript" media type.)

Freed & Borenstein Standards Track [Page 12]

RFC 2046 Media Types November 1996

For example, a meeting scheduler might define a
representation for information about proposed meeting dates.
intelligent user agent would use this information to conduct a
with the user, and might then send additional material based on
dialog. More generally, there have been several "active"
languages developed in which programs in a suitably
language are transported to a remote location and automatically
in the recipient's environment

Such applications may be defined as subtypes of the "application
media type. This document defines two subtypes

octet-stream, and PostScript

The subtype of "application" will often be either the name or
part of the name of the application for which the data are intended
This does not mean, however, that any application program name may
used freely as a subtype of "application".

4.5.1. Octet-Stream

The "octet-stream" subtype is used to indicate that a body
arbitrary binary data. The set of currently defined parameters is

(1) TYPE -- the general type or category of binary data
This is intended as information for the human
rather than for any automatic processing

(2) PADDING -- the number of bits of padding that
appended to the bit-stream comprising the
contents to produce the enclosed 8bit byte-
data. This is useful for enclosing a bit-stream in
body when the total number of bits is not a multiple
8.

Both of these parameters are optional

An additional parameter, "CONVERSIONS", was defined in RFC 1341
has since been removed. RFC 1341 also defined the use of a "NAME
parameter which gave a suggested file name to be used if the
were to be written to a file. This has been deprecated
anticipation of a separate Content-Disposition header field, to
defined in a subsequent RFC

The recommended action for an implementation that receives
"application/octet-stream" entity is to simply offer to put the
in a file, with any Content-Transfer-Encoding undone, or perhaps
use it as input to a user-specified process

Freed & Borenstein Standards Track [Page 13]

RFC 2046 Media Types November 1996

To reduce the danger of transmitting rogue programs, it is
recommended that implementations NOT implement a path-
mechanism whereby an arbitrary program named in the Content-
parameter (e.g., an "interpreter=" parameter) is found and
using the message body as input

4.5.2. PostScript

A media type of "application/postscript" indicates a
program. Currently two variants of the PostScript language
allowed; the original level 1 variant is described in [POSTSCRIPT
and the more recent level 2 variant is described in [POSTSCRIPT2].

PostScript is a registered trademark of Adobe Systems, Inc. Use
the MIME media type "application/postscript" implies recognition
that trademark and all the rights it entails

The PostScript language definition provides facilities for
labelling of the specific language features a given program uses
This labelling, called the PostScript document
conventions, or DSC, is very general and provides substantially
information than just the language level. The use of
structuring conventions, while not required, is strongly
as an aid to interoperability. Documents which lack
structuring conventions cannot be tested to see whether or not
will work in a given environment. As such, some systems may
the worst and refuse to process unstructured documents

The execution of general-purpose PostScript interpreters
serious security risks, and implementors are discouraged from
sending PostScript bodies to "off- the-shelf" interpreters. While
is usually safe to send PostScript to a printer, where the
for harm is greatly constrained by typical printer environments
implementors should consider all of the following before they
interactive display of PostScript bodies to their MIME readers

The remainder of this section outlines some, though probably not all
of the possible problems with the transport of PostScript entities

(1) Dangerous operations in the PostScript
include, but may not be limited to, the
operators "deletefile", "renamefile", "filenameforall",
and "file". "File" is only dangerous when applied
something other than standard input or output
Implementations may also define additional
file operators; these may also pose a threat
security. "Filenameforall", the wildcard file
operator, may appear at first glance to be harmless

Freed & Borenstein Standards Track [Page 14]

RFC 2046 Media Types November 1996

Note, however, that this operator has the potential
reveal information about what files the recipient
access to, and this information may itself
sensitive. Message senders should avoid the use
potentially dangerous file operators, since
operators are quite likely to be unavailable in
PostScript implementations. Message receiving
displaying software should either completely
all potentially dangerous file operators or
special care not to delegate any special authority
their operation. These operators should be viewed
being done by an outside agency when
PostScript documents. Such disabling and/or
should be done completely outside of the reach of
PostScript language itself; care should be taken
insure that no method exists for re-enabling full
function versions of these operators

(2) The PostScript language provides facilities for
the normal interpreter, or server, loop. Changes
in this "outer" environment are customarily
across documents, and may in some cases be
semipermanently in nonvolatile memory. The
associated with exiting the interpreter loop have
potential to interfere with subsequent
processing. As such, their unrestrained
constitutes a threat of service denial.
operators that exit the interpreter loop include,
may not be limited to, the exitserver and
operators. Message sending software should
generate PostScript that depends on exiting
interpreter loop to operate, since the ability to
will probably be unavailable in secure
implementations. Message receiving and
software should completely disable the ability to
retained changes to the PostScript environment
eliminating or disabling the "startjob"
"exitserver" operations. If these operations cannot
eliminated or completely disabled the
associated with them should at least be set to a hard
to-guess value

(3) PostScript provides operators for setting system-
and device-specific parameters. These
settings may be retained across jobs and
potentially pose a threat to the correct operation
the interpreter. The PostScript operators that
system and device parameters include, but may not

Freed & Borenstein Standards Track [Page 15]

RFC 2046 Media Types November 1996

limited to, the "setsystemparams" and "setdevparams
operators. Message sending software should
generate PostScript that depends on the setting
system or device parameters to operate correctly.
ability to set these parameters will probably
unavailable in secure PostScript implementations
Message receiving and displaying software
disable the ability to change system and
parameters. If these operators cannot be
disabled the password associated with them should
least be set to a hard-to-guess value

(4) Some PostScript implementations provide
facilities for the direct loading and execution
machine code. Such facilities are quite obviously
to substantial abuse. Message sending software
not make use of such features. Besides being
hardware-specific, they are also likely to
unavailable in secure implementations of PostScript
Message receiving and displaying software should
allow such operators to be used if they exist

(5) PostScript is an extensible language, and many, if
most, implementations of it provide a number of
own extensions. This document does not deal with
extensions explicitly since they constitute an
factor. Message sending software should not make
of nonstandard extensions; they are likely to
missing from some implementations. Message
and displaying software should make sure that
nonstandard PostScript operators are secure and don'
present any kind of threat

(6) It is possible to write PostScript that consumes
amounts of various system resources. It is
possible to write PostScript programs that
indefinitely. Both types of programs have
potential to cause damage if sent to
recipients. Message-sending software should avoid
construction and dissemination of such programs,
is antisocial. Message receiving and
software should provide appropriate mechanisms to
processing after a reasonable amount of time
elapsed. In addition, PostScript interpreters should
limited to the consumption of only a reasonable
of any given system resource

Freed & Borenstein Standards Track [Page 16]

RFC 2046 Media Types November 1996

(7) It is possible to include raw binary information
PostScript in various forms. This is not
for use in Internet mail, both because it is
supported by all PostScript interpreters and because
significantly complicates the use of a MIME Content
Transfer-Encoding. (Without such binary,
may typically be viewed as line-oriented data.
treatment of CRLF sequences becomes
problematic if binary and line-oriented data are
in a single Postscript data stream.)

(8) Finally, bugs may exist in some PostScript
which could possibly be exploited to gain
access to a recipient's system. Apart from noting
possibility, there is no specific action to take
prevent this, apart from the timely correction of
bugs if any are found

4.5.3. Other Application

It is expected that many other subtypes of "application" will
defined in the future. MIME implementations must at a minimum
any unrecognized subtypes as being equivalent to "application/octet
stream".

5. Composite Media Type

The remaining two of the seven initial Content-Type values refer
composite entities. Composite entities are handled using
mechanisms -- a MIME processor typically handles the body directly

5.1. Multipart Media

In the case of multipart entities, in which one or more
sets of data are combined in a single body, a "multipart" media
field must appear in the entity's header. The body must then
one or more body parts, each preceded by a boundary delimiter line
and the last one followed by a closing boundary delimiter line
After its boundary delimiter line, each body part then consists of
header area, a blank line, and a body area. Thus a body part
similar to an RFC 822 message in syntax, but different in meaning

A body part is an entity and hence is NOT to be interpreted
actually being an RFC 822 message. To begin with, NO header
are actually required in body parts. A body part that starts with
blank line, therefore, is allowed and is a body part for which
default values are to be assumed. In such a case, the absence of
Content-Type header usually indicates that the corresponding body

Freed & Borenstein Standards Track [Page 17]

RFC 2046 Media Types November 1996

a content-type of "text/plain; charset=US-ASCII".

The only header fields that have defined meaning for body parts
those the names of which begin with "Content-". All other
fields may be ignored in body parts. Although they should
be retained if at all possible, they may be discarded by gateways
necessary. Such other fields are permitted to appear in body
but must not be depended on. "X-" fields may be created
experimental or private purposes, with the recognition that
information they contain may be lost at some gateways

NOTE: The distinction between an RFC 822 message and a body part
subtle, but important. A gateway between Internet and X.400 mail
for example, must be able to tell the difference between a body
that contains an image and a body part that contains an
message, the body of which is a JPEG image. In order to
the latter, the body part must have "Content-Type: message/rfc822",
and its body (after the blank line) must be the encapsulated message
with its own "Content-Type: image/jpeg" header field. The use
similar syntax facilitates the conversion of messages to body parts
and vice versa, but the distinction between the two must
understood by implementors. (For the special case in which
actually are messages, a "digest" subtype is also defined.)

As stated previously, each body part is preceded by a
delimiter line that contains the boundary delimiter. The
delimiter MUST NOT appear inside any of the encapsulated parts, on
line by itself or as the prefix of any line. This implies that it
crucial that the composing agent be able to choose and specify
unique boundary parameter value that does not contain the
parameter value of an enclosing multipart as a prefix

All present and future subtypes of the "multipart" type must use
identical syntax. Subtypes may differ in their semantics, and
impose additional restrictions on syntax, but must conform to
required syntax for the "multipart" type. This requirement
that all conformant user agents will at least be able to
and separate the parts of any multipart entity, even those of
unrecognized subtype

As stated in the definition of the Content-Transfer-Encoding
[RFC 2045], no encoding other than "7bit", "8bit", or "binary"
permitted for entities of type "multipart". The "multipart"
delimiters and header fields are always represented as 7bit US-
in any case (though the header fields may encode non-US-ASCII
text as per RFC 2047) and data within the body parts can be
on a part-by-part basis, with Content-Transfer-Encoding fields
each appropriate body part

Freed & Borenstein Standards Track [Page 18]

RFC 2046 Media Types November 1996

5.1.1. Common

This section defines a common syntax for subtypes of "multipart".
All subtypes of "multipart" must use this syntax. A simple
of a multipart message also appears in this section. An example of
more complex multipart message is given in RFC 2049.

The Content-Type field for multipart entities requires one parameter
"boundary". The boundary delimiter line is then defined as a
consisting entirely of two hyphen characters ("-", decimal value 45)
followed by the boundary parameter value from the Content-Type
field, optional linear whitespace, and a terminating CRLF

NOTE: The hyphens are for rough compatibility with the earlier
934 method of message encapsulation, and for ease of searching
the boundaries in some implementations. However, it should be
that multipart messages are NOT completely compatible with RFC 934
encapsulations; in particular, they do not obey RFC 934
conventions for embedded lines that begin with hyphens.
mechanism was chosen over the RFC 934 mechanism because the
causes lines to grow with each level of quoting. The combination
this growth with the fact that SMTP implementations sometimes
long lines made the RFC 934 mechanism unsuitable for use in the
that deeply-nested multipart structuring is ever desired

WARNING TO IMPLEMENTORS: The grammar for parameters on the Content
type field is such that it is often necessary to enclose the
parameter values in quotes on the Content-type line. This is
always necessary, but never hurts. Implementors should be sure
study the grammar carefully in order to avoid producing
Content-type fields. Thus, a typical "multipart" Content-Type
field might look like this

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0

But the following is not valid

Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0

(because of the colon) and must instead be represented

Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p

This Content-Type value indicates that the content consists of one
more parts, each with a structure that is syntactically identical
an RFC 822 message, except that the header area is allowed to
completely empty, and that the parts are each preceded by the

Freed & Borenstein Standards Track [Page 19]

RFC 2046 Media Types November 1996

--gc0pJq0M:08jU534c0

The boundary delimiter MUST occur at the beginning of a line, i.e.,
following a CRLF, and the initial CRLF is considered to be
to the boundary delimiter line rather than part of the
part. The boundary may be followed by zero or more characters
linear whitespace. It is then terminated by either another CRLF
the header fields for the next part, or by two CRLFs, in which
there are no header fields for the next part. If no Content-
field is present it is assumed to be "message/rfc822" in
"multipart/digest" and "text/plain" otherwise

NOTE: The CRLF preceding the boundary delimiter line is
attached to the boundary so that it is possible to have a part
does not end with a CRLF (line break). Body parts that must
considered to end with line breaks, therefore, must have two
preceding the boundary delimiter line, the first of which is part
the preceding body part, and the second of which is part of
encapsulation boundary

Boundary delimiters must not appear within the encapsulated material
and must be no longer than 70 characters, not counting the
leading hyphens

The boundary delimiter line following the last body part is
distinguished delimiter that indicates that no further body
will follow. Such a delimiter line is identical to the
delimiter lines, with the addition of two more hyphens after
boundary parameter value

--gc0pJq0M:08jU534c0p--

NOTE TO IMPLEMENTORS: Boundary string comparisons must compare
boundary value with the beginning of each candidate line. An
match of the entire candidate line is not required; it is
that the boundary appear in its entirety following the CRLF

There appears to be room for additional information prior to
first boundary delimiter line and following the final
delimiter line. These areas should generally be left blank,
implementations must ignore anything that appears before the
boundary delimiter line or after the last one

NOTE: These "preamble" and "epilogue" areas are generally not
because of the lack of proper typing of these parts and the lack
clear semantics for handling these areas at gateways,
X.400 gateways. However, rather than leaving the preamble
blank, many MIME implementations have found this to be a

Freed & Borenstein Standards Track [Page 20]

RFC 2046 Media Types November 1996

place to insert an explanatory note for recipients who read
message with pre-MIME software, since such notes will be ignored
MIME-compliant software

NOTE: Because boundary delimiters must not appear in the body
being encapsulated, a user agent must exercise care to choose
unique boundary parameter value. The boundary parameter value in
example above could have been the result of an algorithm designed
produce boundary delimiters with a very low probability of
existing in the data to be encapsulated without having to prescan
data. Alternate algorithms might result in more "readable"
delimiters for a recipient with an old user agent, but would
more attention to the possibility that the boundary delimiter
appear at the beginning of some line in the encapsulated part.
simplest boundary delimiter line possible is something like "---",
with a closing boundary delimiter line of "-----".

As a very simple example, the following multipart message has
parts, both of them plain text, one of them explicitly typed and
of them implicitly typed

From: Nathaniel Borenstein To: Ned Freed Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST
Subject: Sample
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary

This is the preamble. It is to be ignored, though
is a handy place for composition agents to include
explanatory note to non-MIME conformant readers

--simple

This is implicitly typed plain US-ASCII text
It does NOT end with a linebreak
--simple
Content-type: text/plain; charset=us-

This is explicitly typed plain US-ASCII text
It DOES end with a linebreak

--simple boundary--

This is the epilogue. It is also to be ignored

Freed & Borenstein Standards Track [Page 21]

RFC 2046 Media Types November 1996

The use of a media type of "multipart" in a body part within
"multipart" entity is explicitly allowed. In such cases, for
reasons, care must be taken to ensure that each nested "multipart
entity uses a different boundary delimiter. See RFC 2049 for
example of nested "multipart" entities

The use of the "multipart" media type with only a single body
may be useful in certain contexts, and is explicitly permitted

NOTE: Experience has shown that a "multipart" media type with
single body part is useful for sending non-text media types. It
the advantage of providing the preamble as a place to
decoding instructions. In addition, a number of SMTP gateways
or remove the MIME headers, and a clever MIME decoder can take a
guess at multipart boundaries even in the absence of the Content-
header and thereby successfully decode the message

The only mandatory global parameter for the "multipart" media type
the boundary parameter, which consists of 1 to 70 characters from
set of characters known to be very robust through mail gateways,
NOT ending with white space. (If a boundary delimiter line appears
end with white space, the white space must be presumed to have
added by a gateway, and must be deleted.) It is formally
by the following BNF

boundary := 0*69

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"

Overall, the body of a "multipart" entity may be specified
follows

dash-boundary := "--"
; boundary taken from the value
; boundary parameter of
; Content-Type field

multipart-body := [preamble CRLF
dash-boundary transport-padding
body-part *
close-delimiter transport-
[CRLF epilogue

Freed & Borenstein Standards Track [Page 22]

RFC 2046 Media Types November 1996

transport-padding := *LWSP-
; Composers MUST NOT
; non-zero length
; padding, but receivers
; be able to handle
; added by message transports

encapsulation := delimiter transport-
CRLF body-

delimiter := CRLF dash-

close-delimiter := delimiter "--"

preamble := discard-

epilogue := discard-

discard-text := *(*text CRLF) *
; May be ignored or discarded

body-part := MIME-part-headers [CRLF *OCTET
; Lines in a body-part must not
; with the specified dash-boundary
; the delimiter must not appear
; in the body part. Note that
; semantics of a body-part differ
; the semantics of a message,
; described in the text

OCTET :=
IMPORTANT: The free insertion of linear-white-space and RFC 822
comments between the elements shown in this BNF is NOT allowed
this BNF does not specify a structured header field

NOTE: In certain transport enclaves, RFC 822 restrictions such
the one that limits bodies to printable US-ASCII characters may
be in force. (That is, the transport domains may exist that
standard Internet mail transport as specified in RFC 821 and
by RFC 822, but without certain restrictions.) The relaxation
these restrictions should be construed as locally extending
definition of bodies, for example to include octets outside of
US-ASCII range, as long as these extensions are supported by
transport and adequately documented in the Content- Transfer-
header field. However, in no event are headers (either
headers or body part headers) allowed to contain anything other
US-ASCII characters

Freed & Borenstein Standards Track [Page 23]

RFC 2046 Media Types November 1996

NOTE: Conspicuously missing from the "multipart" type is a notion
structured, related body parts. It is recommended that those
to provide more structured or integrated multipart
facilities should define subtypes of multipart that are
identical but define relationships between the various parts.
example, subtypes of multipart could be defined that include
distinguished part which in turn is used to specify the
between the other parts, probably referring to them by
Content-ID field. Old implementations will not recognize the
subtype if this approach is used, but will treat it
multipart/mixed and will thus be able to show the user the parts
are recognized

5.1.2. Handling Nested Messages and

The "message/rfc822" subtype defined in a subsequent section of
document has no terminating condition other than running out of data
Similarly, an improperly truncated "multipart" entity may not
any terminating boundary marker, and can turn up operationally due
mail system malfunctions

It is essential that such entities be handled correctly when they
themselves imbedded inside of another "multipart" structure.
implementations are therefore required to recognize outer
boundary markers at ANY level of inner nesting. It is not
to only check for the next expected marker or other
condition

5.1.3. Mixed

The "mixed" subtype of "multipart" is intended for use when the
parts are independent and need to be bundled in a particular order
Any "multipart" subtypes that an implementation does not
must be treated as being of subtype "mixed".

5.1.4. Alternative

The "multipart/alternative" type is syntactically identical
"multipart/mixed", but the semantics are different. In particular
each of the body parts is an "alternative" version of the
information

Systems should recognize that the content of the various parts
interchangeable. Systems should choose the "best" type based on
local environment and references, in some cases even through
interaction. As with "multipart/mixed", the order of body parts
significant. In this case, the alternatives appear in an order
increasing faithfulness to the original content. In general,

Freed & Borenstein Standards Track [Page 24]

RFC 2046 Media Types November 1996

best choice is the LAST part of a type supported by the
system's local environment

"Multipart/alternative" may be used, for example, to send a
in a fancy text format in such a way that it can easily be
anywhere

From: Nathaniel Borenstein To: Ned Freed Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST
Subject: Formatted text
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42

--boundary42
Content-Type: text/plain; charset=us-

... plain text version of message goes here ...

--boundary42
Content-Type: text/

... RFC 1896 text/enriched version of same
goes here ...

--boundary42
Content-Type: application/x-

... fanciest version of same message goes here ...

--boundary42--

In this example, users whose mail systems understood
"application/x-whatever" format would see only the fancy version
while other users would see only the enriched or plain text version
depending on the capabilities of their system

In general, user agents that compose "multipart/alternative"
must place the body parts in increasing order of preference, that is
with the preferred format last. For fancy text, the sending
agent should put the plainest format first and the richest
last. Receiving user agents should pick and display the last
they are capable of displaying. In the case where one of
alternatives is itself of type "multipart" and contains
sub-parts, the user agent may choose either to show that alternative
an earlier alternative, or both

Freed & Borenstein Standards Track [Page 25]

RFC 2046 Media Types November 1996

NOTE: From an implementor's perspective, it might seem more
to reverse this ordering, and have the plainest alternative last
However, placing the plainest alternative first is the
possible option when "multipart/alternative" entities are
using a non-MIME-conformant viewer. While this approach does
some burden on conformant MIME viewers, interoperability with
mail readers was deemed to be m