RFC 4288

Media Type Specifications and Registration Procedures

📅 published December 2005, from ietf

RFC 4288: Media Type Specifications and Registration Procedures 🎀

Okay bestie, let's get into it 🌸 This is RFC 4288, a Best Current Practice (it's BCP 13 💅), and the title is Media Type Specifications and Registration Procedures. It came out in December 2005 from the Network Working Group. The authors are N. Freed of Sun Microsystems and J. Klensin 👑 It Obsoletes: 2048, so it replaces RFC 2048 as the go-to. It doesn't update anything else.

Status of This Memo ✨

This document specifies an Internet Best Current Practice for the Internet Community 🌈 It also asks everyone to chat about it and send suggestions for improvements 💬 Distribution of this memo is unlimited, so share it with whoever 🫶

Copyright (C) The Internet Society (2005).

Abstract 🦋

This doc lays out how to specify and register media types 💖 They're for use in MIME and other Internet protocols, so it's kind of the rulebook for labeling stuff ✨

Table of Contents 📚

1. Introduction ....................................................3
2. Media Type Registration Preliminaries ...........................4
3. Registration Trees and Subtype Names ............................4
   3.1. Standards Tree .............................................4
   3.2. Vendor Tree ................................................5
   3.3. Personal or Vanity Tree ....................................5
   3.4. Special x. Tree ............................................5
   3.5. Additional Registration Trees ..............................6
4. Registration Requirements .......................................6
   4.1. Functionality Requirement ..................................6
   4.2. Naming Requirements ........................................6
      4.2.1. Text Media Types ......................................7
      4.2.2. Image Media Types .....................................8
      4.2.3. Audio Media Types .....................................8
      4.2.4. Video Media Types .....................................8
      4.2.5. Application Media Types ...............................9
      4.2.6. Multipart and Message Media Types .....................9
      4.2.7. Additional Top-level Types ............................9
   4.3. Parameter Requirements ....................................10
   4.4. Canonicalization and Format Requirements ..................10
   4.5. Interchange Recommendations ...............................11
   4.6. Security Requirements .....................................11
   4.7. Requirements specific to XML media types ..................13
   4.8. Encoding Requirements .....................................13
   4.9. Usage and Implementation Non-requirements .................13
   4.10. Publication Requirements .................................14
   4.11. Additional Information ...................................15
5. Registration Procedure .........................................15
   5.1. Preliminary Community Review ..............................16
   5.2. IESG Approval .............................................16
   5.3. IANA Registration .........................................16
   5.4. Media Types Reviewer ......................................16
6. Comments on Media Type Registrations ...........................17
7. Location of Registered Media Type List .........................17
8. IANA Procedures for Registering Media Types ....................17
9. Change Procedures ..............................................18
10. Registration Template .........................................19
11. Security Considerations .......................................20
12. IANA Considerations ...........................................20
13. Acknowledgements ..............................................20
14. References ....................................................20
Appendix A.  Grandfathered Media Types ............................22
Appendix B.  Changes Since RFC 2048 ...............................22

1. Introduction 🧚

Recent Internet protocols were designed to be super extensible in certain areas 🔥 Lots of them, MIME [RFC2045] included (but not limited to it), can carry arbitrary labeled content 🍓 So we need a way to label that content, plus a registration process for those labels. That way the whole set of values gets developed in an orderly, well-specified, and public way 📋

This document defines media type specification and registration procedures that use the Internet Assigned Numbers Authority (IANA) as a central registry 🏛️

Historical Note 🕰️

Okay, history time 📜 The media type registration process was first defined for the asynchronous Internet mail environment. In that mail world, 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 🙈 But once media types started being used in new environments where having lots of them wasn't a hindrance to interoperability, the original procedure turned out to be excessively restrictive and had to be generalized. This was first done in [RFC2048], but the procedure there was still part of the MIME document set. Now the media type specification and registration procedure has its own separate document, to make it clear that it's independent of MIME 💜

It may be desirable to restrict the use of media types to specific environments, or to prohibit their use in other environments. This revision attempts, for the first time, to build such restrictions into media type registrations in a systematic way 🎯 See Section 4.9 for additional discussion.

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].

