Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

MIME Standards

MIME was first described in a set of two standards, RFC 1341 and RFC 1342, published in

June 1992. These were updated by RFCs 1521 and 1522 in September 1993. In March

1994, a supplemental standard was published, RFC 1590, which specified the procedure

for defining new MIME media types.

Work continued on MIME through the mid-1990s, and in November 1996 the standards

were revised again. This time, the documents were completely restructured and published

as a set of 5 individual standards. This was done to improve the readability of the infor-

mation. These standards are shown in Table 242.

Since the time that these five “primary” MIME standards came out, numerous additional

RFCs have been published. These have defined various extensions to MIME itself,

including additional MIME header types and new media types. Notable examples are RFCs

2183 and 2557, which define the MIME Content-Disposition and Content-Location headers,

respectively. Some other MIME capabilities are actually defined as part of other technol-

ogies that use MIME; for example, the first HTTP standard, RFC 1945 defines the Content-

Length header. Numerous other RFCs define new media types/subtypes, too many to list

here.

MIME Basic Structures and Headers

The creators of the Multipurpose Internet Mail Extensions (MIME) standard had a difficult

challenge on their hands: how to bring flexibility in the types of data contained in e-mail

messages, when RFC 822 said that they had to be comprised of only ASCII text. To accom-

plish this, they had to exploit the areas of flexibility that had already been put into the

existing RFC 822.

Table 242: Multipurpose Internet Mail Extensions (MIME) Standards

RFC

Number

Name Description

2045

Multipurpose Internet Mail Extensions

(MIME) Part One: Format of Internet

Message Bodies

Describes the fundamental concepts behind MIME

and the structure of MIME messages.

2046

Multipurpose Internet Mail Extensions

(MIME) Part Two: Media Types

Explains the concept of MIME media types and

subtypes and describes some of the kinds of

media whose encoding is defined in the MIME

standards.

2047

MIME (Multipurpose Internet Mail Exten-

sions) Part Three: Message Header

Extensions for Non-ASCII Text

Describes how RFC 822 headers can be modified

to carry non-ASCII text.

2048

Multipurpose Internet Mail Extensions

(MIME) Part Four: Registration Procedures

Discusses how organizations can register

additional media types for use with MIME.

2049

Multipurpose Internet Mail Extensions

(MIME) Part Five: Conformance Criteria

and Examples

Provides additional implementation information

and examples of how MIME can be used.

There were two such “opportunities” available. The first was the fact that RFC 822 message

bodies are allowed to contain any type of ASCII text, as long as lines don't exceed 998 text

characters and each line ends with a “CRLF” control code combination. Even though the

creators of RFC 822 naturally assumed this ASCII text would be human-readable, there

was nothing stopping it from being machine-readable code. The second was the facility built

into RFC 822 (and the protocols that use it, such as SMTP) to allow custom “user-defined”

header fields to be added to any e-mail message.

The non-specific nature of RFC 822 message bodies forms the basis for how MIME itself

works. An e-mail client that supports the MIME standard uses special encoding algorithms

that transform non-ASCII information into ASCII form. It then places this set of encoded

ASCII characters into the body of the message, as if it had been typed by a user, using one

of two special structures.

The ability to add new headers to RFC 822 is used to communicate information about the

use of MIME from the sender to the recipient. The devices transporting a MIME message

don't care that MIME was used, because they don't pay attention to the contents of the

message body. However, when the message reaches its destination, the recipient’s e-mail

client program must have some way of knowing that MIME was used, and must also be told

how the information in the message was encoded. Otherwise, it might just present the

encoded non-ASCII data to the user as ASCII text (which would look like random

gibberish!)

Basic Structure Types

The exact method by which data is encoded in the message body and MIME headers are

included depends on the overall structure of the MIME message. There are two basic

structure types, which are described based on the kind of media the message carries:

☯ Simple Structure (Discrete Media): MIME messages carrying a single discrete

media type, such as a text message or a graphical image, use a simple structure. Only

one encoding of information is present in the body of the message.

☯ Complex (Composite Media) Structure: Some MIME messages carry a composite

media type, which allows multiple different media to be contained in a single message,

such as a text message and a graphical image, or to encapsulate another e-mail

message in its entirety. Many of these use a more complex structure where the body of

the message contains several MIME body parts.

MIME Entities

Collectively, both whole MIME messages and individual body parts are called MIME

entities. Each set of MIME headers provides information about either type of MIME entity: a

MIME message as a whole, or a body part in a composite message. When a MIME

message is received, the recipient first examines the headers in the message as a whole

(the RFC 822 headers) to determine the overall message type. This then indicates if the

message uses a simple or complex structure. If the latter, the body of the message is

parsed and each individual body part is individually interpreted, including its individualized

headers. The topic on composite media types has more details on how these body parts

are formatted.

Primary MIME Headers

The first of the five main MIME standards, RFC 2045, describes a set of five primary MIME

headers that communicate basic information about the content of each MIME entity

(message or body part).

MIME-Version

Each MIME message is required to have a MIME-Version header, which serves two

purposes. First, it identifies the e-mail message as being MIME-encoded. Second, even

though only one version of MIME has been defined so far, having a version number header

provides “future-proofing” in case a new version is created later that may have some incom-

patibilities with the present one. Right now, all MIME messages use version 1.0.

This is the only MIME header that applies only to an entire message; it is not used to label

individual MIME body parts. This is easy to remember as it is the only header whose name

does not begin with “Content-”.

Content-Type

Describes the nature of the data that is encoded in the MIME entity. This header specifies a

content type and a content subtype, which are separated by a slash character. It may

optionally also contain certain parameters, that convey additional information about the type

and subtype. In a message body, this header is what tells the recipient of the e-mail

message what sort of media it contains, and whether the body uses a simple or complex

structure. In a body part, it describes the media type the body part contains.

For example, a message containing an HTML document might have a Content-Type header

of “text/html”, where a message containing a JPEG graphical file might be specified as

“image/jpeg”. For a composite MIME type, the Content-Type header of the whole message

will contain something like “multipart/mixed” or “multipart/alternative”, and each body part

will contain individual Content-Type headers such as “text/html” or “image/jpeg”. These are

all discussed in detail in the next two topics.

This header is optional. When not present, the default of a regular US-ASCII text message

is assumed (the media type of regular RFC 822 messages).

Content-Transfer-Encoding

For a message using simple structure, specifies the specific method that was used to

encode the data in the message body; for a composite message, identifies the encoding

method for each MIME body part. For data that is already in ASCII form, no special

encoding is needed, but other types of data must be converted to ASCII for transmission.

This header tells the recipient how to decode the data back into its normal representation.

MIME encoding methods are described later in this section.

This header is optional; the default value if it is not present is “7bit” encoding, which again is

the encoding of regular ASCII.

Content-ID

Allows the MIME content to be assigned a specific identification code. This header is

analogous to the RFC 822 Message-ID header field, but is specific to the MIME content

itself. It is optional, and is most often used for body parts in multipart MIME messages.

Content-Description

This is an optional header that allows an arbitrary additional text description to be

associated with the MIME entity. In a multipart message, each body part might be given a

description header to make clear to the recipient what the parts represent.

Additional MIME Headers

In addition to the five basic headers above, the MIME standard allows additional ones to be

defined. The only restriction is that they all must start with the word “Content-”, which again,

clearly labels them as describing content of a MIME entity (message or body part).

Obviously, both sender and recipient must support a custom header for it to be useful.

Several new MIME headers have in fact been created and documented in various Internet

RFCs. Some are actually designed not specifically for use by e-mail messages, but for use

by other protocols that make use of MIME technology, such as the HyperText Transfer

Protocol (HTTP). Here are three notable ones.

Content-Disposition

In multipart MIME messages, this header may be given to MIME body parts to control how

information is presented to the user. The two most common values are “inline”, which says

the content is intended to be displayed automatically along with other body parts, and

“attachment”, which indicates that the content is separate from the main document. This

header is defined in RFC 2183.

Content-Location

Allows the location of a MIME body part to be identified using a uniform resource identifier

(URI). This is sometimes used when encoding HTML and other multimedia-enabled

document formats into e-mail using MIME multipart messages. It is defined in RFC 2557.

Content-Length

Specifies the length of a MIME entity in bytes. This header is not commonly used in e-mail

applications of MIME, but is an important header in HTTP. It is described in the HTTP

standards, first appearing in RFC 1945.

Key Concept: MIME provides flexibility in the information that can be carried in e-

mail messages, by encoding non-ASCII data in ASCII form, and by adding special

headers that describe this data and how it is to be interpreted. The most important

MIME headers are Content-Type, which describes what sort of data is in the message, and

Content-Transfer-Encoding, which specifies how the data is encoded. MIME supports two

basic overall formats: simple structure, in which a single type of discrete media is encoded

in a message; and complex structure, which encodes a composite media type that can

carry multiple kinds of information.

MIME Content-Type Header and Discrete Media: Types, Subtypes and Parameters

MIME transforms TCP/IP e-mail from the drab, text-only world of RFC 822, to a rich

communication method that can carry many types of data. It accomplishes this by using

special techniques to encode various kinds of information into ASCII text form, such as

graphical images, sound files, video clips, application programs, compressed data files, and

