idnits 2.17.1 draft-duerst-mediaman-toplevel-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6838]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 March 2022) is 754 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1341 (Obsoleted by RFC 1521) -- Obsolete informational reference (is this intentional?): RFC 2048 (Obsoleted by RFC 4288, RFC 4289) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF M.J. Dürst 3 Internet-Draft Aoyama Gakuin University 4 Updates: 6838 (if approved) 6 March 2022 5 Intended status: Best Current Practice 6 Expires: 7 September 2022 8 Guidelines for the Definition of New Top Level Media Types 9 draft-duerst-mediaman-toplevel-00 11 Abstract 13 The goal of this document is to identify best practices for defining 14 new top-level media types. It updates RFC 6838 [RFC6838], when 15 approved. Comments and discussion about this document should be 16 directed to media-types@ietf.org, the mailing list of the Media Type 17 Maintenance (mediaman) WG. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 7 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Top-Level Media Type History . . . . . . . . . . . . . . . . 2 55 3. Potential Criteria for New Top-Level Media Types . . . . . . 5 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 59 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Normative References . . . . . . . . . . . . . . . . . . . . . 6 61 Informative References . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 This document defines best practices for defining new top-level media 67 types. RFC 6838 [RFC6838] very consisely defines the conditions for 68 defining additional top-level media types. This document expands 69 this and therefore updates RFC 6838 [RFC6838]. 71 This document is currently a personal draft, but is intended for 72 adoption by the Media Type Maintenance (mediaman) IETF WG. Comments 73 and discussion about this document should be directed to that WG's 74 mailing list at media-types@ietf.org. 76 Currently, this document is a collection of information, ideas, and 77 text snippets that may be helpful in creating the actual 78 specification. None of the current language is intended to be final. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Top-Level Media Type History 88 This section shortly describes the history of top-level media types, 89 with a particular emphasis on the (rather rare) adoption of new top- 90 level types. 92 RFC 1341 [RFC1341] first defined the structuring of content types 93 into (top-level) type and subtype, and introduced the 'text', 94 'multipart', 'message', 'image', 'audio', 'video', and 'application' 95 top-level types. That specification also allowed top-level types 96 starting with 'X-'. With respect to new top-level types, it said the 97 following: 99 | An initial set of seven Content-Types is defined by this document. 100 | This set of top-level names is intended to be substantially 101 | complete. It is expected that additions to the larger set of 102 | supported types can generally be accomplished by the creation of 103 | new subtypes of these initial types. In the future, more top- 104 | level types may be defined only by an extension to this standard. 105 | If another primary type is to be used for any reason, it must be 106 | given a name starting with "X-" to indicate its non-standard 107 | status and to avoid a potential conflict with a future official 108 | name. 110 The first time an additional top-level type was defined was in RFC 111 1437 [RFC1437], but this was purely for entertainment purposes 112 (please check date). 114 RFC 2046 [RFC2046] discouraged the use of "X-" for (new) top-level 115 types, with the following words: 117 | In general, the use of "X-" top-level types is strongly 118 | discouraged. Implementors should invent subtypes of the existing 119 | types whenever possible. In many cases, a subtype of 120 | "application" will be more appropriate than a new top-level type. 122 RFC 2048 [RFC2048], published at the same time as RFC 2046 [RFC2046], 123 defined requirements for the definition of new top-level types: 125 | In some cases a new media type may not "fit" under any currently 126 | defined top-level content type. Such cases are expected to be 127 | quite rare. However, if such a case arises a new top-level type 128 | can be defined to accommodate it. Such a definition must be done 129 | via standards-track RFC; no other mechanism can be used to define 130 | additional top-level content types. 132 >RFC 4735 [RFC4735] introduced the 'example' top-level type for use 133 in documentation examples. 135 At some point, the 'model' top-level type was introduced. Any 136 pointers to the defining document are greatly appreciated. 138 The 'font' top-level media type was defined in RFC 8081 [RFC8081], a 139 work of the 'justfont' IETF WG, in 2017. 141 There is ongoing work on defining a new 'haptics' top-level media 142 type in draft-ietf-mediaman-haptics [HAPTICS]. 144 Wikipedia (at https://en.wikipedia.org/wiki/Media_type) reports the 145 unofficial use of a 'chemical' top-level type. 147 The document currently defining the requirements for new top-level 148 media types is RFC 6838 [RFC6838]. Because we are trying to update 149 what it says, we are citing the two relevant sections, Section 4.2.5 150 and Section 4.2.7, here. 152 | 4.2.5. Application Media Types 153 | 154 | The "application" top-level type is to be used for discrete data 155 | that do not fit under any of the other type names, and 156 | particularly for data to be processed by some type of application 157 | program. This is information that must be processed by an 158 | application before it is viewable or usable by a user. Expected 159 | uses for the "application" type name include but are not limited 160 | to file transfer, spreadsheets, presentations, scheduling data, 161 | and languages for "active" (computational) material. (The last, 162 | in particular, can pose security problems that must be understood 163 | by implementors. The "application/postscript" media type 164 | registration in [RFC2046] provides a good example of how to handle 165 | these issues.) 166 | 167 | For example, a meeting scheduler might define a standard 168 | representation for information about proposed meeting dates. An 169 | intelligent user agent would use this information to conduct a 170 | dialog with the user, and might then send additional material 171 | based on that dialog. More generally, there have been several 172 | "active" languages developed in which programs in a suitably 173 | specialized language are transported to a remote location and 174 | automatically run in the recipient's environment. Such 175 | applications may be defined as subtypes of the "application" top- 176 | level type. 177 | 178 | The subtype of "application" will often either be the name or 179 | include part of the name of the application for which the data are 180 | intended. This does not mean, however, that any application 181 | program name may simply be used freely as a subtype of 182 | "application"; the subtype needs to be registered. 184 | 4.2.7. Additional Top-Level Types 185 | 186 | In some cases, a new media type may not "fit" under any currently 187 | defined top-level type names. Such cases are expected to be quite 188 | rare. However, if such a case does arise, a new type name can be 189 | defined to accommodate it. Definition of a new top-level type 190 | name MUST be done via a Standards Track RFC; no other mechanism 191 | can be used to define additional type names. 193 The two sections above are not strictly aligned, because the first 194 says anything that doesn't go under a more specific type can go under 195 the 'application' top-level type, while the later section allows for 196 new top-level types. 198 3. Potential Criteria for New Top-Level Media Types 200 This section describes potential criteria for new top-level media 201 types, including criteria already defined in RFC 6838 [RFC6838]. 202 Further work is needed to distinguish between required and optional 203 criteria. But it is possible that we end up with just "we didn't 204 find any objective criteria for new top-level types, and we will stop 205 looking for such criteria". 207 * New top level types are rare enough and different enough that each 208 application needs to be evaluated separately. 210 * Need to be documented in a Standards Track RFC. 212 * This Standards Track RFC should include initial registrations of 213 actual types. 215 * May (or may not) need an IETF WG for definition. 217 * Existence of a certain number of subtypes that would be grouped 218 under the new top-level type. At a minimum, one actual subtype 219 should exist. But the existence of a single subtype should not be 220 enough; it should be clear that new similar types may appear in 221 the future. 223 * Existing wide use of an undefined top-level type may be an 224 indication of a need, and therefore an argument for formally 225 defining this new top-level type. 227 * On the other hand, the use of undefined top-level types is highly 228 discouraged. 230 * Top-level types mostly help humans; it is unclear to what extent 231 top-level types are used by applications directly, as opposed to 232 application dispatching and behavior triggered by the type/subtype 233 combination. [More information needed/appreciated here.] 234 Therefore, evaluating how a new top-level type helps humans 235 understand types may be crucial. But as often with humans, 236 opinions may widely differ. 238 * Need for clear criteria for what types do and don't fall under the 239 new top-level type. 241 * Desirability for common parameters: The fact that a group of 242 (potential) types have (mostly) common parameters may be an 243 indication that these belong under a common (new) top-level type. 245 4. IANA Considerations 247 There is currently no registry of top-level media types, but the list 248 of top-level types available for registering subtypes is available at 249 https://www.iana.org/assignments/media-types/media-types.xhtml. 251 There may be a question of whether there is a need for a formal 252 registry of top-level types. Such a registry might contain pointers 253 to the definitions of the top-level types. As a concrete example, 254 the author of this document has not yet been able to find the 255 definition of the 'model' top level type. 257 5. Security Considerations 259 This document as such is not expected to introduce any security 260 issues. The security issues of introducing a new top-level media 261 type MUST be evaluated and documented carefully. 263 Acknowledgements 265 The initial encouragement for writing this draft came from Harald 266 Alvestrand. Further encouragement was provided by Murray S. 267 Kucherawy. Both Harald and Murray also provided ideas for actual 268 text. Without them, this memo would never have reached even the 269 first draft stage. 271 References 273 Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 281 Specifications and Registration Procedures", BCP 13, 282 RFC 6838, DOI 10.17487/RFC6838, January 2013, 283 . 285 Informative References 287 [HAPTICS] Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-level 288 Media Type", RFC XXXX, . 291 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 292 Mail Extensions): Mechanisms for Specifying and Describing 293 the Format of Internet Message Bodies", RFC 1341, 294 DOI 10.17487/RFC1341, June 1992, 295 . 297 [RFC1437] Borenstein, N. and M. Linimon, "The Extension of MIME 298 Content-Types to a New Medium", RFC 1437, 299 DOI 10.17487/RFC1437, April 1993, 300 . 302 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 303 Extensions (MIME) Part Two: Media Types", RFC 2046, 304 DOI 10.17487/RFC2046, November 1996, 305 . 307 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 308 Internet Mail Extensions (MIME) Part Four: Registration 309 Procedures", RFC 2048, DOI 10.17487/RFC2048, November 310 1996, . 312 [RFC4735] Taylor, T., "Example Media Types for Use in 313 Documentation", RFC 4735, DOI 10.17487/RFC4735, October 314 2006, . 316 [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081, 317 DOI 10.17487/RFC8081, February 2017, 318 . 320 Author's Address 322 Martin J. Dürst 323 Aoyama Gakuin University 324 Fuchinobe 5-10-1, Chuo-ku, Sagamihara, Kanagawa 325 252-5258 326 Japan 327 Phone: +81 42 759 6329 328 Email: duerst@it.aoyama.ac.jp 329 URI: https://www.sw.it.aoyama.ac.jp/D%C3%BCrst/