Description:

RFC 2045, page 1:

RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for:

1. textual message bodies in character sets other than US-ASCII
2. an extensible set of different formats for non-textual message bodies
3. multi-part message bodies, and
4. textual header information in character sets other than US-ASCII.

RFC 2046, pages 3 - 6:

In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data.

The five discrete top-level media types are:

1. text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other 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 of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched".
2. image -- image data. "Image" requires a display device (such as a graphical display, a graphics printer, or a FAX machine) to view the information. An initial subtype is defined for the widely-used image format JPEG. Subtypes are defined for two widely-used image formats, jpeg and gif.
3. audio -- audio data. "Audio" requires an audio output device (such as a speaker or a telephone) to "display" the contents.
4. video -- video data. "Video" requires the capability to display moving images, typically including specialized hardware and software.
5. application -- some other kind of data, typically either uninterpreted binary data or information to be processed by an application. The 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. The "PostScript" subtype is also defined for the transport of PostScript material. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) messaging, and word processing formats that are not directly readable. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging.

The two composite top-level media types are:

1. multipart -- data consisting of multiple entities of independent data types. Four subtypes are initially defined, including the basic "mixed" subtype specifying a generic mixed set of parts, "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 has a default type of "message
2. message -- an encapsulated message. A body of media type "message" is itself all or a portion of some kind of message object. Such objects may or may not in turn contain other entities. The "rfc822" subtype is used when the encapsulated content is itself an RFC 822 message. The "partial" subtype is defined for partial RFC 822 messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through transport facilities in one piece. Another subtype, "external-body", is defined for specifying large bodies by reference to an external data source.

RFC 2047, page 3:

Certain sequences of "ordinary" printable ASCII characters (known as "encoded-words") are reserved for use as encoded data. The syntax of encoded-words is such that they are unlikely to "accidentally" appear as normal text in message headers. Furthermore, the characters used in encoded-words are restricted to those which do not have special meanings in the context in which the encoded-word appears.

Generally, an "encoded-word" is a sequence of printable ASCII characters that begins with "=?", ends with "?=", and has two "?"s in between. It specifies a character set and an encoding method, and also includes the original text encoded as graphic ASCII characters, according to the rules for that encoding method.

MIME header fields.

MIME-Version. Header field.
Identifies the MIME version to be used.

Syntax:

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Content-Duration. Header field.
This field specifies the time duration of the content in seconds as a 32 bit unsigned integer.

Syntax:

duration := "Content-Duration" ":" 1*10DIGIT

Content-Type. Header field.
(RFC 2045) This field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation. The ordering of parameters is not significant. In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media 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 text, image, audio, and video should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types. Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining content type or subtype or they may be optional. MIME implementations must ignore any parameters whose names they do not recognize. For example, the "charset" parameter is applicable to any subtype of "text", while the "boundary" parameter is required for any subtype of the "multipart" media type. An initial set of seven top-level media types is defined in RFC 2046. Five of these are discrete types whose content is essentially opaque as far as MIME processing is concerned. The remaining two are composite types whose contents require additional handling by MIME.

Syntax:

content := "Content-Type" ":" type "/" subtype *(";" parameter)

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <An extension token defined by a standards-track RFC and registered with IANA.>

x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := <A publicly-defined extension token. Tokens of this form must be registered with IANA as specified in RFC 2048.>

parameter := attribute "=" value

attribute := token ; Matching of attributes ; is ALWAYS case-insensitive.

value := token / quoted-string

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>

tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values

Application. Type.
This media type is to be used for discrete data which does not fit in any of the other categories, and particularly for data to be processed by some type of application program. This is information which must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" media type include file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) material.

Audio. Type.
The body contains audio data.

Image. Media type.
(RFC 2046) A media type of "image" indicates that the body contains an image. The subtype names the specific image format. These names are not case sensitive. An initial subtype is "jpeg" for the JPEG format using JFIF encoding. The list of "image" subtypes given here is neither exclusive nor exhaustive, and is expected to grow as more types are registered with IANA.

Message. Media type.
(RFC 2046) It is frequently desirable, in sending mail, to encapsulate another mail message. A special media type, "message", is defined to facilitate this. In particular, the "rfc822" subtype of "message" is used to encapsulate RFC 822 messages.

Model. Media type.

Multipart. Media type.
(RFC 2046) In the case of multipart entities, in which one or more different sets of data are combined in a single body, a "multipart" media type field must appear in the entity's header. The body must then contain 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 a 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.

Text. Media type.
This media type is intended for sending material which is principally textual in form. A "charset" parameter may be used to indicate the character set of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text. Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text may allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the arbitrary mixing of text segments with opposite writing directions. Beyond plain text, there are many formats for representing what might be known as "rich text". 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".

Video. Media type.
This media type 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 with reference to any particular technology or format, and is not meant to preclude subtypes such as animated drawings encoded compactly. 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".

Content-Description. Header field.
(RFC 2045) 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. This header field is always optional. The description is presumed to be given in the US-ASCII character set, although the mechanism specified in RFC 2047 may be used for non-US-ASCII Content-Description values.

Syntax:

description := "Content-Description" ":" *text

Content-Disposition. Header field.
An optional header field that can be used to convey presentational information.

Syntax:

disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm)

disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive.

disposition-parm := filename-parm / creation-date-parm / modification-date-parm / read-date-parm / size-parm / parameter

filename-parm := "filename" "=" value

creation-date-parm := "creation-date" "=" quoted-date-time

modification-date-parm := "modification-date" "=" quoted-date-time

read-date-parm := "read-date" "=" quoted-date-time

size-parm := "size" "=" 1*DIGIT

quoted-date-time := quoted-string ; contents MUST be an RFC 822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used.

Content-features. Header field.
(RFC 2912) This header provides additional information about the message content directly contained or indirectly referenced in the corresponding MIME message part.

Syntax:

optional-field =/ "Content-features" ":" Feature-expr
Feature-expr = filter

Content-ID. Header field.
(RFC 2045) In constructing a high-level user agent, it may be desirable to allow one body to make reference to another. Accordingly, bodies may be labelled using the "Content-ID" header field, which is syntactically identical to the "Message-ID" header field. The Content-ID value may be used for uniquely identifying MIME entities in several contexts, particularly for caching data referenced by the message/external-body mechanism. Although the Content-ID header is generally optional, its use is MANDATORY in implementations which generate data of the optional MIME media type "message/external-body". That is, each message/external-body entity must have a Content-ID field to permit caching of such data. It is also worth noting that the Content-ID value has special semantics in the case of the multipart/alternative media type. This is explained in the section of RFC 2046 dealing with multipart/alternative.

Syntax:

id := "Content-ID" ":" msg-id

Content-MD5. Header field.
An optional header field which may be used to verify that the decoded data are the same data that were initially sent. This header may also be placed in the encapsulated headers of an object of type message/external-body, to be used to verify that the retreived and decoded data are the same data that were initially referenced.

Content-Transfer-Encoding. Header field.
Describes how the data contents in a message are encoded for transmission.

(RFC 2045) Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator. It is necessary, therefore, to define a standard mechanism for encoding such data into a 7bit short line format. Proper labelling of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. The Content-Transfer-Encoding field's value is a single token specifying the type of encoding, as enumerated below. Formally:

Syntax:

encoding := "Content-Transfer-Encoding" ":" mechanism

mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token

Message-Context. Header field.
This header provides information about the context and presentation characteristics of a message. A receiving user agent may use this information as a hint to optimally present the message.

Glossary:

Character Sets.
(RFC 2047) The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text. A 'charset' can be any of the character set names allowed in an MIME "charset" parameter of a "text/plain" body part, or any character set name registered with IANA for use with the MIME text/plain content-type. Some character sets use code-switching techniques to switch between "ASCII mode" and other modes. If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'. (This rule applies separately to each 'encoded-word', including adjacent 'encoded-word's within a single header field.) When there is a possibility of using more than one character set to represent the text in an 'encoded-word', and in the absence of private agreements between sender and recipients of a message, it is recommended that members of the ISO-8859-* series be used in preference to other character sets.

RFCs:

[RFC 934] Proposed Standard for Message Encapsulation.

[RFC 1036] Standard for Interchange of USENET Messages.

• Obsoletes: RFC 850.

[RFC 1049] A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES.

[RFC 1123] Requirements for Internet Hosts -- Application and Support.

[RFC 1154] Encoding Header Field for Internet Messages.

[RFC 1343] A User Agent Configuration Mechanism For Multimedia Mail Format Information.

[RFC 1344] Implications of MIME for Internet Mail Gateways.

[RFC 1428] Transition of Internet Mail from Just-Send-8 to 8 bit-SMTP/MIME.

[RFC 1524] A User Agent Configuration Mechanism For Multimedia Mail Format Information.

[RFC 1528] Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures.

• Defines MIME media subtypes application/remote-printing and image/tiff.
• Obsoletes: RFC 1486.

[RFC 1554] ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP.

[RFC 1555] Hebrew Character Encoding for Internet Messages.

[RFC 1556] Handling of Bi-directional Texts in MIME.

[RFC 1557] Korean Character Encoding for Internet Messages.

[RFC 1740] MIME Encapsulation of Macintosh files - MacMIME.

• Defines MIME media subtypes application/applefile and multipart/appledouble.

[RFC 1741] MIME Content Type for BinHex Encoded Files.

[RFC 1767] MIME Encapsulation of EDI Objects.

• Defines MIME media subtypes application/EDIFACT, application/EDI-Consent and application/EDI-X12.

[RFC 1806] Communicating Presentation Information in Internet Messages: The Content-Disposition Header.

[RFC 1844] Multimedia E-mail (MIME) User Agent checklist.

• Obsoletes: RFC 1820.

[RFC 1847] Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.

[RFC 1848] MIME Object Security Services.

[RFC 1864] The Content-MD5 Header Field.

• Defines MIME content header field Content-MD5.
• Obsoletes: RFC 1544.

[RFC 1873] Message/External-Body Content-ID Access Type.

[RFC 1874] SGML Media Types.

[RFC 1895] The Application/CALS-1840 Content-type.

• Defines MIME media subtype application/CALS-1840.

[RFC 1896] The text/enriched MIME Content-type.

• Defines MIME media subtype text/enriched.
• Obsoletes: RFC 1523, RFC 1563.

[RFC 1947] Greek Character Encoding for Electronic Mail Messages.

[RFC 2015] MIME Security with Pretty Good Privacy (PGP).

• Category: Standards Track.
• Defines MIME media subtypes application/pgp-encrypted, application/pgp-keys and application/pgp-signature.

[RFC 2017] Definition of the URL MIME External-Body Access-Type.

[RFC 2045] Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.

• Obsoletes: RFC 1341, RFC 1342, RFC 1521, RFC 1522, RFC 1590.

[RFC 2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.

• Updated by: RFC 3798.
• Obsoletes: RFC 1521, RFC 1522, RFC 1590.

[RFC 2047] MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text.

• Obsoletes: RFC 1521, RFC 1522, RFC 1590.

[RFC 2049] Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples.

• Obsoletes: RFC 1521, RFC 1522, RFC 1590.

[RFC 2076] Common Internet Message Headers.

[RFC 2077] T