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 was based on ARPANET, inheriting many characteristics that are still used.

This is an important metadata item and fundamental to the delivery of media although it was originally designed to support email.

The Media Type suggests how a receiving client application should treat the incoming content. The browser or media player handles the incoming media accordingly.

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 IETF in a collection of RFC documents and registered with the 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. Every organization has a preferred nomenclature.

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

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

MIME is an abbreviation of the term 'Multipart Internet Mail Extension'. 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 downloads.

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

Media Types or MIME Types (etc.) are fundamentally the same thing and do the same job in every context.

Who Manages The Media Type Definitions?

Two organizations manage the Media Types:

• The Internet Assigned Numbers Authority (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.
• The Internet Engineering Task Force (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:

Refer to RFC 4289 and 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

The Suffix value extends the Media Type definition to provide a more specific hint about the media content. This could select generic processors that understand format specific syntax while ignoring the internal semantics of the data which is parsed separately afterwards.

Parameters

Important Standards

MIME and its antecedents have been around for a long time. The earliest RFCs relating to this topic were published in 1977 (RFC 724) when email was introduced to ARPANET. Long before the Internet was created and 20 years prior to the World Wide Web.

For modern purposes, RFC 2045 is the starting point. The email architecture was overhauled in 1996 to support the more advanced attachments that facilitated HTML formatted messages. The new specifications allowed for a massive increase in the number and diversity of Media Types.

These RFC documents currently relevant to the Media Type specifications. Some of these describe aspects of the mail protocol but also contain useful insights.

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.

Conclusion

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:

These Appendix articles contain additional information you may find useful: