Why Do We Need Media Type Identifiers?

Media Types describe the container and content format when delivering media over a network. Historically they were described as MIME Types and you will often see them listed as such in some standards documents.

A Media Type describes a container file or stream and the payload carried in it. These object descriptions were first defined for the ARPANET. The Internet we know today was based on ARPANET, and many of its characteristics are still used today.

Although originally designed to support email, they are an important metadata item and fundamental to the delivery of media. The Media Type suggests how a receiving client application should treat the incoming content. The browser or media player handles the incoming media accordingly. Web browsers will use the media type value in preference to the file type when deciding how to handle an incoming media asset.

Workflows depend on this when assets are delivered via the IP network. Typically, they are transferred with HTTP although other mechanisms might be used. Attaching Media Type signatures in HTTP protocol headers or supporting metadata packages facilitates proper handling at each processing node.

Media Type standards are described by the Internet Engineering Task Force (IETF) in a collection of RFC documents and registered with the Internet Assigned Numbers Authority (IANA) in a publicly accessible database.

What Is The Correct Terminology?

Opinion is divided on what to call the metadata items describing the media format. There is a long history to consider. This will have influenced many ancient documents that are still relevant and might not have been updated.

These terms are broadly interchangeable in a functional sense but should be used appropriately depending on the context:

• MIME Type.
• Media Type.
• Media Type Identifier.
• Content Type.

MIME is an abbreviation of the term ‘Multipart Internet Mail Extension’ and were originally designed to facilitate the attachment of non-textual media objects when they are carried in an email message. Now, they are more often described as Media Types and are used in many other contexts.

Web Server response headers use the term ‘Content Type’ when delivering media for display or downloading.

The same fundamental technology is used within an IP based production environment. Media Type Identifiers would probably be the most appropriate term for use in broadcast production.

Every organization has a preferred nomenclature:

Media Type Identifiers, content types and MIME Types (etc.) are fundamentally the same thing and do the same thing in every context.

Who Manages The Media Type Definitions?

Two organizations manage the Media Type Identifiers:

• IANA manages the publicly accessible registries of protocols and types. Their database associates Media Types with file extensions so the receiving device can choose the correct parsing mechanism.
• IETF publishes RFC documents that describe how to deploy the IANA registered values. RFC specifications are updated or replaced when new types are registered with the IANA.

A Media Type value is more reliable than a file extension on its own for determining the content of an asset. The extended Subtype, Tree, Suffix and Parameter-set details make the description very specific when necessary.

A complete list is maintained at the IANA registry where there are over 2000 individual Media Types:

The RFC 4289 and 6838 documents describe the process for registering new Media Types.

Many of the RFC documents were originally written to describe an email context for using these Media Type values. It is still worth reading those parts of the specifications.

Structure & Format

Media Types identify the fundamental nature of the content. File extensions are less specific and not as reliable an indicator of what variety of media is being carried. The component parts of the Media Type cover different aspects:

Top-Level-Types

The Top-Level-Type identifies the fundamental category of media being delivered. They are most recently described in RFC 6838. There are some proprietary Top-Level-Types defined elsewhere on an informal basis:

The Top-Level-Type values are case insensitive but by convention are usually presented in lower-case.

Other Top-Level-Types are defined for chemical model files and the Linux desktop environment also describes some special values for use within the operating system. They are used to implement the user interface.

Refer to RFC 2046, RFC 6838 and the IANA registry for Media Types for a more detailed description.

Subtypes

The Subtype value supports a nested tree-like structure to allow for proprietary and other extensions. There are four Subtype Trees currently defined. Each requires a slightly different syntax for constructing the Subtype value.

The Top-Level-Type and Subtype are separated by a slash character (/). Here are some common useful Top-Level-Types and Subtype combinations.

Refer to RFC 4289 and RFC 6838 for details of how the member Subtypes in these Trees should be defined and registered. The IETF may create additional Trees and register them with the IANA if they are called for.

Subtype values are case-insensitive but by convention they are presented in lower case.

Suffixes

These Suffix values should be registered with the IANA. The use of unregistered Suffix values is discouraged.

The current list of IANA registered suffix values is available here:

Parameters

Relevant Standards

The descriptive RFC documents have been continuously updated and replaced by more recent versions that extend and improve the capabilities. Search the IETF RFC repository for the older versions of the documents if you need them.

Do You Want To Know More?

Media Types are important in the context of an IP studio workflow. Without them, the incoming content must be inspected carefully to determine the type and format. Any misinterpretation will cause serious problems downstream.

The IANA maintains many registries which are useful when constructing workflows. Access the top-level index to the IANA registry here: