Network Working Group M. Nottingham Internet-Draft Cloudflare Obsoletes: 6838 (if approved) P. Resnick Intended status: Best Current Practice 18 May 2025 Expires: 19 November 2025 Media Type Specifications and Registration Procedures draft-ietf-mediaman-6838bis-03 Abstract This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-mediaman-6838bis/. information can be found at https://datatracker.ietf.org/wg/mediaman/ about/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-mediaman/6838bis/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 November 2025. Nottingham & Resnick Expires 19 November 2025 [Page 1] Internet-Draft Media Type Registration May 2025 Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Media Type Registration Requirements . . . . . . . . . . . . 4 2.1. Functionality . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Publication . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Availability . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Intellectual Property . . . . . . . . . . . . . . . . 5 2.3. Canonicalization and Interoperability . . . . . . . . . . 6 2.4. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1. Aliases . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Fragment Identifiers . . . . . . . . . . . . . . . . . . 9 2.8. Security . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8.1. Structured Suffixes . . . . . . . . . . . . . . . . . 11 2.9. Non-Requirements . . . . . . . . . . . . . . . . . . . . 12 2.10. Additional Information . . . . . . . . . . . . . . . . . 12 3. Top-Level Media Types . . . . . . . . . . . . . . . . . . . . 13 3.1. Text Media Types . . . . . . . . . . . . . . . . . . . . 13 3.1.1. The Charset Parameter . . . . . . . . . . . . . . . . 14 3.2. Image Media Types . . . . . . . . . . . . . . . . . . . . 14 3.3. Audio Media Types . . . . . . . . . . . . . . . . . . . . 14 3.4. Video Media Types . . . . . . . . . . . . . . . . . . . . 15 3.5. Application Media Types . . . . . . . . . . . . . . . . . 15 3.6. Multipart and Message Media Types . . . . . . . . . . . . 16 3.7. Additional Top-Level Types . . . . . . . . . . . . . . . 16 3.7.1. Required Criteria . . . . . . . . . . . . . . . . . . 16 3.7.2. Additional Considerations . . . . . . . . . . . . . . 17 3.7.3. Negative Criteria . . . . . . . . . . . . . . . . . . 18 4. Media Subtypes . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Registration Trees . . . . . . . . . . . . . . . . . . . 19 4.1.1. Standards Tree . . . . . . . . . . . . . . . . . . . 19 Nottingham & Resnick Expires 19 November 2025 [Page 2] Internet-Draft Media Type Registration May 2025 4.1.2. Vendor Tree . . . . . . . . . . . . . . . . . . . . . 21 4.1.3. Personal Tree . . . . . . . . . . . . . . . . . . . . 22 4.1.4. Unregistered x. Tree . . . . . . . . . . . . . . . . 22 4.1.5. Additional Registration Trees . . . . . . . . . . . . 23 4.2. Subtype Suffixs . . . . . . . . . . . . . . . . . . . . . 23 4.2.1. Common Suffix Patterns . . . . . . . . . . . . . . . 24 4.2.2. Fragment Identifiers and Suffixes . . . . . . . . . . 25 5. Media Type Registration Procedures . . . . . . . . . . . . . 25 5.1. Preliminary Community Review . . . . . . . . . . . . . . 25 5.2. Submit Request to IANA . . . . . . . . . . . . . . . . . 26 5.2.1. Provisional Registrations . . . . . . . . . . . . . . 26 5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 26 5.4. Comments on Media Type Registrations . . . . . . . . . . 27 5.5. Change Procedures . . . . . . . . . . . . . . . . . . . . 27 5.6. Registration Template . . . . . . . . . . . . . . . . . . 28 6. Structured Syntax Suffix Registration Procedures . . . . . . 29 6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 30 6.2. Structured Syntax Suffix Registration Template . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 35 Appendix B. Grandfathered Media Types . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction Internet application protocols are capable of carrying arbitrary labeled content, including but not limited to HTTP [RFC9110] and MIME [RFC2045]. Such labels are known as media types. A media type consists of a top-level type and a subtype, which is further structured into trees. Optionally, a media type can be defined to allow companion data, known as parameters. This document defines the criteria and 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) registry. The location of the media type registry managed by these procedures is: http://www.iana.org/assignments/media-types/ Nottingham & Resnick Expires 19 November 2025 [Page 3] Internet-Draft Media Type Registration May 2025 1.1. 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. 2. Media Type Registration Requirements Media type registrations are expected to conform to various requirements laid out in the following sections. Note that specific requirements can vary depending on the registration tree. Additional requirements specific to the registration of XML media types are specified in [RFC7303]. 2.1. Functionality 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. 2.2. Publication Media types registered in the standards tree by the IETF MUST be published as RFCs. RFC publication of vendor and personal media type registrations is allowed but not required. In all cases, the IANA will retain copies of all media type registrations and publish them as part of the media types registration tree itself. Standards-tree registrations for media types defined in documents produced by other standards-related organizations MUST be described by a formal standards specification produced by that organization. Additionally, any copyright on the registration template MUST allow the IANA to copy it into the IANA registry. Nottingham & Resnick Expires 19 November 2025 [Page 4] Internet-Draft Media Type Registration May 2025 The standards tree exists for those media types that require a substantive review and approval process in a recognized standards- related organization. The vendor and personal trees exist for those media types that do not require such a process. It is expected that applicability statements for particular applications will be published from time to time in the IETF, recommending implementation of, and support for, media types that have proven particularly useful in those contexts. Other than IETF registrations in the standards tree, the registration of a media type does not imply endorsement, approval, or recommendation by the IANA or the IETF or even certification that the specification is adequate. Registration of a top-level type requires Standards Action in the IETF and, hence, the publication of a RFC on the Standards Track. 2.2.1. Availability A permanent and readily available public specification of the format for the media type MUST exist for all types registered in the standards tree. This specification MUST provide sufficient detail so that interoperability between independent implementations using the media type is possible. If not part of the media type registration proposal, this specification MUST be referenced by it. The specifications of format and processing particulars need not be publicly available for media types registered in the vendor and personal trees. Such registrations are explicitly permitted to limit the information in the registration to which software and version produce or process such media types. As such, references to or inclusion of format specifications in registrations is encouraged but not required. Note, however, that the public availability of a meaningful specification will often make the difference between simply having a name reserved so that there are no conflicts with other uses and having the potential for other implementations of the media type and useful interoperation with them. 2.2.2. Intellectual Property The registration of media types involving patented technology is permitted. However, the restrictions set forth in BCP 79 [RFC8179] and BCP 78 [RFC5378] on the use of patented technology in IETF Standards Track protocols must be respected when the specification of a media type is part of a Standards Track protocol. In addition, other standards-related organizations making use of the standards tree may have their own rules regarding intellectual property that must be observed in their registrations. Nottingham & Resnick Expires 19 November 2025 [Page 5] Internet-Draft Media Type Registration May 2025 Intellectual Property Rights (IPR) disclosures for registrations in the vendor and personal trees are encouraged but not required. 2.3. Canonicalization and Interoperability All registered media types MUST employ a single, canonical data format, regardless of registration tree. Ideally, media types will be defined so they interoperate across as many systems and applications as possible. However, some media types will inevitably have problems interoperating across different platforms. For example, problems with different versions, byte ordering, and specifics of gateway handling can arise. Universal interoperability of media types is not required, but known interoperability issues SHOULD be identified whenever possible. Publication of a media type does not require an exhaustive review of interoperability, and the interoperability considerations section is subject to continuing evaluation. The recommendations in this subsection apply regardless of the registration tree involved. 2.4. Naming 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 Section 5.1 of [RFC2045] or Section 4.2 of [RFC4288]. Also note that while this syntax allows names of up to 127 Nottingham & Resnick Expires 19 November 2025 [Page 6] Internet-Draft Media Type Registration May 2025 characters, implementation limits may make such long names problematic. For this reason, 'type-name' and 'subtype-name' SHOULD be limited to 64 characters. Although this syntax treats "." as equivalent to any other character, characters before any initial "." always specify the registration facet. Note that this means that facet-less standards tree registrations cannot use periods in the subtype name. Similarly, the final "+" in a subtype name introduces a structured syntax specifier suffix. Structured syntax suffix requirements are specified in Section 4.2. While it is possible for a given media type to be assigned more than one name, the use of different names to identify the same media type is discouraged. These requirements apply regardless of the registration tree involved. 2.4.1. 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. However, a list of deprecated aliases by which the type is known MAY be supplied as additional information in order to assist applications in processing the media type properly. 2.5. Parameters Media types MAY be defined to allow or require use of media type parameters. Additionally, 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. In either case, the names, values, and meanings of any parameters MUST be fully specified when a media type is registered in the standards tree, and SHOULD be specified as completely as possible when media types are registered in the vendor or personal trees. Parameter names have the same syntax as media type names and values: parameter-name = restricted-name Nottingham & Resnick Expires 19 November 2025 [Page 7] Internet-Draft Media Type Registration May 2025 Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in [RFC2045] and amended by [RFC2231]. 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. There is no defined syntax for parameter values; therefore, it MUST be specified upon registration. Additionally, some transports impose restrictions on parameter value syntax, so care needs be taken to limit the use of potentially problematic syntaxes; for example, binary valued parameters, while permitted in some protocols, are best avoided. Note that a protocol can impose further restrictions on parameter value syntax, depending on how it chooses to represent parameters. Both MIME [RFC2045] [RFC2231] and HTTP [RFC9110] [RFC8187] allow binary parameters as well as parameter values expressed in a specific charset, but other protocols may be less flexible. Types already registered in the standards tree SHOULD NOT have new functionality added through the definition of new parameters subsequent to the original registration. New parameters MAY be used to convey additional information that does not otherwise change existing functionality. An example of this would be a "revision" parameter to indicate a revision level of an external specification such as JPEG. Similar behavior is encouraged for media types registered in the vendor or personal trees, but is not required. Changes to parameters (including the introduction of new ones) is managed in the same manner as other changes to the media type; see Section 5.5. 2.6. Encoding Some transports impose restrictions on the type of data they can carry. For example, Internet mail traditionally was limited to 7bit US-ASCII text. Encoding schemes are often used to work around such transport limitations. It is therefore useful to note what sort of data a media type can consist of as part of its registration. An "encoding considerations" field is provided for this purpose. Possible values of this field are: 7bit: The content of the media type consists solely of CRLF- delimited 7bit US-ASCII text. Nottingham & Resnick Expires 19 November 2025 [Page 8] Internet-Draft Media Type Registration May 2025 8bit: The content of the media type consists solely of CRLF- delimited 8bit text. binary: The content consists of an unrestricted sequence of octets. framed: The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out- of-band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets; therefore, such media types are unsuitable for use in many traditional protocols. A commonly used transport with framed encoding is the Real-time Transport Protocol, RTP. Additional rules for framed encodings defined for transport using RTP are given in [RFC4855]. Additional restrictions on 7bit and 8bit text are given in Section 4.1.1 of [RFC2046]. 2.7. Fragment Identifiers Media type registrations can specify how applications should interpret fragment identifiers (specified in Section 3.5 of [RFC3986]) associated with the media type. Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media types that use a named structured syntax with a registered "+suffix" MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration. 2.8. Security All registrations of types in the standards tree MUST include an analysis of security issues. A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. All descriptions of security issues MUST be as accurate as possible regardless of registration tree. In particular, the security considerations MUST NOT state that there are "no security issues associated with this type". Security considerations for types in the vendor or personal tree MAY say that "the security issues associated with this type have not been assessed". Nottingham & Resnick Expires 19 November 2025 [Page 9] Internet-Draft Media Type Registration May 2025 There is no requirement that media types registered in any tree be secure or completely free from risks. Nevertheless, all known security risks MUST be identified in the registration of a media type, again regardless of registration tree. The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in Section 5.4 below. Some of the issues that need to be examined and described in a security analysis of a media type are: * Processing of complex media types might institute actions on a recipient's files or other resources. If it is possible to specify arbitrary actions in an unrestricted fashion, it could have devastating effects. See the registration of the application/postscript media type in [RFC2046] for an example of description and handling of these issues. * Any security analysis MUST state whether or not the format employs such "active content"; if it does, it MUST state what steps have been taken (or are required be taken by applications) of the media type to protect users of the media type. * Processing of complex media types might institute actions that, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient's privacy in some way. Again, the registration of the application/ postscript media type illustrates how such directives can be handled. * A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources. All media types SHOULD state whether or not they employ compression; if they do, they SHOULD discuss what steps need to be taken to avoid such attacks. * A media type might be targeted for applications that require some sort of security assurance but don't provide the necessary security mechanisms themselves. For example, a media type could be defined for storage of sensitive medical information that in turn requires external confidentiality and integrity protection services, or which is designed for use only within a secure environment. Types SHOULD always document whether or not they need such services in their security considerations. Nottingham & Resnick Expires 19 November 2025 [Page 10] Internet-Draft Media Type Registration May 2025 2.8.1. Structured Suffixes 2.8.1.1. Document Validity If a toolchain chooses to process a provided media type by using the selected structured suffix processing rules, it cannot presume that a document that is valid per the decoding rules associated with the structured suffix will be valid for a recognized subset of the structured suffix. For example, presuming a media type of "application/foo+bar", a toolchain cannot presume that a valid "+bar" document will also be a valid "application/foo" document. On the other hand, presuming a media type of "application/foo+bar", a toolchain can presume that a valid "application/foo+bar" document will also be a valid "+bar" document. 2.8.1.2. Fragment Semantics If a toolchain chooses to process a provided media type by using the selected structured suffix processing rules, it cannot presume that fragment identifier semantics will be the same across a recognized subset of the structured suffix. For example, presuming a media type of "application/foo+bar", a toolchain cannot presume that the fragment semantics for a "+bar" document will be the same as for an "application/foo+bar" document. 2.8.1.3. Security Characteristics Toolchains cannot assume that the security characteristics of processing based on structured suffixes will be the same for the entire media type. For example, presuming a media type of "application/foo+bar", a toolchain cannot presume that the security characteristics for a "+bar" document will be the same as for a "application/foo+bar" document. 2.8.1.4. Partial Processing It is conceivable that an attacker could utilize structured suffixes in a way that tricks unsuspecting toolchains into skipping important security checks and allowing viruses to propagate. For example, an attacker might utilize an "application/vnd.ms- excel.addin.macroEnabled.12+zip" structured suffix to trigger an unzip process that might then directly invoke Microsoft Excel, bypassing anti-virus tooling that would otherwise block a macro- enabled MS Excel file containing a virus of some kind from being scanned or opened. Nottingham & Resnick Expires 19 November 2025 [Page 11] Internet-Draft Media Type Registration May 2025 Enterprising attackers might take advantage of toolchains that partially process media types in this manner. Toolchains that process media types based purely on a structured suffix need to ensure that further processing does not blindly trust the decoded data, and that proper magic header or file structure checking is performed, before allowing the decoded data to drive operations that might negatively impact the application environment or operating system. 2.9. Non-Requirements In the asynchronous mail environment, where information on the capabilities of the remote mail agent is frequently not available to the sender, maximum interoperability is attained by restricting the media types used to those "common" formats expected to be widely implemented. This was asserted in the past as a reason to limit the number of possible media types, and resulted in a registration process with a significant hurdle and delay for those registering media types. However, the need for "common" media types does not require limiting the registration of new media types. If a limited set of media types is recommended for a particular application, that should be asserted by a separate applicability statement specific for the application and/or environment. Therefore, universal support and implementation of a media type are NOT a requirement for registration. However, if a media type is explicitly intended for limited use, this MUST be noted in its registration. The "Restrictions on Usage" field is provided for this purpose. 2.10. Additional Information The following optional information SHOULD be included in the specification of a media type if it is available: * Magic number(s) (length, octet values). Magic numbers are byte sequences that are always present at a given place in the file and thus can be used to identify entities as being of a given media type. * File name extension(s) commonly used on one or more platforms to indicate that some file contains a given media type. Nottingham & Resnick Expires 19 November 2025 [Page 12] Internet-Draft Media Type Registration May 2025 * macOS Uniform Type Identifier (a string), if it makes sense to exchange media of this type through user-triggered exchange mechanisms such as copy-and-paste or drag-and-drop on macOS and related platforms (see [MacOSUTIs] for definitions and syntax). * Windows clipboard name (a string), if it makes sense to exchange media of this type through user-triggered exchange mechanisms such as copy-and-paste or drag-and-drop on Microsoft Windows and related platforms (see [windowsClipboardNames] for definitions and syntax). In the case of a registration in the standards tree, this additional information MAY be provided in the formal specification of the media type format. It is suggested that this be done by incorporating the IANA media type registration form into the format specification itself. 3. Top-Level Media Types The choice of top-level type MUST take into account the nature of media type involved. New subtypes of top-level types MUST conform to the restrictions of the top-level type, if any. The following sections describe each of the initial set of top-level types and their associated restrictions. Additionally, various protocols, including but not limited to HTTP and MIME, MAY impose additional restrictions on the media types they can transport. (See [RFC2046] for additional information on the restrictions MIME imposes.) 3.1. Text Media Types A top-level type of "text" indicates that the content is principally textual in form. Text that does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup is known as "plain text". Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text MAY allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilities that allow the arbitrary mixing of text segments with different writing directions. Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without Nottingham & Resnick Expires 19 November 2025 [Page 13] Internet-Draft Media Type Registration May 2025 the software that interprets them. It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to present subtypes of "text" to the user, while it is not reasonable to do so with most non-textual data. Such formatted textual data can be represented using subtypes of "text". 3.1.1. The Charset Parameter 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]. As specified in [RFC6657], a "charset" parameter SHOULD NOT be specified when charset information is transported inside the payload (e.g., as in "text/xml"). If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See [RFC6657] for additional information on the use of "charset" parameters in conjunction with subtypes of text. Regardless of what approach is chosen, all new text/* registrations MUST clearly specify how the charset is determined; relying on the US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer permitted. If explanatory text is needed, this SHOULD be placed in the additional information section of the registration. 3.2. Image Media Types A top-level type of "image" indicates that the content is one or more individual images. The subtype names the specific image format. 3.3. Audio Media Types A top-level type of "audio" indicates that the content is audio data. The subtype names the specific audio format. Nottingham & Resnick Expires 19 November 2025 [Page 14] Internet-Draft Media Type Registration May 2025 3.4. Video Media Types A top-level type of "video" indicates that the content is 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. Note that although in general the mixing of multiple kinds of media in a single body is discouraged [RFC2046], it is recognized that many video formats include a representation for synchronized audio and/or text, and this is explicitly permitted for subtypes of "video". 3.5. Application Media Types A top-level type of "application" indicates that the content is 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. This is information that must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" type name include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material. (The last, in particular, can pose security problems that must be understood by implementors. The "application/postscript" media type registration in [RFC2046] provides a good example of how to handle these issues.) For example, a meeting scheduler might define a standard representation for information about proposed meeting dates. An intelligent user agent would use this information to conduct a dialog with the user, and might then send additional material based on that dialog. More generally, there have been several "active" languages developed in which programs in a suitably specialized language are transported to a remote location and automatically run in the recipient's environment. Such applications may be defined as subtypes of the "application" top-level type. The subtype of "application" will often either be the name or include part of the name of the application for which the data are intended. This does not mean, however, that any application program name may simply be used freely as a subtype of "application"; the subtype needs to be registered. Nottingham & Resnick Expires 19 November 2025 [Page 15] Internet-Draft Media Type Registration May 2025 3.6. Multipart and Message Media Types A top-level type of "multipart" or "message" indicates that the content is a composite type; 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]. 3.7. Additional Top-Level Types In some cases, a new media type may not be easily classified 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, taking into account the criteria and guidelines given below; no other mechanism can be used to define additional type names. 3.7.1. Required Criteria Definitions of new top-level types are required to fulfil the following criteria: * Every new top-level type MUST be defined in a Standards Track RFC (see Section 4.9 of [RFC8126]). This will make sure there is sufficient community interest, review, and consensus appropriate for a new top-level type. * The IANA Considerations section of an RFC defining a new top-level type MUST request that IANA add this new top-level type to the registry of top-level types. * The criteria for what types do and do not fall under the new top- level type MUST be defined clearly. Clear criteria are expected to help expert reviewers to evaluate whether a subtype belongs below the new type or not, and whether the registration template for a subtype contains the appropriate information. If the criteria cannot be defined clearly, this is a strong indication that whatever is being talked about is not suitable as a top-level type. * Any RFC defining a new top-level type MUST clearly document the security considerations applying to all or a significant subset of subtypes. Nottingham & Resnick Expires 19 November 2025 [Page 16] Internet-Draft Media Type Registration May 2025 * At the minimum, one subtype MUST be described. A top-level type without any subtype serves no purpose. Please note that the 'example' top-level describes a subtype 'example'. 3.7.2. Additional Considerations Additional considerations for the defintion of a new top-level type include: * Existing wide use of an unregistered top-level type may be an indication of a need, and therefore an argument for formally defining a new top-level type. * On the other hand, the use of unregistered top-level types is highly discouraged. * Use of an IETF Working Group to define a new top-level type is not needed, but may be advisable in some cases. There are examples of new top-level type definitions without a Working Group ([RFC2077]), with a short, dedicated WG ([RFC8081]), and with a Working Group that included other related work ([I-D.ietf-mediaman-haptics]). * The document defining the new top-level type should include initial registrations of actual subtypes. The exception may be a top-level type similar to 'example'. This will help to show the need for the new top-level type, will allow checking the appropriateness of the definition of the new top-level type, will avoid separate work for registering an initial slate of subtypes, and will provide examples of what is considered a valid subtype for future subtype registrations. * The registration and actual use of a certain number of subtypes under the new top-level type should be expected. The existence of a single subtype should not be enough; it should be clear that new similar types may appear in the future. Otherwise, the creation of a new top-level type is likely unjustified. * The proposers of the new top-level type and the wider community should be willing to commit to emitting and consuming the new top- level type in environments that they control. * The fact that a group of (potential) types have (mostly) common parameters may be an indication that these belong under a common new top-level type. Nottingham & Resnick Expires 19 November 2025 [Page 17] Internet-Draft Media Type Registration May 2025 * Top-level types can help humans with understanding and debugging. Therefore, evaluating how a new top-level type helps humans understand types may be crucial. * Common restrictions may apply to all subtypes of a top-level type. Examples are the restriction to CRLF line endings for subtypes of type 'text' (at least in the context of electronic mail), or on subtypes of type 'multipart'. * Top-level types are also used frequently in dispatching code. For example "multipart/*" is frequently handled as multipart/mixed, without understanding of a specific subtype. The top-level types 'image', 'audio', and 'video' are also often handled generically. Documents with these top-level types can be passed to applications handling a wide variety of image, audio, or video formats. HTML generating applications can select different HTML elements (e.g. or