many others. We commonly refer to these as different types of media, and MIME uses the

same term to describe them.

Since MIME supports so many kinds of media, it is necessary that each message contain

information that describes what it contains, to permit accurate decoding of message

contents. This is the function of the important MIME Content-Type header.

Content-Type Header Syntax

The syntax of the header is as follows:

Content-Type: <type>/<subtype> [; parameter1 ; parameter2 .. ; parameterN ]

The purpose of these different elements is to describe the media in the MIME entity in a

way that proceeds from the general to the specific. The first element, “<type>”, is called the

top-level media type and describes the overall form of the data. For example, it indicates if

the MIME entity contains text, an image, audio and so forth. The second element,

“<subtype>”, provides specific information about the form or format of the data. For

example, a JPEG image and a GIF image are both images, but they are in a different

format. Both “<type>” and “<subtype>” are mandatory in the Content-Type header.

Following these elements may appear one or more parameters, which are usually optional

but may be required for some media types. These provide still more detailed specification of

the nature of the data, when it is required. Each parameter is preceded by a semi-colon and

is expressed as an attribute/value pair, separated by an “=” sign, like this:

; attribute=value

One example of how parameters may be used is in specifying the character set in a text

message. The representation of “regular” RFC 822 ASCII text is as follows:

Content-type: text/plain; charset=“us-ascii”

The top-level media type is “text”, and the subtype is “plain”, so this indicates a plain text

message. The parameter “charset” specifies that the message uses the US ASCII

character set. Another common use for parameters is to specify the name of an attached

file, like this:

Content-type: image/jpeg; name=“ryanpicture.jpg”

Discrete Media Types and Subtypes

As I mentioned in the preceding topic, MIME supports two basic structures: simple or

complex. A simple message carries only one media type, such as a piece of text, a picture

or an executable file. These are called discrete media types in MIME. A complex message

carries a composite media type, which may incorporate multiple body parts. Each body part

in turn carries data corresponding to one of the discrete media types. The top-level media

type indicates whether the whole message carries a discrete media type or a composite

type; I will describe the discrete media types here; the composite types are discussed in the

next topic.

The RFC 2046 standard (part two of the set of five standards that describes MIME) defines

five discrete top-level media types: text, image, audio, video and application; they each

represent one of the major classes of data commonly transmitted over TCP/IP. Each of

these has one or more subtypes, and some also have parameters that are used to provide

more information about them.

The creators of MIME recognized that the standard could not describe every media type,

and that new ones would be created in the future. RFC 2048 (part four of the five-standard

MIME set) describes the process by which new media types, subtypes and parameters can

be described and registered with the Internet Assigned Numbers Authority (IANA).

Thus far, only one new top-level media type has been created; this is the model top-level

type, defined for CAD modeling files and similar uses, as described in RFC 2077. However,

many dozens of new subtypes have been created over the years, some specified in RFCs

and others just registered directly with IANA. This includes many “vendor-specific”

subtypes, which are usually identified by either the prefix “x-” or “vnd.” in the subtype name.

On The Web: You can find a complete list of MIME media organized by top-level

media type, on IANA's web site: http://www.iana.org/assignments/media-types/

index.html

Key Concept: The MIME Content-Type header specifies what sort of data is

encoded in a MIME message. The header indicates the general form of the

message’s content through a top-level media type, and the more specific nature of

the data through the specification of a subtype. It may also contain optional parameters that

provide still more information about the content.

Common Discrete Media Types and Subtypes

There are literally hundreds of type/subtype combinations now, and I will not try to list them

all, but will briefly describes the six MIME discrete top-level media types. For each, a table

has been provided showing some of the more commonly-encountered MIME subtypes, to

give you an idea of what is "out there". This includes a description of each subtype and a

reference to the place where it is defined.

Text Media Type (text)

This type is used for sending data that is primarily in textual form (Table 243).

Table 243: MIME text Media Type Subtypes

type/subtype Description

Defining

Source

text/plain

Plain text, used for regular messages such as those corre-

sponding to the initial RFC 822 standard.

RFC 2046

text/enriched

Text that includes formatting information or other “enrichment”

that makes it no longer “plain”.

RFC 1896

text/html

A document expressed in Hypertext Markup Language

(HTML), commonly used for the World Wide Web.

RFC 2854

text/css Cascading style sheet information for the World Wide Web. RFC 2318

Image Media Type (image)

The image type indicates graphical image files, such as pictures. The subtype normally

indicates the specific format to allow the recipient to properly decode and present the file,

with some of the more common subtypes given in Table 244.

Audio Media Type (audio)

This media type is used for sending audio information. The subtype normally indicates the

specific format, with Table 245 showing a couple of common values.

Video Media Type (video)

This type is used for sending video information. Again, the subtype normally indicates the

specific format (Table 246).

Table 244: MIME image Media Type Subtypes

type/subtype Description

Defining

Source

image/jpeg An image in JPEG format. RFC 2046

image/gif A Graphical Interchange Format (GIF).image.

(IANA says

RFC 2046 but

it’s not

there…)

image/tiff Tagged Image File Format (TIFF) image. RFC 2302

image/vnd.dwg,

image/vnd.dxf,

image/vnd.svf

Vector images used in AutoCAD.

Registration

with IANA

Table 245: MIME audio Media Type Subtypes

type/subtype Description

Defining

Source

audio/basic

A “basic” audio type defined in the main MIME standards. It

describes single-channel audio encoded using 8-bit ISDN mu-

law PCM at 8000 Hz.

RFC 2046

audio/mpeg MPEG standard audio (including the popular MP3 file format). RFC 3003

Table 246: MIME video Media Type Subtypes (Page 1 of 2)

type/subtype Description

Defining

Source

video/mpeg Video encoded to the MPEG digital video standard. RFC 2046

Model Media Type (model)

This type describes a model representation, such as a two-dimensional or three-dimension

physical model (Table 247).

Application Media Type (application)

This media type is a “catch all” for any kind of data that doesn't fit into one of the categories

above, or that is inherently application-specific. The subtype describes the data by

indicating the kind of application that uses it. This can be used to guide the recipient's e-

mail program in choosing an appropriate application program to display it, just like how a file

extension in Windows tells the operating system how to open different kinds of files.

For example, if you have Microsoft Excel installed on your PC, clicking a file ending with

“.XLS” will launch Excel automatically. Similarly, an Excel spreadsheet will normally be sent

using MIME with a media type of application/vnd.ms-excel. This tells the recipient's e-mail

program to launch Excel to read this file.

video/dv

Digital video corresponding to several popular standards

including SD-VCR, HD-VCR, and DVB, as used by various

types of video equipment.

RFC 3189

video/quicktime Apple's Quicktime movie format.

Registration

with IANA

Table 247: MIME model Media Type Subtypes

type/subtype Description

Defining

Source

model/mesh A mesh, as used in modeling. RFC 2077

model/vrml A Virtual Reality Modeling Language (VRML) model. RFC 2077

model/iges

A model file correspondng to the Initial Graphics Exchange

Specification (IGES).

Registration

with IANA

Table 246: MIME video Media Type Subtypes (Page 2 of 2)

type/subtype Description

Defining

Source

Since there are so many applications out there, there are over a hundred different subtypes

within this top-level type. Table 248 contains a few representative samples.

Of these, there is one special subtype that is worth further mention: the application/octet-

stream subtype. This is a “catch all” within the “catch all” of the application type, and just

means the file is a sequence of arbitrary binary data. It is usually used when the sender is

unsure of what form the data takes, or cannot identify it as belonging to a particular appli-

cation. When this type is used, the recipient will usually be prompted to just save the data to

a file. He or she must then figure out what application to use to read it.

The application/octet-stream MIME type/subtype may even be used for images, audio or

video in unknown formats. If you try to send a multimedia document that your sending

program does not understand, it will generally encode it as application/octet-stream for

transmission. This is your e-mail program's way of saying to the recipient “I am sending you

this file as-is, you figure out what to do with it”.

Table 248: MIME application Media Type Subtypes

type/subtype Description

Defining

Source

application/octet-stream

An arbitrary set of binary data octets. See below for more

details.

RFC 2046

application/postscript

A Postscript file, used for printing and for generating Adobe

Acrobat (PDF) files.

RFC 2046

application/applefile

Resource file information for representing Apple Macintosh

files.

Registration

with IANA

application/msword

Microsoft Word document. Note that this does not have the

“vnd” prefix like most other Microsoft file types.

Registration

with IANA

application/pdf

A Portable Document Format (PDF) file, as created by Adobe

Acrobat.

Registration

with IANA

application/

vnd.framemaker

An Adobe FrameMaker file.

Registration

with IANA

application/vnd.lotus-1-

2-3

A Lotus 1-2-3 file.

Registration

with IANA

application/vnd.lotus-

notes

A Lotus Notes file.

Registration

with IANA

application/vnd.ms-

excel

A Microsoft Excel spreadsheet file.

Registration

with IANA

application/vnd.ms-

powerpoint

A Microsoft Powerpoint presentation file.

Registration

with IANA

application/vnd.ms-

project

A Microsoft Project file.

Registration

with IANA

application/zip

A compressed archive file containing one or more other files,

using the ZIP/PKZIP compression format.

Registration

with IANA