MEDIAMAN M.J. Dürst Internet-Draft Aoyama Gakuin University Updates: 6838 (if approved) 5 July 2024 Intended status: Best Current Practice Expires: 6 January 2025 Guidelines for the Definition of New Top-Level Media Types draft-ietf-mediaman-toplevel-06 Abstract This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838. [RFC Editor, please remove this paragraph.] Comments and discussion about this document should be directed to media-types@ietf.org, the mailing list of the Media Type Maintenance (mediaman) WG. Alternatively, issues can be raised on GitHub at https://github.com/ ietf-wg-mediaman/toplevel. 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 6 January 2025. Copyright Notice Copyright (c) 2024 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. Dürst Expires 6 January 2025 [Page 1] Internet-Draft New Top-level Media Types July 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Rules and Criteria for the Registration of New Top-Level Media Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Required Criteria . . . . . . . . . . . . . . . . . . . . 3 2.2. Additional Considerations . . . . . . . . . . . . . . . . 4 2.3. Negative Criteria . . . . . . . . . . . . . . . . . . . . 6 3. Top-Level Media Type History . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. Registration of Top-level Media Types . . . . . . . . . . 8 4.2. Initialization of the Registry of Top-level Media Types . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Changes from draft-ietf-mediaman-toplevel-01 Onwards . . . . . 11 Changes from draft-ietf-mediaman-toplevel-00 to draft-ietf-mediaman-toplevel-00 . . . . . . . . . . . . 11 Changes from draft-duerst-mediaman-toplevel-00 to draft-ietf-mediaman-toplevel-01 . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction This document defines best practices for defining new top-level media types. Top-level media types ('top-level types' for short) appear to the left of the slash in a media type, examples being 'text/...', 'application/...', 'image/...', and so on. Please note that top- level types are different from trees (standards tree, vendor tree, personal tree), which (except for the standards tree) are indicated immediately to the right of the slash with a prefix of '.../vnd.' or '.../prs.'. RFC 6838 [RFC6838], Section 4.2.7 only summarily gave criteria for defining additional top-level types. This document provides more detailed criteria for defining additional top-level types. It therefore updates RFC 6838 [RFC6838]. Dürst Expires 6 January 2025 [Page 2] Internet-Draft New Top-level Media Types July 2024 1.1. Background New top-level types are rare enough and different enough from each other that each application needs to be evaluated separately. The main protocol extension point for media types are subtypes below each of the main types. For formats that do not fit below any other top- level type, the 'application' top-level type can always be used. The main function of media types and subtypes is the dispatch of data formats to application code. In most cases, this requires and is done using the full type (i.e. including the subtype, and often some parameters). The top-level type can occasionally serve as a fallback for the tentative dispatch to applications handling a very wide range of related formats. Please note that assumptions about the correctness of a media type must be made carefully, as it could be under the control of an attacker. In some older scenarios, it may also have been possible to identify a device (e.g. a phone for audio messages, a printer or fax device for images, a video recorder for videos, a computer for 'application' subtypes). However, the current hardware landscape, where computers and smartphones can handle a very wide variety of media, makes such a scenario look somewhat far-fetched. The top-level type can be used for user-directed information. Besides direct inspection of the type string by the user, this includes using different types of default icons for different top- level types. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Rules and Criteria for the Registration of New Top-Level Media Types This section describes the rules and criteria for new top-level types, including criteria already defined in RFC 6838 [RFC6838]. 2.1. Required Criteria The following is the list of required criteria for the definition of a new top-level type. Motivations for the requirements are also included. Dürst Expires 6 January 2025 [Page 3] Internet-Draft New Top-level Media Types July 2024 * Every new top-level type MUST be defined in a Standards Track RFC (see RFC 8126, Section 4.9 [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. * 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'. 2.2. Additional Considerations * Existing wide use of an unregistered top-level type may be an indication of a need, and therefore an argument for formally defining this new top-level type. * On the other hand, the use of unregistered top-level types is highly discouraged. * Use of an IETF WG 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 WG (RFC 2077 [RFC2077]), with a short, dedicated WG (RFC 8081 [RFC8081]), and with a WG that included other related work (draft-ietf-mediaman-haptics [HAPTICS]). Dürst Expires 6 January 2025 [Page 4] Internet-Draft New Top-level Media Types July 2024 * 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 most probably not justified. * 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. * Desirability for common parameters: 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. * 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. But as often with humans, opinions may widely differ. * 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