9.2 MIME and Media Types

The Multipurpose Internet Mail Extensions (MIME) standard is a means of specifying media types such as images, program data, audio files, and text. Described in Internet Engineering Task Force (IETF) Request for Comments (RFC) documents 2045 through 2049, it includes a comprehensive list of known types and has inspired a registry for many more.

MIME was developed originally to extend the paradigm of email from plain text to a rich array of media. Email transport systems, such as the Simple Mail Transfer Protocol (SMTP), can only deal with 7-bit ASCII text. You cannot simply append a binary file to the end of a message and have it bounce happily across the Internet. The data has to be encoded in an ASCII-compatible way. There are other requirements as well, such as a minimum line length and absence of certain control characters . MIME introduces methods to transform data into a safe form. It also describes how to package this data in a recognizable way for mail transfer agents and clients to work with.

One of the ways MIME describes a resource is by assigning it a media type (or content-type ) which names the general category that best describes the data. Each type includes a set of subtypes that exactly identify the resource. The type and subtype are usually written together, joined by a slash character (/). For example, image/jpeg denotes a graphical resource in the JPEG format. The major types include:

text

Textual information that can be read in a traditional text editor without any special processing. text/plain is as simple as you can get: just ASCII characters without any kind of formatting other than whitespace.

image

Graphical data requiring some display device such as a printer or display terminal. image/gif is a popular image subtype on the Web.

audio

Sound data requiring an audio output device such as a speaker to reproduce. audio/wav is one common example.

video

Animated graphical data requiring a viewing device, such as the movie format video/mpeg .

application

Some undetermined kind of data. It may be a binary format, or else requiring some processing to be useful. A good example is application/PostScript which looks like dense program code until sent to a printer. Uninterpreted binary data is labeled application/octet-stream , a grab bag for unknown types.

multipart

More of a meta-type, really, it packages up a group of possibly unrelated resources. Subtypes like multipart/mixed and multipart/parallel describe how to present the resources (e.g., positioned together on a screen).

message

Another meta-type that packages resources. In this case, the resources all pertain to a single message object, presumably adding up to a single communicative package.

You can see that MIME tackles a huge problem in attempting to label every conceivable kind of data that could be transmitted over a network. It works well because of a well-publicized registry of media types maintained by the Internet Assigned Numbers Authority (IANA). You can see the latest list at http://www.iana.org/assignments/media-types/index.html.

MIME content types are important in many areas outside of email. General-purpose MIME dispatchers analyze a document as it appears and routes it to the correct media handler. For example, web browsers rely on HTTP headers to tell them what kind of data is arriving. The following HTTP content type field tells us that the incoming resource is text and should be handled as HTML:

 Content-Type: text/html; charset=ISO-8859-1 

The charset portion is optional and actually means "character encoding" (another case of confusing terms). This is another mechanism, besides XML declarations, for specifying a character encoding.

In XML, too, there are cases in which MIME is useful. For example, in linking with XPointers, it would be helpful to the XML processor to know in advance what resource is being imported. Another example is specifying a stylesheet in a document:

 <?xml-stylesheet type="text/css" href="ex2_memo.css"?> 

Here, the type attribute is set to a MIME content type for CSS stylesheets.

As XML rises in prominence as an exchange medium on the Internet, the need for media types that identify XML-related data grows. A recent specification, RFC 3023, adds a few new XML- related media types to the mix and a way to extend other media types to include a "+xml" suffix. For example, you can make the type image/svg more descriptive by adding the tag to make it image/svg+xml . A system that recognizes and treats XML data specially will benefit from that extra information. The new media types are:

text/xml

This is your basic XML document with no special processing requested . The recipient is expected to know what to do with the data. (Some developers would like to see text/xml deprecated in favor of application/xml , as XML doesn't precisely fit IETF expectations for the text top-level type.)

application/xml

This is an XML document that requires some preparation before it is useful for viewing. Some indication of what application to use will be included. The recipient might look inside the document for a DOCTYPE declaration, for example.

text/xml-external-parsed-entity , application/xml-external-parsed-entity

Like the above, but not necessarily a complete document. The recipient will have to assemble the entities into a complete package before parsing the document. (Like text/xml , some developers want text/xml-external-parse-entity deprecated.)

application/xml-dtd

The item is a document type definition (DTD), and not an actual XML document. In some cases, it may be useful to supply a DTD in addition to the document to help out the XML processor.