RFC 6838
Media Type Specifications and Registration Procedures
Media Type Specifications and Registration Procedures 🎀
RFC 6838 · BCP 13 💖
Okay so bestie, here's the title block tea ☕. This is RFC 6838, filed as BCP 13, so the category is Best Current Practice 🔥. N. Freed (Oracle), J. Klensin, and T. Hansen (AT&T Laboratories) wrote it, and it came out in January 2013. It obsoletes RFC 4288, so 4288 is officially retired and this one is the new main character 👑. The ISSN is 2070-1721 if you ever need it 🫶.
Abstract ✨
Okay, the abstract is giving "here's what this doc is about" 💅. It sets out how media types get specified and registered so they can be used in HTTP, MIME, and other Internet protocols 🦋.
Status of This Memo 🌸
This memo documents an Internet Best Current Practice, so it's an official BCP bestie 💜.
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🙌. If you want more on BCPs, check Section 2 of RFC 5741 📚.
For the current status, any errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6838 🎀.
Copyright Notice 💅
Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⭐.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Media Type Registration Preliminaries . . . . . . . . . . . . 4
3. Registration Trees and Subtype Names . . . . . . . . . . . . . 4
3.1. Standards Tree . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Personal or Vanity Tree . . . . . . . . . . . . . . . . . 6
3.4. Unregistered x. Tree . . . . . . . . . . . . . . . . . . . 7
3.5. Additional Registration Trees . . . . . . . . . . . . . . 7
4. Registration Requirements . . . . . . . . . . . . . . . . . . 7
4.1. Functionality Requirement . . . . . . . . . . . . . . . . 8
4.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 8
4.2.1. Text Media Types . . . . . . . . . . . . . . . . . . . 9
4.2.2. Image Media Types . . . . . . . . . . . . . . . . . . 10
4.2.3. Audio Media Types . . . . . . . . . . . . . . . . . . 10
4.2.4. Video Media Types . . . . . . . . . . . . . . . . . . 10
4.2.5. Application Media Types . . . . . . . . . . . . . . . 11
4.2.6. Multipart and Message Media Types . . . . . . . . . . 11
4.2.7. Additional Top-Level Types . . . . . . . . . . . . . . 12
4.2.8. Structured Syntax Name Suffixes . . . . . . . . . . . 12
4.2.9. Deprecated Aliases . . . . . . . . . . . . . . . . . . 13
4.3. Parameter Requirements . . . . . . . . . . . . . . . . . . 13
4.4. Canonicalization and Format Requirements . . . . . . . . . 14
4.5. Interchange Recommendations . . . . . . . . . . . . . . . 15
4.6. Security Requirements . . . . . . . . . . . . . . . . . . 15
4.7. Requirements Specific to XML Media Types . . . . . . . . . 16
4.8. Encoding Requirements . . . . . . . . . . . . . . . . . . 16
4.9. Usage and Implementation Non-Requirements . . . . . . . . 17
4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18
4.11. Fragment Identifier Requirements . . . . . . . . . . . . . 18
4.12. Additional Information . . . . . . . . . . . . . . . . . . 19
5. Media Type Registration Procedures . . . . . . . . . . . . . . 19
5.1. Preliminary Community Review . . . . . . . . . . . . . . . 19
5.2. Submit Request to IANA . . . . . . . . . . . . . . . . . . 20
5.2.1. Provisional Registrations . . . . . . . . . . . . . . 20
5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 21
5.4. Comments on Media Type Registrations . . . . . . . . . . . 21
5.5. Change Procedures . . . . . . . . . . . . . . . . . . . . 21
5.6. Registration Template . . . . . . . . . . . . . . . . . . 22
6. Structured Syntax Suffix Registration Procedures . . . . . . . 23
6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 24
6.2. Structured Syntax Suffix Registration Template . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 30
Appendix B. Changes since RFC 4288 . . . . . . . . . . . . . . . 301. Introduction 🦋
Okay so recent Internet protocols were designed on purpose to be super extensible in certain areas 💖. Lots of them, like HTTP [RFC2616] and MIME [RFC2045], can carry arbitrary labeled content, and they're literally iconic for it ✨.
The label is called a media type. It has a top-level type and a subtype, and the subtype is organized into trees 🌳. Media types can also optionally carry companion data called parameters 🎀.
These labels need a registration process so the whole set of values stays orderly, well specified, and public 📚. Nobody wants a wild west of labels 💀.
This document lays out the criteria for media type registrations and the procedures for registering media types (Section 5) and media type structured suffixes (Section 6) in the central registry managed by the Internet Assigned Numbers Authority (IANA) 👑. The location of that registry is:
http://www.iana.org/assignments/media-types/1.1. Historical Note 🌸
So the registration process was first built for the asynchronous Internet mail environment 📬. In mail, you really need to limit how many media types exist, so the odds of interoperability go up when you don't know what the remote mail system can handle 🫶. Later, media types got used in new places where having lots of them isn't a problem for interoperability, so the original procedure ended up being way too restrictive and had to be generalized 🔥. That was first done in [RFC2048], but the procedure was still part of the MIME document set. Now the media type specification and registration procedure is its own separate document, which makes it clear it's independent of MIME 💜.
It may be desirable to restrict media types to specific environments, or to stop them being used in other environments 🙈. This specification bakes those restrictions into media type registrations in a systematic way. See Section 4.9 for more ✨.
1.2. Conventions Used in This Document 💅
Here's the key words situation 🎀. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] when they appear in ALL CAPS. They can also show up in lower or mixed case as plain English words, with no normative meaning 🌈.
This specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of that document 🧚.
2. Media Type Registration Preliminaries 🍓
Registering a new media type, or a batch of them, starts with writing up a registration proposal 📝. Registration can happen in several different registration trees, and each tree has its own requirements, which we'll get into below ⭐. In general, a new 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 cover the requirements and procedures for each registration tree 💖.
3. Registration Trees and Subtype Names 🌸
Okay, so to make registration more efficient and flexible, different structures of subtype names can be registered 💅. That's because different subtypes have different natural needs, like, e.g., a subtype that's going to be recommended for wide support and implementation across the Internet community, or a subtype that's just used to move files around for proprietary software 🫶. The subsections below define registration "trees" that are told apart by faceted names, meaning subtype names that start with a "tree." prefix 🌳. Heads up: some media types defined before this document don't follow these naming conventions, so see Appendix A for the tea on those 🙈.
3.1. Standards Tree ✨
okay so the standards tree is for types of general interest to the whole Internet community 🌐 Registrations in here MUST be either:
- in the case of registrations tied to IETF specifications, approved directly by the IESG, or
- registered by a recognized standards-related organization using the "Specification Required" IANA registration policy [RFC5226] (which implies Expert Review).
The first route is for registrations from IETF Consensus documents, or in rare cases when a grandfathered (see Appendix A) and/or otherwise incomplete registration is good for the Internet community 💖 The registration proposal MUST be published as an RFC. When the registration RFC is in the IETF stream, it must have IETF Consensus, which can be attained with a status of Standards Track, BCP, Informational, or Experimental. Registrations published in non-IETF RFC streams are also allowed, but they require IESG approval. A registration can live in a stand-alone "registration only" RFC or get folded into a more general specification of some sort 🎀
For the second route, the IESG makes a one-time decision on whether the registration submitter is a recognized standards-related organization. After that, a Media Types Reviewer (a Designated Expert or a group of Designated Experts) does the Expert Review as specified in this document, and subsequent submissions from that same source don't involve the IESG at all 🙌 The format MUST be described by a formal standards specification produced by the submitting standards-related organization.
Media types in the standards tree MUST NOT have faceted names, unless they are grandfathered in using the process described in Appendix A. no faceted names here, bestie 💅
The "owner" of a media type registered in the standards tree is assumed to be the standards-related organization itself 🦋 Changing or altering the specification uses the same level of processing that the initial registration needed. For example, a registration submitted on Standards Track can be revised in another Standards Track RFC, but it cannot be revised in an Informational RFC 😭
Standards-tree registrations from recognized standards-related organizations are submitted directly to the IANA, where they undergo Expert Review [RFC5226] before approval. In this case, the Expert Reviewer(s) will, among other things, make sure the required specification provides adequate documentation 📚
3.2. Vendor Tree 🛍️
The vendor tree is for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly here and are treated as equivalent. Also, industry consortia and non-commercial entities that don't qualify as recognized standards-related organizations can totally and appropriately register media types in the vendor tree 🌸
Anyone who needs to interchange files associated with some product (or set of products) may place a registration in the vendor tree. However, the registration properly belongs to the vendor or organization producing the software that uses the type being registered. That vendor or organization can, at any time, elect to assert ownership of a registration done by a third party in order to correct or update it. See Section 5.5 for additional information 👑
When a third party registers a type on behalf of someone else, both entities SHOULD be noted in the Change Controller field in the registration. One possible format would be Foo, on behalf of Bar ✨
Vendor-tree registrations are distinguished by the leading facet vnd.. That may be followed, at the registrant's discretion, by either a media subtype name from a well-known producer (for example, vnd.mudpie) or by an IANA-approved designation of the producer's name, followed by a media type or product designation (for example, vnd.bigcompany.funnypictures) 🧁
Public exposure and review of vendor-tree media types are not required, but using the media-types@iana.org mailing list for review is encouraged, to improve the quality of those specifications 💬 Registrations in the vendor tree may be submitted directly to the IANA, where they undergo Expert Review [RFC5226] before approval.
3.3. Personal or Vanity Tree 🧚
Registrations for media types created experimentally, or as part of products that aren't distributed commercially, may go in the personal or vanity tree. These are distinguished by the leading facet prs. 💜
The owner of "personal" registrations and associated specifications is the person or entity making the registration, or someone to whom responsibility has been transferred as described below 🫶
Public exposure and review of personal-tree media types are not required, but using the media-types@iana.org mailing list (see Section 5.1) for review is encouraged, to improve the quality of those specifications. Registrations in the personal tree may be submitted directly to the IANA, where they undergo Expert Review [RFC5226] before approval 🌈
3.4. Unregistered x. Tree 🙈
Subtype names with x. as the first facet may be used for types intended exclusively for use in private, local environments. Types in this tree cannot be registered, and they're only meant for use with the active agreement of the parties exchanging them 🔒
Heads up: with the simplified registration procedures described above for the vendor and personal trees, it should rarely, if ever, be necessary to use unregistered types. Therefore, use of types in the x. tree is strongly discouraged. 💀
Note that types with names beginning with x- are no longer considered members of this tree (see [RFC6648]) 🍓 Also, if a generally useful and widely deployed type incorrectly ends up with an x- name prefix, it MAY be registered using its current name in an alternative tree, by following the procedure defined in Appendix A ✨
3.5. Additional Registration Trees 🌟
From time to time, and as the community requires, new top-level registration trees may be created by IETF Standards Action. It is explicitly assumed that these trees may be created for external registration and management by well-known permanent organizations. For example, scientific societies may register media types specific to the sciences they cover 🔬
In general, the quality of review for specifications in one of these additional registration trees is expected to be equivalent to registrations in the standards tree by a recognized standards-related organization. When the IETF performs such a review, it needs to consider the greater expertise of the requesting organization with respect to the subject media type 🧠
4. Registration Requirements 📋
Media type registrations are all expected to conform to the various requirements laid out in the following sections. Requirement specifics sometimes vary depending on the registration tree, again as detailed in those sections 🌷
4.1. Functionality Requirement ⚙️
Media types MUST function as actual media formats. Registering things that are better thought of as a transfer encoding, as a charset, or as a collection of separate entities of another type is not allowed 🚫 For example, although applications exist to decode the base64 transfer encoding [RFC2045], base64 cannot be registered as a media type. sorry base64, you're not it 😭
This requirement applies regardless of the registration tree involved.
4.2. Naming Requirements 🏷️
All registered media types MUST be assigned top-level type and subtype names. The combination of these names serves to uniquely identify the media type, and the subtype name facet (or the absence of one) identifies the registration tree. Both top-level type and subtype names are case-insensitive 🌈
Type and subtype names MUST conform to the following ABNF:
type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
; specify a structured syntax suffixThis syntax is somewhat more restrictive than what's allowed by the ABNF in Section 5.1 of [RFC2045] or Section 4.2 of [RFC4288] 🧐 Also, while this syntax allows names of up to 127 characters, implementation limits may make such long names problematic. For this reason, <type-name> and <subtype-name> SHOULD be limited to 64 characters 📏
Even though the name syntax treats "." as equivalent to any other character, characters before any initial "." always specify the registration facet. This means facet-less standards-tree registrations cannot use periods in the subtype name 🙅
Similarly, the final "+" in a subtype name introduces a structured syntax specifier suffix. Structured syntax suffix requirements are specified in Section 4.2.8 ✨
It's possible for a given media type to be assigned additional names, but using different names to identify the same media type is discouraged 🙃
These requirements apply regardless of the registration tree involved.
The choice of top-level type MUST take into account the nature of the media type involved. New subtypes of top-level types MUST conform to the restrictions of the top-level type, if any. The following sections describe each of the initial set of top-level types and their associated restrictions. Additionally, various protocols, including but not limited to HTTP and MIME, MAY impose additional restrictions on the media types they can transport. (See [RFC2046] for additional information on the restrictions MIME imposes.) 🦋
4.2.1. Text Media Types 📝
okay so the "text" top-level type is for stuff that's mainly textual in form 💖
Lots of text subtypes define a "charset" parameter, including the super basic "text/plain" (the generic plain text one from [RFC2046]) 🎀. If a subtype defines a "charset" parameter, it MUST be used to specify a charset name that follows the procedures laid out in [RFC2978].
[RFC6657] spells it out: a "charset" parameter SHOULD NOT be specified when the charset info is already carried inside the payload, like "text/xml" 🙅♀️
If a "charset" parameter is specified, it SHOULD be a required parameter, which kills off the option of a default value. If there's a strong reason it should be optional anyway, each subtype MAY specify its own default value, or it MAY specify that there's no default value at all. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default ✨. For more on using "charset" parameters with text subtypes, see [RFC6657].
No matter which approach you pick, all new text/* registrations MUST clearly specify how the charset is determined. Relying on the US-ASCII default from Section 4.1.2 of [RFC2046] is no longer permitted 🚫. If you need explanatory text, it SHOULD go in the additional information section of the registration.
Plain text is giving minimalism 🍓. It doesn't provide for or allow formatting commands, font attribute specs, 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. Plain text in scripts like Arabic and Hebrew may also include facilities for mixing text segments with different writing directions 🌈.
Beyond plain text, there are tons of formats for "rich text". The wild part is that lots of them are somewhat readable even without the software that interprets them 👀. At the highest level, it's useful to tell them apart from unreadable data like images, audio, or text in an unreadable form. Without the right interpreting 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 can be represented using subtypes of "text" 🫶.
4.2.2. Image Media Types 📸
A top-level type of "image" means the content specifies one or more individual images. The subtype names the specific image format ✨.
4.2.3. Audio Media Types 🎧
A top-level type of "audio" means the content contains audio data. The subtype names the specific audio format 🎶.
4.2.4. Video Media Types 🎬
A top-level 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 one technology or format, and it doesn't rule out subtypes like animated drawings encoded compactly 🎞️.
Mixing multiple kinds of media in a single body is generally discouraged [RFC2046], but it's recognized that many video formats include a representation for synchronized audio and/or text. This is explicitly permitted for subtypes of "video" 💜.
4.2.5. Application Media Types 💻
The "application" top-level type is for discrete data that don't fit under any of the other type names, especially data that gets processed by some kind of application program 🧚. This is information 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 the big-deal one 🔐: it can pose security problems that implementors need to understand. The "application/postscript" media type registration in [RFC2046] is a great example of how to handle those issues.
For example, a meeting scheduler might define a standard representation for info about proposed meeting dates. A smart user agent could use that info to have a little dialog with the user, and then send more material based on that dialog 📅. More generally, there have been several "active" languages where programs written in a specialized language get transported to a remote location and automatically run in the recipient's environment 🤯. Those kinds of applications can be defined as subtypes of the "application" top-level type.
The subtype of "application" will often be the name of the application the data is for, or include part of that name 🌈. That does NOT mean any app name can just be used freely as a subtype. The subtype needs to be registered 🙅♀️.
4.2.6. Multipart and Message Media Types 📦
Multipart and message are composite types. That means they give you a way to encapsulate zero or more objects, each one a separate media type 🫧.
All subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046] and amended by Section 3.5 of [RFC6532].
4.2.7. Additional Top-Level Types 🆕
Sometimes a new media type won't "fit" under any currently defined top-level type name. That's expected to be pretty rare 🤏. But if it does happen, a new type name can be defined to accommodate it. Defining a new top-level type name MUST be done via a Standards Track RFC. No other mechanism can be used to define additional type names 🚫.
4.2.8. Structured Syntax Name Suffixes 🧩
XML in MIME [RFC3023] was the first augmentation to the media type definition that also specified the underlying structure of that media type. Here's the exact quote 👀:
This document also standardizes a convention (using the suffix '+xml') for naming media types ... when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities.
So basically it specified a suffix (in that case, +xml) to be appended to the base subtype name 💅.
Since then, de facto practice has grown to use this suffix convention for other well-known structuring syntaxes. Media types have been registered with suffixes like +der, +fastinfoset, and +json. This spec formalizes that practice and sets up a registry for structured type name suffixes 📋.
The primary guideline for whether a structured type name suffix is registrable is that it's described by a readily available description. Ideally that's in a document published by an established standards-related organization, with a reference that can be used in a Normative References section of an RFC 🔍.
Media types that make use of a named structured syntax SHOULD use the appropriate registered "+suffix" for that structured syntax when they're registered. By the same token, media types MUST NOT be given names that incorporate suffixes for structured syntaxes they don't actually employ. "+suffix" constructs for as-yet unregistered structured syntaxes SHOULD NOT be used, given the possibility of conflicts with future suffix definitions ⚠️.
4.2.9. Deprecated Aliases 🫥
Sometimes a single media type was already widely deployed before it got registered under multiple names. In that case, a preferred name MUST be chosen for the media type, and applications MUST use it to be compliant with the type's registration 📛. However, a list of deprecated aliases the type is known by MAY be supplied as additional information, to help applications process the media type properly 🛠️.
4.3. Parameter Requirements 🎀
Media types MAY elect to use one or more media type parameters. Or some parameters may be automatically made available to the media type just by being a subtype of a content type that defines a set of parameters applicable to any of its subtypes 🧁. Either way, the names, values, and meanings of any parameters MUST be fully specified when a media type is registered in the standards tree. They SHOULD be specified as completely as possible when media types are registered in the vendor or personal trees ✨.
Parameter names have the same syntax as media type names and values:
parameter-name = restricted-nameNote that this syntax is somewhat more restrictive than what's allowed by the ABNF in [RFC2045] and amended by [RFC2231] 🔒.
Parameter names are case-insensitive, and no meaning is attached to the order they appear in. It's an error for a specific parameter to be specified more than once 🙈.
There's no defined syntax for parameter values. Therefore, registrations MUST specify parameter value syntax. Also, some transports impose restrictions on parameter value syntax, so care needs to be taken to limit the use of potentially problematic syntaxes. For example, pure binary valued parameters are permitted in some protocols, but they're best avoided 🚧.
A protocol can impose further restrictions on parameter value syntax, depending on how it chooses to represent parameters. Both MIME [RFC2045] [RFC2231] and HTTP [RFC2045] [RFC5987] allow binary parameters as well as parameter values expressed in a specific charset, but other protocols may be less flexible 🦋.
New parameters SHOULD NOT be defined as a way to introduce new functionality in types registered in the standards tree. That said, new parameters MAY be added to convey additional information that doesn't otherwise change existing functionality. An example would be a "revision" parameter to indicate a revision level of an external specification such as JPEG 📷. Similar behavior is encouraged for media types registered in the vendor or personal trees, but it's not required 💅.
Changes to parameters (including the introduction of new ones) are managed in the same way as other changes to the media type. See Section 5.5 🌷.
4.4. Canonicalization and Format Requirements ✨
okay so bestie, every registered media type MUST use a single, canonical data format, no matter which registration tree it lives in 🎀
If a type is in the standards tree, there MUST be a permanent, easy-to-find public spec for its format 📚 That spec MUST give enough detail that independent implementations can actually interoperate with each other 🫶 It MUST at a minimum be referenced by the registration proposal, even if it isn't actually included in it 💅
Vendor and personal trees are a lot more chill about this. Their format and processing details may or may not be public, and those registrations are explicitly allowed to limit which software and versions produce or process the type 🦋 So referencing or including format specs is encouraged but not required 🌸 Still, ngl, a meaningful public spec is often the difference between just having a name reserved so nobody else grabs it, and having actual implementations and useful interop with them 💖
Some media types use patented tech, and registering those is specifically permitted 🔥 But if the media type is part of a Standards Track protocol, the restrictions in BCP 79 [RFC3979] and BCP 78 [RFC5378] on patented technology in IETF Standards Track protocols must be respected 👑 Other standards-related organizations that use the standards tree might also have their own IP rules that must be observed in their registrations 🙈
IPR disclosures for vendor and personal tree registrations are encouraged but not required 🌈
4.5. Interchange Recommendations 🦋
Ideally, media types are defined so they interoperate across as many systems and apps as possible 💜 Realistically though, some media types will have problems interoperating across different platforms 😭 Version differences, byte ordering, and gateway handling quirks can and will show up 💀
Universal interoperability of media types is not required, but known interoperability issues SHOULD be identified whenever possible ✨ Publishing a media type doesn't need an exhaustive interoperability review, and the interoperability considerations section keeps getting re-evaluated over time 🌸
These recommendations apply no matter which registration tree is involved 💅
4.6. Security Requirements 🔒
An analysis of security issues MUST be done for all types registered in the standards tree 🔥 A similar analysis for vendor or personal tree types is encouraged but not required 🫶 Regardless of what analysis has or hasn't been done, all descriptions of security issues MUST be as accurate as possible, in every registration tree 💖 Specifically, the security considerations MUST NOT state that there are "no security issues associated with this type" 🙈 Vendor or personal tree types MAY say that "the security issues associated with this type have not been assessed" 🌈
There's absolutely no requirement that media types in any tree be secure or totally risk-free 💀 Even so, 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 5.4 below 🦋
Some of the things a security analysis of a media type needs to examine and describe are:
- Complex media types may include directives that take actions on a recipient's files or other resources 📂 Often, originators are allowed to specify arbitrary actions with no restrictions, which may then have devastating effects 💀 See the registration of the
application/postscriptmedia type in [RFC2046] for an example of these directives and how to describe them in a registration 📜 - Any security analysis MUST state whether or not the type employs such "active content"; if it does, it MUST state what steps have been taken, or MUST be taken by applications of the media type, to protect users of the media type from harm 🛡️
- Complex media types may include directives that take actions which, while not directly harmful to the recipient, may disclose information that either makes a later attack easier or violates a recipient's privacy somehow 👀 Again, the registration of the
application/postscriptmedia type shows how these directives can be handled 🫣 - A media type that uses compression may give an attacker a chance to send a small amount of data that, once received and evaluated, expands enormously to eat all of the recipient's resources 🍿💥 All media types SHOULD state whether or not they employ compression; if they do, they SHOULD discuss what steps need to be taken to avoid such 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 type could be defined for storing sensitive medical information that depends on external confidentiality and integrity protection services, or that is designed for use only within a secure environment 🏥 Types SHOULD always document whether or not they need such services in their security considerations 📝
4.7. Requirements Specific to XML Media Types 🧩
There are a bunch of additional requirements specific to registering XML media types 💅 Those are specified in [RFC3023] 📖
4.8. Encoding Requirements 🍓
Some transports put restrictions on what kind of data they can carry 🚧 For example, Internet mail traditionally was limited to 7bit US-ASCII text 📧 Encoding schemes are often used to work around those transport limits 🪄
So it's useful to note what sort of data a media type can consist of as part of its registration 🫶 An "encoding considerations" field exists for exactly this purpose ✨ Its possible values are:
7bit: The content of the media type consists solely of CRLF-delimited 7bit US-ASCII text 🔤8bit: The content of the media type 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 without internal framing or alignment indicators 🎞️ Extra out-of-band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames and knowledge of the transport mechanism 🧠 Note that media types like this can't simply be stored in a file or sent as a plain stream of octets, so they're unsuitable for many traditional protocols 🙅♀️ A commonly used transport with framed encoding is the Real-time Transport Protocol, RTP 📡 Additional rules for framed encodings defined for transport using RTP are given in [RFC4855] 🦋
Additional restrictions on 7bit and 8bit text are given in Section 4.1.1 of [RFC2046] 🌸
4.9. Usage and Implementation Non-Requirements 🌈
In the asynchronous mail environment, the sender often has no idea what the remote mail agent can handle 📬 So maximum interoperability comes from sticking to "common" formats that are expected to be widely implemented 🫠 This used to be cited as a reason to limit how many media types could exist, and it led to a registration process with a big hurdle and lots of delay for anyone registering a type 😤
But the need for "common" media types doesn't mean we should cap new registrations 💜 If a limited set of media types is recommended for a particular application, that should be asserted by a separate applicability statement written for that application and/or environment 🎯
So universal support and implementation of a media type are NOT a requirement for registration 🙌 However, if a media type is explicitly intended for limited use, this MUST be noted in its registration 🚫 The "Restrictions on Usage" field exists for exactly this 💅
4.10. Publication Requirements 📣
Media types registered in the standards tree by the IETF itself MUST be published as RFCs 📜 RFC publication of vendor and personal media type registrations is allowed but not required 🦋 In every case, the IANA will keep copies of all media type registrations and "publish" them as part of the media types registration tree itself 🗂️
As stated previously, standards-tree registrations for media types defined in documents produced by other standards-related organizations MUST be described by a formal standards specification produced by that organization 🏛️ On top of that, any copyright on the registration template MUST allow the IANA to copy it into the IANA registry 📋
Outside of IETF registrations in the standards tree, registering a media type doesn't mean the IANA or the IETF endorses it, approves it, or recommends it, or even certifies that the spec is adequate 🙅♀️ To become an IETF standard, a protocol or data object must go through the IETF standards process 🎓 That gives extra assurance when it's appropriate, but it's way too difficult and too long for the convenient registration of media types 🐢
The standards tree exists for media types that do need a substantive review and approval process in a recognized standards-related organization 👑 The vendor and personal trees exist for media types that don't need that kind of process 🌷 It's expected that applicability statements for particular applications will be published from time to time in the IETF, 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 Action in the IETF and, hence, publication of an RFC on the Standards Track 🚀
4.11. Fragment Identifier Requirements 🧚
Media type registrations can specify how applications should interpret fragment identifiers (specified in Section 3.5 of [RFC3986]) associated with the media type 🔍
Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types 💕 Specifically, media types that use a named structured syntax with a registered +suffix MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration 🦋 ✨
4.12. Additional Information
Okay so the spec says a bunch of optional extras SHOULD be included in a media type's specification if you have them lying around 🎀 ✨
- Magic number(s) (length, octet values) 🔥 These are byte sequences that are always sitting at a given spot in the file, so they can be used to figure out that an entity is a certain media type. Literally a fingerprint 🫶
- File name extension(s) that are commonly used on one or more platforms to show that a file has a given media type 🍓
- Mac OS File Type code(s) (4 octets) used to label files with a given media type 💜 There's some tea on Macintosh file type codes and why they exist over in [MacOSFileTypes] 🦋
If it's a registration in the standards tree, this extra info MAY be put in the formal specification of the format too 💅 The suggestion is to bake the IANA media type registration form right into the format spec itself, which is very neat and tidy ✨
5. Media Type Registration Procedures 🌈
Okay bestie, so this procedure is NOT a formal standards process 💀 It's more of an administrative thing meant to let the community comment and sanity check without waiting forever 🙈
Normal IETF processes still need to be followed for all IETF registrations in the standards tree 👑 Posting an Internet Draft is a necessary first step, and then you post to the media-types@iana.org list, as talked about below 🎀
5.1. Preliminary Community Review 🦋
Notice of a potential media type registration in the standards tree SHOULD be sent to the media-types@iana.org mailing list for review 💖 That list exists specifically to review proposed media and access types ✨ Registrations in other trees MAY be sent to the list too, and doing that is entirely OPTIONAL, though it's strongly encouraged 🫶
The whole point of posting to this list is to get comments and feedback on the choice of type/subtype name, whether the references are unambiguous about versions and external profiling info, and a look at any interoperability or security considerations 🔥 The submitter can submit a revised proposal or abandon the registration completely at any time, no questions asked 💅
5.2. Submit Request to IANA 🌸
Media types registered in the standards tree by the IETF itself MUST be reviewed and approved by the IESG as part of the normal standards process 👑 Standards-tree registrations by recognized standards-related organizations, plus registrations in the vendor and personal trees, get submitted straight to IANA, unless other arrangements were made as part of a liaison agreement 🧚 Either way, posting the registration to the media-types@iana.org list for review before submitting is strongly encouraged 💜
Registration requests can be sent to iana@iana.org 💌 There's also a web form for registration requests:
http://www.iana.org/form/media-types
5.2.1. Provisional Registrations 🧚
Standardization processes often take forever to finish 😭 So to help with prototyping and testing, it's super helpful to assign identifiers, including but not limited to media types, early on 🌈 That way, identifiers used during standards development can stay the same once the process is done, and implementations and docs don't have to be updated 🙌
So a provisional registration process exists to support early assignment of media type names in the standards tree 💖 A provisional registration MAY be submitted to IANA for standards-tree types 🎀 The only REQUIRED fields are the media type name and contact information (including the standards-related organization name) 🍓
When IANA gets a provisional registration, it checks the name and contact info, then publishes it in a distinct, publicly visible provisional registration list ✨
Provisional registrations MAY be updated or abandoned at any time 🦋 When one is abandoned, the media type is no longer registered in any sense, and it can later be registered just like any other unassigned media type name 💅
5.3. Review and Approval 💅
Except for provisional standards-tree registrations, registrations submitted to IANA get passed on to the media types reviewer 👑 This reviewer 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 it doesn't, it gets sent back to the submitter for revision 🙈
If you disagree with a decision from the media types reviewer, you can appeal to the IESG using the procedure in Section 6.5.4 of [RFC2026] 🫶
Once a registration passes review, IANA registers the media type and makes it available to the community 🌸
For standards-tree registrations from other standards-related organizations, IANA also checks that the submitter really is a recognized standards-related organization 🧐 If they aren't currently recognized, the IESG gets asked to confirm their status 💜 Recognition from the IESG MUST be obtained before a standards-tree registration can proceed 🛑
5.4. Comments on Media Type Registrations 💬
Community members can submit comments on registered media types to IANA at iana@iana.org 💌 The media types reviewer looks at these 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, and if IANA, in consultation with the media types reviewer, approves, the comment becomes accessible alongside the type registration ✨
5.5. Change Procedures 🔄
Once 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 kind of registration 🧚 The same procedure used for the original registration request is used to process a change request 💅
Media type registrations may NOT be deleted 🙅 But media types that are no longer believed appropriate for use can be declared OBSOLETE by changing their "intended use" field, and they'll be clearly marked in the lists IANA publishes 💀
Significant changes to a media type's definition should only be requested 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 one 🥲
The owner of a media type can hand responsibility over to another person or agency by telling IANA 🫶 This can be done without discussion or review 💨
The IESG may reassign responsibility for a media type 👑 The most common case is when the author of the registration has died, moved out of contact, or is otherwise unable to make changes that matter to the community 😢
5.6. Registration Template 📝
Here's the template, bestie 🎀 Fill out every field:
Type name:
Subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification:
Applications that use this media type:
Fragment identifier considerations:
Additional information:
Deprecated alias names for this type:
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:
Provisional registration? (standards tree only):
(Any other information that the author deems interesting may be
added below this line.)"N/A", written exactly that way, can go in any field if you want to show that it doesn't apply, or that the question wasn't skipped by accident 💅 Do NOT use 'none' or other words that could be mistaken for an actual response 🙅
Limited-use media types should also say in the applications list whether or not that list is exhaustive 🌈
6. Structured Syntax Suffix Registration Procedures ✨
Someone who wants to define a "+suffix" name for a structured syntax to use with a new media type registration SHOULD do the following 🧚
- Check IANA's registry of media type name suffixes to see whether there's already an entry for that well-defined structured syntax 👀
- If there's no entry for their suffix scheme, fill out the template (specified in Section 6.2) and include it with the media type registration 📝 The template can live in an Internet Draft, alone or as part of some other protocol specification 💖 It can also be submitted in another form (as part of another document or as a standalone document), but the contents will be treated as an "IETF Contribution" under the guidelines of BCP 78 [RFC5378] 🎀
- Send a copy of the template, or a pointer to the containing document (with a specific reference to the section with the template), to the mailing list media-types@iana.org, requesting review 📬 You can combine this with a request to review the media type registration 🫶 Allow a reasonable amount of time for discussion and comments ⏳
- Respond to review comments and make revisions to the proposed registration as needed to bring it in line with the guidelines in this document 🔥
- Submit the (possibly updated) registration template, or a pointer to the document containing it, to IANA at iana@iana.org 🚀
When IANA receives a structured syntax suffix registration request, here's what happens 👀
- IANA checks the submission for completeness. If sections are missing or citations are not correct, IANA REJECTS the registration request 🙅
- IANA checks the current registry for an entry with the same name. If such an entry exists, IANA REJECTS the registration request 🛑
- IANA requests Expert Review of the registration request against the corresponding guidelines 🧐
- The Designated Expert may request additional review or discussion, as necessary 💬
- If Expert Review recommends registration, IANA adds the registration to the appropriate registry 🎉
The initial registry content specification [RFC6839] has examples of structured syntax suffix registrations 🌸
6.1. Change Procedures 🔄
Registrations may be updated in each registry through the same mechanism that's required for an initial registration 💅 If the original definition of the scheme is in an IESG-approved document, updating the specification also needs IESG approval 👑
6.2. Structured Syntax Suffix Registration Template ✨
okay so this is the checklist for a structured syntax suffix registration request 📝 these are the fields that must be filled in:
- Name: Full name of the well-defined structured syntax. 🏷️
+suffix: Suffix used to indicate conformance to the syntax. 💖- References: Include full citations for all specifications necessary to understand the structured syntax. 📚
- Encoding considerations: General guidance regarding encoding considerations for any type employing this syntax should be given here. The same requirements for media type encoding considerations given in Section 4.8 apply here. 🔤
- Interoperability considerations: Any issues regarding the interoperable use of types employing this structured syntax should be given here. Examples would include the existence of incompatible versions of the syntax, issues combining certain charsets with the syntax, or incompatibilities with other types or protocols. 🫶
- Fragment identifier considerations: Generic processing of fragment identifiers for any type employing this syntax should be described here. 🧩
- Security considerations: Security considerations shared by media types employing this structured syntax must be specified here. The same requirements for media type security considerations given in Section 4.6 apply here, with the exception that the option of not assessing the security considerations is not available for suffix registrations. 🔐 this one is serious, bestie, no skipping it!
- Contact: Person (including contact information) to contact for further information. 📮
- Author/Change controller.: Person (including contact information) authorized to change this suffix registration. 👑
7. Security Considerations 🔐
okay the security stuff for both media type and media type suffix registrations lives over in Section 4.6, so go read that one 💅
8. IANA Considerations 🌸
so the whole point of this document is to define IANA registries for media types and structured syntax suffixes, plus the procedures for managing them 🎀 it also requires IANA to keep a list of standards-related organizations for which the IESG has approved media type registrations in the standards tree.
the existing media type registry got extended with a section for provisional registrations. only standards-tree registrations are allowed in the standards tree, and only when an organization on the IANA list of standards-related organizations asks for it. see Section 5.2.1 for more on provisional registrations 🦋
IANA also added this note at the top of the provisional registry:
This registry, unlike some other provisional IANA registries, is only for temporary use. Entries in this registry are either finalized and moved to the main media types registry, or are abandoned and deleted. Entries in this registry are suitable for use for development and test purposes only.
the structured syntax name suffix registry was created like this 🧁
- The name is the "Structured Syntax Suffix" registry.
- The registration process is specified in Section 6.
- The information required for a registry entry as well as the entry format are specified in Section 6.2.
- The initial content of the registry is specified in [RFC6839].
both the media type and structured suffix registries get annotated by IANA with the original registration date AND the date of the most recent update 📅 registrations made before this spec existed may, if necessary, be marked as such instead of getting a specific date.
registration entries can get updated lots of times, so IANA also keeps the history of changes for each one, in a way that lets you figure out what the registration looked like at any given time 🕰️ main character energy for record-keeping.
last thing: per this document, IANA made a new email address, media-types@iana.org, for the media type review list. it replaces ietf-types@iana.org from RFC 4288, which is kept around as an alias 💌
9. Acknowledgments 🫶
the current authors want to give a shout-out to the late Dr. Jon Postel, whose general model of IANA registration procedures and specific contributions shaped the predecessors of this document [RFC2048] [RFC4288] 🕊️ they hope the current version is one he would have agreed with, but since nobody can verify that, they regretfully took his name off as a co-author.
Randy Bush, Francis Dupont, Bjoern Hoehrmann, Barry Leiba, Murray Kucherawy, Alexey Melnikov, S. Moonesamy, Mark Nottingham, Tom Petch, Peter Saint-Andre, and Jeni Tennison gave lots of helpful review comments and suggestions 🌟 thank you, queens!!
10. References 📖
10.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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic
Syntax", STD 66, RFC 3986, January 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors
Provide to the IETF Trust", BCP 78, RFC 5378,
November 2008.
[RFC6532] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", RFC 6532,
February 2012.
[RFC6657] Melnikov, A. and J. Reschke, "Update to MIME
regarding "charset" Parameter Handling in Textual
Media Types", RFC 6657, July 2012.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839,
January 2013.10.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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2616, June 1999.
[RFC4288] Freed, N. and J. Klensin, "Media Type
Specifications and Registration Procedures",
BCP 13, RFC 4288, December 2005.
[RFC5987] Reschke, J., "Character Set and Language Encoding
for Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs
in Application Protocols", BCP 178, RFC 6648,
June 2012.Appendix A. Grandfathered Media Types 🦕
okay so a bunch of media types with unfaceted subtype names got registered before 1996 💫 if they were registered under this document's guidelines, they'd get a faceted name and go into either the vendor or personal tree. reregistering them to match the right tree is encouraged but not required. the ownership and change control principles in this document apply to those types as if they'd been registered in the trees described above.
also, sometimes a media type with an unfaceted subtype name is widely deployed without ever being registered. (this includes subtype names starting with the "x-" prefix, fyi 🙈) if possible, that kind of media type SHOULD be reregistered with a proper faceted subtype name, maybe using a deprecated alias to identify the original name (see Section 4.2.9). but if that's not possible, the type can, subject to approval by both the media types reviewer and the IESG, be registered in the proper tree with its unfaceted name ✨
Appendix B. Changes since RFC 4288 ✨
okay so this appendix is basically the "what's new" tea ☕ for anyone who was using RFC 4288. here's everything that glowed up:
- Suffixes that indicate a particular structured syntax are now fully specified, and there's a whole suffix registration process now 🧚
- Registering widely deployed unregistered unfaceted type names in the vendor or personal trees is now allowed, as long as the media types reviewer and the IESG approve it 💅
- The standards-tree registration process got a revamp. It now includes Expert Review and works for stuff like media types in non-IETF stream documents 🦋
- The registration template has a new field for fragment identifiers, plus brief directions on how to specify them 🎀
- Personal-tree registrations now have the same specification requirements as the vendor tree. The text encourages specification availability but doesn't require it 🫶
- The process for defining additional trees is clarified: it needs an IETF Standards Action 📜
- Widely deployed types with "x-" names can now be registered as an exception in the vendor tree 🌸
- The rules for changing registrations are looser, so minor changes are way easier to make 🍓
- The registration process was completely restructured. Except for IETF-generated types in the standards tree, every request is processed by IANA instead of the IESG. no cap, that's a big deal 👑
- A provisional registration process was added for early assignment of types in the standards tree 🌈
- Lots of editorial changes throughout, so the requirements and processes are clearer and easier to follow 💜
- You can now list deprecated aliases for a media type ✨
- Types with names starting with "x-" are no longer considered members of the unregistered "x." tree. Like any unfaceted type, they get special procedures for registration in an appropriate tree 🦋
- The designated change controller can now change a type registered by a third party, even if that isn't the vendor or organization that created it. The vendor or organization can still choose to assert ownership and change controller over the type at any time 🔥
- Limited-use media types are now asked to say whether or not their list of applications is exhaustive 🙈
- The ABNF for media type names is further restricted so names must begin with an alphanumeric character 🧚
- Mailing list review is no longer required before registering a media type. The media type review mailing list address is now media-types@iana.org 💖
- The rules for text/* media types are updated to reflect the changes in [RFC6657] ⭐
Authors' Addresses ✨
the squad behind this one, bestie 🫶
Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
USA
EMail: ned+ietf@mrochek.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
EMail: john+ietf@jck.com
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
EMail: tony+mtsuffix@maillennium.att.com📦 where this page comes from
- ietf: rfc6838 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms