1. Introduction
Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, many protocols, including but not limited to HTTP [RFC2616] and MIME [RFC2045], are capable of carrying arbitrary labeled content.
The mechanism used to label such content is a media type, consisting of a top-level type and a subtype, which is further structured into trees. Optionally, media types can define companion data, known as parameters.
A registration process is needed for these labels, so that the set of such values are defined in a reasonably orderly, well-specified, and public manner.
This document specifies the criteria for media type registrations and defines the procedures to be used to register media types (Section 5) as well as media type structured suffixes (Section 6) in the Internet Assigned Numbers Authority (IANA) central registry.
The location of the media type registry managed by these procedures is:
http://www.iana.org/assignments/media-types/
1.1 Historical Note
The media type registration process was initially defined for registering media types for use in the context of the asynchronous Internet mail environment. In this mail environment, there is a need to limit the number of possible media types, to increase the likelihood of interoperability when the capabilities of the remote mail system are not known. As media types are used in new environments in which the proliferation of media types is not a hindrance to interoperability, the original procedure proved excessively restrictive and had to be generalized. This was initially done in [RFC2048], but the procedure defined there was still part of the MIME document set. The media type specification and registration procedure is now a separate document, to make it clear that it is independent of MIME.
It may be desirable to restrict the use of media types to specific environments or to prohibit their use in other environments. This specification incorporates such restrictions into media type registrations in a systematic way. See Section 4.9 for additional discussion.
1.2 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. They may also appear in lower or mixed case as plain English words, without any normative meaning.
This specification makes use of the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of that document.