This specification makes use of the Augmented Backus-Naur Form (ABNF) [RFC4234] notation, including the core rules defined in Appendix A of that document 🌸

2. Media Type Registration Preliminaries 📮

Registering a new media type (or types) starts with building a registration proposal ✍️ Registration can happen within several different registration trees, and those trees have different requirements, as we'll see below. In general, a new registration proposal gets circulated and reviewed in a way that fits the tree it's in. If the proposal is acceptable, the media type gets registered 🎉 The following sections describe the requirements and procedures for each of the different registration trees.

3. Registration Trees and Subtype Names 🌳

To make the registration process more efficient and flexible, different structures of subtype names can be registered to match different natural needs 🦋 For example, you might have a subtype that's recommended for wide support across the Internet community, or one that's used to move files tied to proprietary software. The subsections below define registration "trees" that are told apart by faceted names, like names of the form "tree.subtree...subtype" 🧩 Some media types defined before this document don't follow these naming conventions, so check out Appendix A if you're curious about those 👀

3.1. Standards Tree 🏆

The standards tree is for types of general interest to the Internet community 🌍 Registrations in the standards tree MUST be approved by the IESG and MUST correspond to a formal publication by a recognized standards body 👑 For registration done for the IETF itself, the registration proposal MUST be published as an RFC 📄 Standards-tree registration RFCs can either be standalone "registration only" RFCs, or they can be folded into a more general specification of some sort ✨

Media types in the standards tree are normally named without explicit facets, which means their names don't contain period (".", full stop) characters 💅

The "owner" of a standards tree registration is assumed to be the standards body itself 🏢 Changing or altering the specification takes the same level of processing (e.g., standards track) as the initial registration did 🔁

3.2. Vendor Tree 🛍️

The vendor tree is for media types tied to commercially available products. "Vendor" or "producer" are treated as equivalent and very broadly in this context 💼

Anyone who needs to interchange files for a particular product can place a registration in the vendor tree 🫶 But the registration formally belongs to the vendor or organization that produces the software or file format being registered. Changes to the specification will be made at their request, as discussed in later sections 💖

Vendor tree registrations are marked by the leading facet "vnd." 🌈 After that, the registrant decides whether to use a media subtype name from a well-known producer (e.g., "vnd.mudpie") or an IANA-approved designation of the producer's name followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures) 🍭

Public exposure and review of media types to be registered in the vendor tree is not required 🙌 Still, using the ietf-types@iana.org mailing list for review is strongly encouraged, since it improves the quality of those specifications ✨ Vendor tree registrations may be submitted directly to the IANA 🏛️

3.3. Personal or Vanity Tree 💅

Media types created experimentally, or as part of products that aren't distributed commercially, can be registered in the personal or vanity tree 🧁 These are marked by the leading facet "prs." 🎀

The owner of "personal" registrations and their associated specifications is the person or entity who made the registration, or someone that responsibility was transferred to as described below 🪞

Public exposure and review of media types to be registered in the personal tree is not required 🙌 But using the ietf-types list for review is strongly encouraged, because it improves the quality of those specifications 💜 Personal tree registrations may be submitted directly to the IANA 🏛️

3.4. Special x. Tree 🦄

For convenience and symmetry with this registration scheme, subtype names with "x." as the first facet can be used for the same purposes that names starting with "x-" are used for 🧚 These types are unregistered and experimental, and they're only for use with the active agreement of the parties exchanging them 🤝

Here's the tea 🍵 With the simplified registration procedures described above for the vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, using both the "x-" and "x." forms is discouraged 🙅‍♀️

Types in this tree MUST NOT be registered 🚫

To be continued... Part 2 is coming next, bestie 💖🦋

3.5. Additional Registration Trees 🌈

okay so from time to time, when the community actually needs it, IANA can (with the advice and consent of the IESG 💅) create brand new top-level registration trees. 🦋 it's explicitly assumed these trees could be handed over for outside registration and management to well-known permanent bodies. like, scientific societies could register media types for the sciences they cover 🧪 ngl that's iconic. the review quality for specs in one of these extra trees is expected to be on par with the standards tree ✨ and whenever a new tree is set up, it gets announced through an RFC publication that the IESG approves 📣

4. Registration Requirements 🎀

bestie, every media type registration proposal is expected to follow the various requirements in the sections below 💖 just know that the specifics can shift depending on which registration tree you're in, and the following sections spell that out too 🧚

4.1. Functionality Requirement 💅

media types MUST function as an actual media format 🔥 registering things that are better thought of as a transfer encoding, a charset, or a bunch of separate entities of another type is not allowed 🙅‍♀️ for example, there are apps that can decode the base64 transfer encoding [RFC2045], but base64 cannot be registered as a media type 💀

this requirement applies no matter which registration tree is involved 🌸

4.2. Naming Requirements 🦋

all registered media types MUST be assigned type and subtype names 💖 the combo of those names is what uniquely identifies the media type, and the format of the subtype name tells you which registration tree it lives in 🌳 both type and subtype names are case-insensitive, so no drama there ✨

type and subtype names beginning with "X-" are reserved for experimental use and MUST NOT be registered 🙈 this mirrors the restriction on the x. tree, which we talked about in Section 3.4 🫶

type and subtype names MUST conform to the following ABNF:

    type-name = reg-name
    subtype-name = reg-name

    reg-name = 1*127reg-name-chars
    reg-name-chars = ALPHA / DIGIT / "!" /
                    "#" / "$" / "&" / "." /
                    "+" / "-" / "^" / "_"

note that this syntax is a bit stricter than what [RFC2045] allows in its ABNF 🧐

okay this part is important: following the rules in [RFC3023], media subtypes that do NOT represent XML entities MUST NOT be given a name ending with the "+xml" suffix 🚫 more generally, "+suffix" constructs should be used with care, because future suffix definitions could clash with them 😬

while one media type can be given more than one name, using different names for the same media type is discouraged 🙅‍♀️

these requirements apply no matter which registration tree is involved 💜

the choice of top-level type name MUST take the nature of the media type into account 👑 new subtypes of top-level types MUST conform to that top-level type's restrictions, if it has any 🍓 the next sections walk through each of the initial top-level types and their restrictions 🧚 also, various protocols, including but not limited to MIME, MAY impose extra restrictions on the media types they can carry (see [RFC2046] for more on the restrictions MIME imposes) 📬

4.2.1. Text Media Types 📝

the "text" media type is meant for stuff that's mainly textual 💕 a "charset" parameter MAY be used to say which charset the body text uses for "text" subtypes, and that includes "text/plain", the generic plain-text subtype defined in [RFC2046] 🌷 if a text "charset" parameter is defined, it MUST name a charset that's defined following the procedures in [RFC2978] ✅

plain text doesn't do formatting commands, font attributes, processing instructions, interpretation directives, or content markup 🙅‍♀️ it's just a linear sequence of characters, maybe broken up by line breaks or page breaks 📄 plain text MAY allow stacking several characters in the same position 🌀 and plain text in scripts like Arabic and Hebrew may also have facilities for mixing text segments that run in opposite writing directions ↔️

beyond plain text, there are tons of formats for "rich text" 💅 what's interesting is that a lot of them are kinda readable even without the software that interprets them 👀 so it's useful to split them out at the highest level from stuff like images, audio, or text in an unreadable form 🧩 without the right interpretation software, it's reasonable to show "text" subtypes to the user, but it's NOT reasonable to do that with most non-textual data 🙈 formatted textual data should be represented using subtypes of "text" 🎀

4.2.2. Image Media Types 🖼️

a media type of "image" means the content specifies one or more separate images that need appropriate hardware to display 🌈 the subtype names the specific image format ✨

4.2.3. Audio Media Types 🎧

a media type of "audio" means the content contains audio data 🎶

4.2.4. Video Media Types 🎬

a media type of "video" means the content specifies a time-varying picture image, possibly with color and coordinated sound 🍿 "video" is used in its most generic sense, not tied to any particular technology or format, and it isn't meant to rule out subtypes like compactly encoded animated drawings 🦋

