Skip to main content

4. Registration Requirements

Media type registrations are all expected to conform to various requirements laid out in the following sections. Note that requirement specifics sometimes vary depending on the registration tree, again as detailed in the following sections.

4.1 Functionality Requirement​

Media types MUST function as actual media formats. Registration of things that are better thought of as a transfer encoding, as a charset, or as a collection of separate entities of another type, is not allowed. For example, although applications exist to decode the base64 transfer encoding [RFC2045], base64 cannot be registered as a media type.

This requirement applies regardless of the registration tree involved.

4.2 Naming Requirements​

All registered media types MUST be assigned top-level type and subtype names. The combination of these names serves to uniquely identify the media type, and the subtype name facet (or the absence of one) identifies the registration tree. Both top-level type and subtype names are case-insensitive.

Type and subtype names MUST conform to the following ABNF:

type-name = restricted-name
subtype-name = restricted-name

restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first  = ALPHA / DIGIT
restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
                         "$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
                             ; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
                             ; specify a structured syntax suffix

Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in Section 5.1 of [RFC2045] or Section 4.2 of [RFC4288]. Also note that while this syntax allows names of up to 127 characters, implementation limits may make such long names problematic. For this reason, <type-name> and <subtype-name> SHOULD be limited to 64 characters.

4.2.1 Text Media Types​

The "text" top-level type is intended for sending material that is principally textual in form.

Many subtypes of text, notably including the subtype "text/plain", which is a generic subtype for plain text defined in [RFC2046], define a "charset" parameter. If a "charset" parameter is defined for a particular subtype of text, it MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].

4.2.2 Image Media Types​

A top-level type of "image" indicates that the content specifies one or more individual images. The subtype names the specific image format.

4.2.3 Audio Media Types​

A top-level type of "audio" indicates that the content contains audio data. The subtype names the specific audio format.

4.2.4 Video Media Types​

A top-level type of "video" indicates that the content specifies a time-varying-picture image, possibly with color and coordinated sound. The term 'video' is used in its most generic sense, rather than with reference to any particular technology or format, and is not meant to preclude subtypes such as animated drawings encoded compactly.

4.2.5 Application Media Types​

The "application" top-level type is to be used for discrete data that do not fit under any of the other type names, and particularly for data to be processed by some type of application program.

4.2.6 Multipart and Message Media Types​

Multipart and message are composite types; that is, they provide a means of encapsulating zero or more objects, each one a separate media type.

All subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046] and amended by Section 3.5 of [RFC6532].

4.2.7 Additional Top-Level Types​

In some cases, a new media type may not "fit" under any currently defined top-level type names. Such cases are expected to be quite rare. However, if such a case does arise, a new type name can be defined to accommodate it. Definition of a new top-level type name MUST be done via a Standards Track RFC; no other mechanism can be used to define additional type names.

4.2.8 Structured Syntax Name Suffixes​

Media types that make use of a named structured syntax SHOULD use the appropriate registered "+suffix" for that structured syntax when they are registered. By the same token, media types MUST NOT be given names incorporating suffixes for structured syntaxes they do not actually employ.

4.2.9 Deprecated Aliases​

In some cases, a single media type may have been widely deployed prior to registration under multiple names. In such cases, a preferred name MUST be chosen for the media type, and applications MUST use this to be compliant with the type's registration.

4.3 Parameter Requirements​

Media types MAY elect to use one or more media type parameters, or some parameters may be automatically made available to the media type by virtue of being a subtype of a content type that defines a set of parameters applicable to any of its subtypes.

Parameter names have the syntax as media type names and values:

parameter-name = restricted-name

Parameter names are case-insensitive and no meaning is attached to the order in which they appear. It is an error for a specific parameter to be specified more than once.

4.4 Canonicalization and Format Requirements​

All registered media types MUST employ a single canonical encoding format.

4.5 Interchange Recommendations​

Media types SHOULD include recommendations about how best to accomplish interchange between heterogeneous systems.

4.6 Security Requirements​

An analysis of security issues MUST be done for all registrations. All media type registrations MUST include a "Security considerations" section detailing the security implications of the media type.

4.7 Requirements Specific to XML Media Types​

Media types that employ XML MUST comply with the requirements specified in [RFC7303].

4.8 Encoding Requirements​

Media type registrations MUST clearly specify how the type is to be encoded for use with various transport protocols.

4.9 Usage and Implementation Non-Requirements​

Registration of a media type does not imply any endorsement of a particular implementation.

4.10 Publication Requirements​

Standards tree registrations for widely deployed media types SHOULD be published as RFCs.

4.11 Fragment Identifier Requirements​

Media types that employ fragment identifiers MUST document what fragment identifier syntax is supported.

4.12 Additional Information​

The media type registration template includes a number of additional information fields.

Last updated on