MEDIAMAN M.J. Dürst Internet-Draft Aoyama Gakuin University Updates: 6838 (if approved) 26 March 2023 Intended status: Best Current Practice Expires: 27 September 2023 Guidelines for the Definition of New Top-Level Media Types draft-ietf-mediaman-toplevel-03 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 27 September 2023. Copyright Notice Copyright (c) 2023 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 27 September 2023 [Page 1] Internet-Draft New Top-level Media Types March 2023 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 . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Rules for the Registration of New Top-Level Media Types . . . 3 2.1. Required Criteria . . . . . . . . . . . . . . . . . . . . 3 2.2. Additional Considerations . . . . . . . . . . . . . . . . 4 2.3. Negative Criteria . . . . . . . . . . . . . . . . . . . . 5 3. Top-Level Media Type History . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Changes from draft-ietf-mediaman-toplevel-01 Onwards . . . . . 8 Changes from draft-ietf-mediaman-toplevel-00 to draft-ietf-mediaman-toplevel-01 . . . . . . . . . . . . 8 Changes from draft-duerst-mediaman-toplevel-00 to draft-ietf-mediaman-toplevel-01 . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9 Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document defines best practices for defining new top-level media types. RFC 6838 (Media Type Specifications and Registration Procedures) only summarily gave criteria for defining additional top- level media types. This document provides more detailled criteria for defining additional top-level media types. It therefore updates RFC 6838 (Media Type Specifications and Registration Procedures). 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. Dürst Expires 27 September 2023 [Page 2] Internet-Draft New Top-level Media Types March 2023 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. In some older scenarios, it may also be 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 smart phones 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 for the Registration of New Top-Level Media Types This section describes the rules and criteria for new top-level media types, including criteria already defined in RFC 6838 (Media Type Specifications and Registration Procedures). Further work is needed to distinguish between required and optional criteria. 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. * Every new top-level type MUST be defined in a Standards Track RFC. 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. Dürst Expires 27 September 2023 [Page 3] Internet-Draft New Top-level Media Types March 2023 * The criteria for what types do and do not fall under the new top- level type need to 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 approriate 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. * The document defining the new top-level type MUST include initial registrations of actual subtypes. This will help to show the need for the new top-level type, will allow to check the appropriateness of the definition of the new top-level type, and will avoid separate work for registering an initial slate of subtypes. * The registration and actual use of a certain number of subtypes under the new top-level type SHOULD be expected. At a minimum, one actual subtype SHOULD exist. But 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. * Any RFC defining a new top-level type MUST clearly document the security considerations applying to all or a significant subset of subtypes. * 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. 2.2. Additional Considerations * Existing wide use of an undefined 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 undefined top-level types is highly discouraged. * Use of an IETF WG to define a new top-level type is not be 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 27 September 2023 [Page 4] Internet-Draft New Top-level Media Types March 2023 * 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 understading 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 media types 'image', 'audio', and 'video' are also often handled generically. Documents with these top-level media 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