RFC 1590

RFC 1590: Media Type Registration Procedure ✨

• Network Working Group 🌸
• Author: J. Postel (Jon Postel), ISI (USC/Information Sciences Institute) 💖
• Date: March 1994 📅
• Category: Informational 🎀
• Updates: 1521 (RFC 1521) 🔥

Status of This Memo 💅

Okay so, this memo is just information for the Internet community 🌈. It does not specify an Internet standard of any kind, so it's not a standard, no cap. Distribution of this memo is unlimited, so share it with your whole group chat 🫶.

Abstract 🦋

Lots of protocols let you send different "media" like text, images, audio, and video. Inside each media there are different encoding styles too, like jpeg, gif, ief, and tiff for video. MIME [1] set up some first multimedia types and a way to register new ones with IANA, but people kept asking about the rules and admin steps for registering MIME content-types and subtypes, and about using Media Types in other apps. This doc answers those questions and lays out a procedure for registering new Media Types (content-type/subtypes) ✨. It also widens how these Media Types can be used, so the same registrations and specs can work with other applications 🧚.

1. Introduction 🌸

RFC 1521 [1] defines a registration procedure for new data types used with the Multimedia Internet Message Extensions (MIME) 💜. That system was built to make identifiers for a data type available and to stop naming conflicts. With all the new multimedia protocols and access mechanisms showing up, this could become a unified, general registration service for Internet Protocols, which is giving big main character energy 👑. These types, previously called "MIME Types", are now called "Media Types".

The registration process for Media Types (content-type/subtypes) started out in asynchronous mail environments. In mail, there's a need to limit how many Media Types exist so interoperability is more likely when you don't know what the remote mail system can handle 📮. As Media Types get used in new environments, where having lots of them isn't a hindrance to interoperability, the original procedure is way too restrictive and needs to be generalized 🙈.

This document answers the specific questions raised and gives an administrative procedure for registering Media Types. It also covers the registration requirements for mapping Object Identifiers (OIDs) for X.400 MHS use to Media Types 🍓.

2. Media Type Registration Procedure 🎀

The IANA has implemented the following procedure for reviewing and approving new Media Types. Honestly, it's not a formal standards process. It's an administrative procedure meant to get community comments and sanity checks without adding a ton of delay ⭐.

2.1 Present the Request for Registration to the Community 💌

Send a proposed Media Type (content-type/subtype) to the ietf-types@cs.utk.edu mailing list. That list exists for the sole purpose of reviewing proposed Media Types. Proposed content-types are not formally registered yet, and they must use the x- notation for the subtype name 🙈.

The whole point of the public posting is to get comments and feedback on the choice of content-type/subtype name, whether the references are unambiguous about versions and external profiling information, which OIDs to use, and a review of the security considerations section 🔍. It should be noted that the proposed Media Type doesn't need to make sense for every possible application. If the Media Type is meant for a limited or specific use, it should be noted in the submission ✨.

2.2 Submit the Content Type to the IANA for Registration 🫶

After two weeks, submit the proposed Media Type to the IANA for registration. The request and supporting documentation should be sent to iana@isi.edu. Once a reasonable review period has passed, the IANA will register the Media Type, assign an OID under the IANA branch, and make the registration available to the community 💖.

The Media Type registrations get posted in the anonymous FTP directory ftp.isi.edu:in-notes/media-types, and the Media Type will be listed in the periodically issued "Assigned Numbers" RFC [2] 📚. The Media Type description may be published as an Informational RFC by sending it to rfc-editor@isi.edu. Please follow the instructions to RFC authors [3] 🎀.

3. Clarifications On Specific Issues 🔥

3.1 MIME Requirements for a Limited Number of Content-Types 🧁

Issue: In the asynchronous mail environment, the sender doesn't have any info about the capabilities of the remote mail agent. So maximum interoperability was thought to come from restricting content-types to the "common" ones expected to be widely implemented. That reasoning was used to limit how many content-types could exist, and it made registration a process with a significant hurdle and delay for anyone registering content-types 😭.