ngl, this doc really discourages mixing multiple media in a single body 🙅‍♀️ but it's recognized that a lot of so-called video formats include a representation for synchronized audio and/or text, and that's explicitly allowed for "video" subtypes 🫶

4.2.5. Application Media Types 💻

the "application" media type is for discrete data that doesn't fit any of the other media types, especially data meant to be processed by some kind of application program 🧠 this is info an application has to process before a user can view or use it 📊 expected uses include (but aren't limited to) file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material 🔥 (the last one is a big deal because it can pose security problems that implementors need to understand, and it's covered in detail in the discussion of the "application/PostScript" media type in [RFC2046] 🔐)

for example, a meeting scheduler might define a standard way to represent info about proposed meeting dates 📅 an intelligent user agent could use that info to have a little chat with the user, then maybe send more stuff based on that convo 💬 there have also been several "active" languages where programs get shipped to a remote location and auto-run in the recipient's environment 🤖 those can be defined as subtypes of "application" 💖

the subtype of "application" is often the name, or part of the name, of the application the data is meant for 🎯 but that does NOT mean any application program name can be used freely as a subtype of "application" 🙅‍♀️

4.2.6. Multipart and Message Media Types 📦

multipart and message are composite types, which means they're a way to wrap up zero or more objects, each labeled with its own media type 🎁

all subtypes of multipart and message MUST conform to the syntax rules and other requirements in [RFC2046] 📜

4.2.7. Additional Top-level Types 🌟

sometimes a new media type doesn't "fit" under any currently defined top-level content type 🤷‍♀️ that's expected to be super rare 😭 but if it does happen, a new top-level type can be defined to accommodate it 🙌 that definition MUST be done via a standards-track RFC, and no other mechanism can be used to define additional top-level content types 🚫

4.3. Parameter Requirements 🎀

media types MAY choose to use one or more media type parameters 💖 or some parameters might be automatically available to the media type just by being a subtype of a content type that defines a set of parameters for any of its subtypes 🧚 either way, the names, values, and meanings of any parameters MUST be fully specified when the 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 follow the same syntax as media type names and values:

    parameter-name = reg-name

note that this syntax is a bit stricter than what [RFC2045] allows, and it's amended by [RFC2231] too 🧐

there's no defined syntax for parameter values 🤷‍♀️ so registrations MUST specify parameter value syntax 📝 some transports also impose restrictions on parameter value syntax, so take care to limit the use of potentially problematic syntaxes 🧠 e.g., pure binary valued parameters are permitted in some protocols, but they probably should be avoided 🙅‍♀️

new parameters SHOULD NOT be defined as a way to add new functionality to types registered in the standards tree 🚫 however, new parameters MAY be added to convey extra info that doesn't otherwise change existing functionality 💡 an example is a "revision" parameter that indicates a revision level of an external spec like JPEG 📷 similar behavior is encouraged for media types in the vendor or personal trees, but it isn't required 🌸

4.4. Canonicalization and Format Requirements 📐

all registered media types MUST use a single, canonical data format, no matter which registration tree they're in 🔒

a precise and openly available spec of each media type's format MUST exist for all types registered in the standards tree 📖 it MUST, at a minimum, be referenced by the media type registration proposal itself, even if it isn't actually included in it 🔗

the format and processing specs for media types in the vendor tree may or may not be publicly available, and those registration proposals are explicitly allowed to limit the spec to which software and version produce or process such media types 🏢 referencing or including format specs in registration proposals is encouraged but NOT required 💅

format specs are still required for registration in the personal tree 🫶 but they may be published as RFCs or otherwise deposited with IANA 📬 the deposited specs will meet the same criteria as those required to register a well-known TCP port and, in particular, don't need to be made public 🤫

some media types involve patented technology 💰 registering media types involving patented technology is specifically permitted ✅ however, the restrictions set forth in [RFC2026] on using patented technology in IETF standards-track protocols must be respected when a media type's spec is part of a standards-track protocol ⚖️ also, other standards bodies that use the standards tree may have their own IP rules that must be observed in their registrations 🌈

4.5. Interchange Recommendations 🌸

okay bestie, media types SHOULD interoperate across as many systems and apps as possible 💖 but ngl some of them are gonna beef across platforms no matter what. Different versions, byte ordering, and the specifics of gateway handling can and will cause problems 😭

Universal interoperability is not required 🙈, but known interoperability issues SHOULD be identified whenever possible ✨. Publishing a media type doesn't need an exhaustive interop review, and the interoperability considerations section keeps getting re-evaluated over time 🦋.

These recommendations apply regardless of which registration tree is involved 💅.

4.6. Security Requirements 🔐

an analysis of security issues MUST be done for every type registered in the standards tree 👑. A similar analysis for types in the vendor or personal trees is encouraged, but it's not required. Either way, all descriptions of security issues MUST be as accurate as possible, no matter the tree 💯. Also, a statement that there are "no security issues associated with this type" MUST NOT be confused with "the security issues associates with this type have not been assessed" 🙃. Those are two very different vibes!!

there's absolutely no requirement that media types be secure or totally risk-free 🫶. Still, all known security risks MUST be identified in the registration of a media type, again regardless of tree 🚨.

the security considerations section of every registration is subject to continuing evaluation and modification, and it MAY be extended through the "comments on media types" mechanism described in Section 6 below 🌈.

some of the things you should look at in a security analysis of a media type:

  • complex media types may include directives that carry out actions on a recipient's files or other resources. often they let the originator specify arbitrary actions with no restrictions, which can have devastating effects 💀. See the registration of the application/postscript media type in [RFC2046] for an example of these directives and how they should be described in a registration.
  • ALL registrations MUST state whether or not they use this kind of "active content" 🧨. If they do, they MUST state what steps were taken to protect users of the media type from harm 🛡️.
  • complex media types may also include directives that carry out actions which aren't directly harmful to the recipient, but could still disclose information that helps a later attack or violates a recipient's privacy 🕵️. Once again, the registration of the application/postscript media type shows how these can be handled.
  • a media type that uses compression may give an attacker a way to send a small amount of data that, once received and evaluated, expands enormously and eats all of the recipient's resources 🍿. All media types SHOULD state whether or not they use compression, and if they do, they should discuss what steps need to be taken to avoid these attacks.
  • a media type might be aimed at applications that need some kind of security assurance but don't provide the necessary security mechanisms themselves 🤷‍♀️. For example, a media type could be defined for storing confidential medical information that depends on an external confidentiality service, or that is designed for use only inside a secure environment.

4.7. Requirements specific to XML media types 📜

there are a bunch of extra requirements that only apply when registering XML media types 🧡. Those are specified in [RFC3023].

4.8. Encoding Requirements 🔤

some transports restrict what kinds of data they can carry. For example, internet mail used to be limited to 7bit US-ASCII text 📧. Encoding schemes are often used to get around these transport limits 🎁.

So it's useful to note, as part of a registration, what sort of data a media type can consist of. There's an "encoding considerations" field just for this 📝. The possible values of this field are:

  • 7bit: the content consists solely of CRLF-delimited 7bit US-ASCII text.
  • 8bit: the content 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 with no internal framing or alignment indicators 🧩. Extra out-of-band information is needed to interpret the data properly, including (but not necessarily limited to) knowing where the boundaries between successive frames are and knowing the transport mechanism. Be careful with this one: media types like this can't just be stored in a file or sent as a simple stream of octets, so they're unsuitable for lots of traditional protocols 🚫. A commonly used transport with framed encoding is the Real-time Transport Protocol, RTP. Additional rules for framed encodings used with RTP are given in [RFC3555].

Additional restrictions on 7bit and 8bit text are given in [RFC2046].

4.9. Usage and Implementation Non-requirements 🙅‍♀️

in asynchronous mail, the sender often has no idea what the remote mail agent can handle 📬. Back then, the way to get maximum interoperability was to stick to "common" formats that were expected to be widely implemented 🙄. People assumed that meant capping how many media types could exist, and that made registration a whole process with a big hurdle and lots of delay 😩.

but needing "common" media types doesn't mean you have to limit new registrations 💫. If a small set of media types is recommended for a particular application, that should be stated in a separate applicability statement written for that application and/or environment 📋.

So universal support and implementation of a media type is NOT a requirement for registration 🌟. However, if a media type is explicitly meant for limited use, this MUST be noted in its registration 🚧. The "Restrictions on Usage" field exists for exactly that purpose.

4.10. Publication Requirements 📚

proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs 🎓. RFC publication for vendor and personal media type proposals is encouraged but not required. In every case, the IANA keeps copies of all media type proposals and "publishes" them as part of the media types registration tree itself 🗂️.

as mentioned before, standards tree registrations for media types defined in documents produced by other standards bodies MUST be described by a formal standards specification from that body 🏛️. Those specifications MUST contain an appropriate media type registration template taken from Section 10 💅. On top of that, the copyright on the registration template MUST allow the IANA to copy it into the IANA registry 🔓.

apart from IETF registrations in the standards tree, registering a data type doesn't mean the IANA or the IETF endorses, approves, or recommends it. It doesn't even certify that the specification is adequate 🙅‍♀️. To become Internet Standards, a protocol or data object has to go through the IETF standards process, but that's way too difficult and lengthy for convenient media type registration 🐢.

the standards tree is for media types that do need a substantive review and approval process in a recognized standards body 🧐. The vendor and personal trees are for media types that don't need that process 🌷. It's expected that applicability statements for particular applications will be published in the IETF from time to time, recommending implementation of, and support for, media types that have proven especially useful in those contexts 🦋.

As discussed above, registering a top-level type requires standards-track processing in the IETF and, therefore, RFC publication 🎀.

4.11. Additional Information ✨

all kinds of optional info SHOULD be included in the specification of a media type if it's available 🌈:

  • magic number(s) (length, octet values). Magic numbers are byte sequences that are always present at a given place in a file, so they can be used to identify entities as being a given media type 🔍.
  • file name extension(s) commonly used on one or more platforms to indicate that a file contains a given media type 📁.
  • Mac OS File Type code(s) (4 octets) used to label files containing a given media type 🍎.
  • information about how fragment/anchor identifiers [RFC3986] are constructed for use with this media type 🔗.

For a registration in the standards tree, this additional information MAY be provided in the formal specification of the media type 🧾. It's suggested that you do this by putting the IANA media type registration form right into the specification itself 💜.

5. Registration Procedure 🚦

the media type registration procedure isn't a formal standards process 🙌. It's more of an administrative procedure meant to allow community comments and sanity checks without a ton of delay ⏰.

the normal IETF processes should be followed for all IETF registrations in the standards tree 🏃‍♀️. Posting an Internet Draft is a necessary first step, followed by posting to the ietf-types@iana.org list as discussed below 📮.

Registrations in the vendor and personal trees should be submitted directly to the IANA, ideally after first posting to the ietf-types@iana.org list for review 💌.

Proposed registrations in the standards tree by other standards bodies should be communicated to the IESG (at iesg@ietf.org) and to the ietf-types list (at ietf-types@iana.org) 📣. Posting as an Internet Draft beforehand is not required for these, but it may be helpful to the IESG and is encouraged 🫶.

5.1. Preliminary Community Review 👀

notice of a potential media type registration in the standards tree MUST be sent to the "ietf-types@iana.org" mailing list for review 📬. That list was set up specifically to review proposed media and access types 🧚. Registrations in other trees MAY be sent to the list for review too 💖.

posting to the list is meant to gather comments and feedback on the choice of type/subtype name, whether the references are unambiguous with respect to versions and external profiling information, and to review any interoperability or security considerations 🔎. The submitter can submit a revised registration or abandon the registration completely at any time 🫠.

5.2. IESG Approval 🏁

media types registered in the standards tree MUST be approved by the IESG prior to registration 👑✨.

5.3. IANA Registration ✨

Once the media type meets every relevant requirement and has collected whatever approval it needs, the author can send the registration request to the IANA 💌 Requests can go to iana@iana.org, or you can use the web form if clicking is more your thing:

http://www.iana.org/cgi-bin/mediatypes.pl

Heads up, bestie 🙅‍♀️ sending to ietf-types@iana.org does not count as submitting the registration to the IANA. That list is for discussion, not submission.

When the registration is part of an RFC publication request, or a registration in the standards tree that goes to the IESG, the IANA and the IESG are so tight that IESG approval actually submits it to the IANA for you 🤝 No extra registration request needed, periodt.

5.4. Media Types Reviewer 👩‍💻

Registrations sent to the IANA get passed to the media types reviewer 🎀 This person is appointed by the IETF Applications Area Director(s), and their job is to check that the registration meets the requirements in this document.

If a registration doesn't pass, it gets sent back to the submitter for revision. No shade, just edits 💅

Decisions made by the media types reviewer can be appealed to the IESG using the procedure specified in [RFC2026] section 6.5.4.

Once a media type registration passes review, the IANA registers it and makes it available to the community 🎉

6. Comments on Media Type Registrations 💬

Community members can submit comments on registered media types to the IANA. The media types reviewer looks them over and then passes them on to the "owner" of the media type if possible 🫶 Commenters can ask for their comment to be attached to the media type registration itself. If the IANA approves, the comment becomes accessible alongside the type registration 🧾

7. Location of Registered Media Type List 📍

The IANA lists media type registrations at:

http://www.iana.org/assignments/media-types/

8. IANA Procedures for Registering Media Types 🛠️

The IANA will only register media types in the standards tree in response to a communication from the IESG stating that a given registration has been approved. Vendor and personal types get registered by the IANA automatically, with no formal approval process, as long as the following minimal conditions are met:

  • Media types MUST function as an actual media format. In particular, charsets and transfer encodings MUST NOT be registered as media types.
  • All media types MUST have properly formed type and subtype names. All type names MUST be defined by a standards-track RFC. All type/subtype name pairs MUST be unique and MUST contain the proper tree prefix.
  • Types registered in the personal tree MUST either provide a format specification or a pointer to one.
  • All media types MUST have a reasonable security considerations section. (It is neither possible nor necessary for the IANA to conduct a comprehensive security review of media type registrations. Nevertheless, the IANA has the authority to identify obviously incompetent material and return it to the submitter for revision.)

Registrations in the standards tree MUST satisfy the additional requirement that they originate from the IETF itself or from another standards body recognized as such by the IETF 🏛️

9. Change Procedures 🔄

Once the IANA has published a media type, the owner can request a change to its definition. The descriptions of the different registration trees above say who the "owners" are for each type of registration 👑 The same procedure that would fit the original registration request gets used to process a change request.

Changes should be requested only when there are serious omissions or errors in the published specification. When review is required, a change request may be denied if it makes entities that were valid under the previous definition invalid under the new definition.

The owner of a media type can pass responsibility to another person or agency by informing the IANA and the ietf-types list. This can be done without discussion or review, so easy 🦋

The IESG may reassign responsibility for a media type. The most common case will be when the registration's author has died, moved out of contact, or is otherwise unable to make changes that matter to the community 🕊️

Media type registrations may not be deleted. Media types that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field, and such media types will be clearly marked in the lists published by the IANA 🪦

10. Registration Template 📝

Here's the template, exactly as it's meant to be filled in:

To: ietf-types@iana.org
Subject: Registration of media type XXX/YYY

Type name:

Subtype name:

Required parameters:

Optional parameters:

Encoding considerations:

Security considerations:

Interoperability considerations:

Published specification:

Applications that use this media type:

Additional information:

  Magic number(s):
  File extension(s):
  Macintosh file type code(s):

Person & email address to contact for further information:

Intended usage:

(One of COMMON, LIMITED USE or OBSOLETE.)

Restrictions on usage:

(Any restrictions on where the media type can be used go here.)

Author:

Change controller:

(Any other information that the author deems interesting may be added
below this line.)

Some discussion of Macintosh file type codes and their purpose can be found in [MacOSFileTypes]. Also, please refrain from writing "none" or anything similar when no file extension or Macintosh file type is specified, lest "none" be confused with an actual code value 🙈

11. Security Considerations 🔐

Security requirements for media type registrations are discussed in Section 4.6. Read it, bestie, it's serious business 😭

12. IANA Considerations 🌷

The purpose of this document is to define IANA registries for media types.

13. Acknowledgements 🙏

The current authors want to acknowledge their debt to the late Dr. Jon Postel, whose general model of IANA registration procedures and specific contributions shaped the predecessors of this document [RFC2048]. The authors hope the current version is one he would have agreed with. But since it's impossible to verify that agreement, they regretfully removed his name as a co-author 🕯️

14. References 📚

14.1. Normative References

  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
  • [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4234] Crocker, D. Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

14.2. Informative References

  • [MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator Codes, and File Formats", Apple Knowledge Base Article 55381, June 1993, <http://www.info.apple.com/kbnum/n55381>.
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
  • [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.

Appendix A. Grandfathered Media Types 👵

A number of media types registered before 1996 would, if registered under the guidelines in this document, be placed into either the vendor or personal trees. Reregistering those types to reflect the appropriate trees is encouraged but not required. The ownership and change control principles outlined in this document apply to those types as if they had been registered in the trees described above 🍓

Appendix B. Changes Since RFC 2048 🆕

  • Media type specification and registration procedures have been moved out of the MIME document set to this separate specification.
  • The various URLs and addresses in this document have been changed so they all refer to iana.org rather than isi.edu. Additionally, many of the URLs have been changed to use HTTP; formerly they used FTP.
  • Much of the document has been clarified in the light of operational experience with these procedures.
  • The unfaceted IETF tree is now called the standards tree, and the registration rules for this tree have been relaxed to allow use by other standards bodies.
  • The text describing the media type registration procedure has been clarified.
  • The rules and requirements for constructing security considerations sections have been extended and clarified.
  • RFC 3023 is now referenced as the source of additional information concerning the registration of XML media types.
  • Several of the references in this document have been updated to refer to current versions of the relevant specifications.
  • A note has been added discouraging the assignment of multiple names to a single media type.
  • Security considerations and IANA considerations sections have been added.
  • Concerns regarding copyrights on media type registration templates produced by other standards bodies have been dealt with by requiring that the IANA be allowed to copy the registration template into the registry.
  • The basic registration requirements for the various top-level types have been moved from RFC 2046 to this document.
  • A syntax is now specified for media type, subtype, and parameter names.
  • Imposed a maximum length of 127 on all media type and subtype names.
  • A note has been added to caution against excessive use of "+suffix" constructs in subtype names.
  • The encoding considerations field has been extended to allow the value "framed".
  • A reference describing Macintosh Type codes has been added.
  • Ietf-types list review of registrations in the standards tree is now required rather than just recommended.

Authors' Addresses 🎀

okay so here's where you can find the two legends who wrote this spec 🫶 bestie, save these 💅

Ned Freed
Sun Microsystems
3401 Centrelake Drive, Suite 410
Ontario, CA  92761-1205
USA

Phone: +1 909 457 4293
EMail: ned.freed@mrochek.com


John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA  02140

EMail: klensin+ietf@jck.com

Copyright (C) The Internet Society (2005). ✨

ngl this part is the legal stuff, but it's giving clarity 💅 The document is covered by the rights, licenses, and restrictions in BCP 78, and unless BCP 78 says otherwise, the authors keep all their own rights 💜

The document and everything in it is provided "AS IS" 🙈 The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say there are no warranties at all, express or implied. That includes no promise that using the information won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose. Totally no guarantees, bestie 💀

Intellectual Property 🌸

The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether licenses for those rights are available. And it hasn't independently tried to find any such rights either 🧚 Info on how rights work for RFC documents is in BCP 78 and BCP 79, so go check those if you're curious 🍓

Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances of licenses that are offered. You can also find the results of anyone trying to get a general license or permission to use the proprietary rights, for implementers or users of this spec. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr ✨

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them. Send that info to ietf-ipr@ietf.org 📬 (the address is split across a line break in the original, so it's ietf-ipr@ietf.org 💖)

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 👑 That's the end of the doc, bestie, you made it 😭🫶

📦 where this page comes from