Comment: Needing "common" content-type formats doesn't mean registration of new content-types has to be limited. That restriction may actually hinder interoperability, because separate registration authorities for specific applications could register values that conflict with or are otherwise incompatible with each other 💀. If a limited set of content-types is recommended for a particular application, that should be asserted by a separate applicability statement specific to the application and/or environment 🌸.

3.2 Requirements for a Published Specification 📜

Issue: Content-Type registration requires an RFC specifying the data format, or a reference to a published specification of the data stream. For file attachments and distribution, that might be overly restrictive, because a public specification may not exist for a bunch of widely used and exchanged objects 📎.

Comment: MIME required documentation of a specific content-type so the defined type could be identified unambiguously. That intent is met by identifying a particular software package and version when registering the content-type, and that is allowed for registration 💜. Using a Media Type whose specification isn't available should not be an issue in the registration 🦋.

3.3 Identification of Security Considerations 🔐

Issue: The registration process requires identifying any known security problems with the content-type.

Comment: The content-type doesn't have to be secure or risk-free. What matters is that the known risks get identified ✅. Publishing a content-type doesn't require an exhaustive security review, and the security considerations section is always open to continuing evaluation. Additional security considerations should be published periodically in an RFC by IANA 🛡️.

3.4. Recommendations and Standards Status 👑

Issue: Registering a data type doesn't imply endorsement, approval, or recommendation by IANA or IETF. It doesn't even certify that the specification is adequate 🙅.

Comment: To become Internet Standards, protocols, data objects, or whatever else must go through the IETF standards process. That's too difficult and too lengthy a process for the convenient, practical need to register Media Types 🐢. It's expected that applicability statements for particular applications will be published from time to time, recommending implementation of and support for data types that have proven particularly useful in those contexts 🌈.

4. Security Considerations 💀

Okay bestie, this one is serious 🫣. This memo does not address specific security issues. What it does is outline a security review process for Media Types, so please take it seriously 🔥.

5. Acknowledgements 🙈

Most of the words in this RFC were written by other people, primarily John Klensin and Greg Vaudreuil 🫶. My contribution was to slightly modify some sentences, delete some phrases, and rearrange some paragraphs. That means I am responsible for all the bad ideas and mangled English, and they deserve the credit (and, rightly, all the good ideas) 💅.

6. Author's Address 📮

Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA  90292

Phone: 310-822-1511
Fax:   310-823-6714
EMail: Postel@ISI.EDU

7. References 📚

[1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.

[3] Postel,J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993.

Appendix A -- IANA Registration Procedures for Media Types 👑

MIME was carefully designed with extensible mechanisms, and the set of content-type/subtype pairs and their associated parameters is expected to grow a lot over time 📈. Several other MIME fields, notably character set names, access-type parameters for the message/external-body type, and possibly even Content-Transfer-Encoding values, are likely to get new values defined over time 🌱.

In general, parameters in the content-type header field are used to convey supplemental information for various content types, and their use is defined when the content-type and subtype are defined. New parameters should not be defined as a way to introduce new functionality 🙅‍♀️.

To keep the content-type and subtype (that is, Media Type) values developed in an orderly, well-specified, and public manner, MIME and other applications use the registration process for Media Types defined in this RFC. That process uses the Internet Assigned Numbers Authority (IANA) as a central registry for these values 🗂️.

To simplify and standardize this Media Type registration process, this appendix gives templates for registering new values with IANA. Each one is an email message template, to be filled in by the registering party 💌.

Registration of New Content-type/subtype Values:

Note that MIME is generally expected to be extended by subtypes. If a new fundamental top-level type is needed, its specification must be published as an RFC or submitted in a form suitable to become an RFC, and be subject to the Internet standards process 🌟.

      ==================================================================

      To:  IANA@isi.edu
      Subject:  Registration of new Media Type content-type/subtype

      Media Type name:

      (If the above is not an existing top-level Media Type, please
      explain why an existing type cannot be used.)

      Media subtype name:

      Required parameters:

      Optional parameters:

      Encoding considerations:

      Security considerations:

      Published specification:

      (The published specification must be an Internet RFC or RFC-to-be
      if a new top-level type is being defined, and must be a publicly
      available specification in any case.)

      Person & email address to contact for further information:

      ==================================================================