rfc9694v1.txt   rfc9694.txt 
Internet Engineering Task Force (IETF) M. Dürst Internet Engineering Task Force (IETF) M. Dürst
Request for Comments: 9694 Aoyama Gakuin University Request for Comments: 9694 Aoyama Gakuin University
BCP: 13 February 2025 BCP: 13 March 2025
Updates: 6838 Updates: 6838
Category: Best Current Practice Category: Best Current Practice
ISSN: 2070-1721 ISSN: 2070-1721
Guidelines for the Definition of New Top-Level Media Types Guidelines for the Definition of New Top-Level Media Types
Abstract Abstract
This document defines best practices for defining new top-level media This document defines best practices for defining new top-level media
types. It also introduces a registry for top-level media types, and types. It also introduces a registry for top-level media types, and
skipping to change at line 185 skipping to change at line 185
registering an initial slate of subtypes, and provide examples of registering an initial slate of subtypes, and provide examples of
what is considered a valid subtype for future subtype what is considered a valid subtype for future subtype
registrations. registrations.
* The registration and actual use of a certain number of subtypes * The registration and actual use of a certain number of subtypes
under the new top-level type should be expected. The existence of under the new top-level type should be expected. The existence of
a single subtype should not be enough; it should be clear that new a single subtype should not be enough; it should be clear that new
similar types may appear in the future. Otherwise, the creation similar types may appear in the future. Otherwise, the creation
of a new top-level type is most probably not justified. of a new top-level type is most probably not justified.
* The proposers of the new top-level type and the wider community * The proposers of the new top-level type and the wider user
should be willing to commit to emitting and consuming the new top- community should be willing to commit to emitting and consuming
level type in environments that they control. the new top-level type in environments that they control.
* Desirability for common parameters: The fact that a group of * Desirability for common parameters: The fact that a group of
(potential) types have (mostly) common parameters may be an (potential) types have (mostly) common parameters may be an
indication that they belong under a common new top-level type. indication that they belong under a common new top-level type.
* Top-level types can help humans with understanding and debugging. * Top-level types can help humans with understanding and debugging.
Therefore, evaluating how a new top-level type helps humans Therefore, evaluating how a new top-level type helps humans
understand types may be crucial. But as often with humans, understand types may be crucial. But as often with humans,
opinions may widely differ. opinions may widely differ.
skipping to change at line 273 skipping to change at line 273
| This set of top-level names is intended to be substantially | This set of top-level names is intended to be substantially
| complete. It is expected that additions to the larger set of | complete. It is expected that additions to the larger set of
| supported types can generally be accomplished by the creation of | supported types can generally be accomplished by the creation of
| new subtypes of these initial types. In the future, more top- | new subtypes of these initial types. In the future, more top-
| level types may be defined only by an extension to this standard. | level types may be defined only by an extension to this standard.
| If another primary type is to be used for any reason, it must be | If another primary type is to be used for any reason, it must be
| given a name starting with "X-" to indicate its non-standard | given a name starting with "X-" to indicate its non-standard
| status and to avoid a potential conflict with a future official | status and to avoid a potential conflict with a future official
| name. | name.
The first time an additional top-level type was defined was in RFC RFC 1437 [RFC1437] defined the first additional top-level type;
1437 [RFC1437], but this was an April Fools RFC, purely for however, it was not registered because RFC 1437 is an April Fools RFC
entertainment purposes. that was published purely for entertainment purposes.
RFC 2046 [RFC2046] discouraged the use of "X-" for (new) top-level RFC 2046 [RFC2046] discouraged the use of "X-" for (new) top-level
types, with the following words: types, with the following words:
| In general, the use of "X-" top-level types is strongly | In general, the use of "X-" top-level types is strongly
| discouraged. Implementors should invent subtypes of the existing | discouraged. Implementors should invent subtypes of the existing
| types whenever possible. In many cases, a subtype of | types whenever possible. In many cases, a subtype of
| "application" will be more appropriate than a new top-level type. | "application" will be more appropriate than a new top-level type.
RFC 2048 [RFC2048], published at the same time as RFC 2046 [RFC2046], RFC 2048 [RFC2048], published at the same time as RFC 2046 [RFC2046],
skipping to change at line 306 skipping to change at line 306
1997. 1997.
RFC 4735 [RFC4735] introduced the 'example' top-level type for use in RFC 4735 [RFC4735] introduced the 'example' top-level type for use in
documentation examples. documentation examples.
The 'font' top-level type was defined in RFC 8081 [RFC8081], a work The 'font' top-level type was defined in RFC 8081 [RFC8081], a work
of the 'justfont' IETF WG, in 2017. This was formalizing the of the 'justfont' IETF WG, in 2017. This was formalizing the
widespread use of the unofficial 'font' top-level type that people widespread use of the unofficial 'font' top-level type that people
were using in preference to official, registered types. were using in preference to official, registered types.
There is ongoing work to define a new 'haptics' top-level media type RFC 9695 [RFC9695] defines a new 'haptics' top-level type. RFC 9695
in RFC 9695 [RFC9695]. and this document were developed in parallel, and RFC 9695 was used
to cross-check the considerations and procedures defined in this
document.
Wikipedia (at https://en.wikipedia.org/wiki/Chemical_file_format) The "Chemical file format" Wikipedia page [CHEMICAL] reports the
reports the unofficial use of a 'chemical' top-level type. This top- unofficial use of a 'chemical' top-level type. This top-level type
level type was proposed by Peter Murray-Rust and Henry Rzepa at a was proposed by Peter Murray-Rust and Henry Rzepa at a workshop at
workshop at the First WWW conference in May 1994 [CHEMIME]. It is in the First WWW conference in May 1994 CHEMIME [CHEMIME]. It is in
widespread use but remains unregistered. widespread use but remains unregistered.
Some Linux desktop logic uses what looks like a top-level type of 'x- Some Linux desktop logic uses what looks like a top-level type of 'x-
scheme-handler' to map URI schemes to applications. In addition, the scheme-handler' to map URI schemes to applications. In addition, the
type 'inode/directory' is used. However, this is a purely local, type 'inode/directory' is used. However, this is a purely local,
system-specific use, and is not intended for exchange. If exchange system-specific use, and is not intended for exchange. If exchange
or standardization are desired, a change from, for example, 'x- or standardization are desired, a change from, for example, 'x-
scheme-handler/http' to something like 'application/scheme-handler; scheme-handler/http' to something like 'application/scheme-handler;
scheme=http' or 'inode/directory' to 'multipart/inode-directory' or scheme=http' or 'inode/directory' to 'multipart/inode-directory' or
'application/inode-directory (in all cases, properly registered) is 'application/inode-directory (in all cases, properly registered) is
skipping to change at line 344 skipping to change at line 346
4. IANA Considerations 4. IANA Considerations
4.1. Registration of Top-level Media Types 4.1. Registration of Top-level Media Types
Registrations of new top-level types follow the "Standards Action" Registrations of new top-level types follow the "Standards Action"
policy (see Section 4.9 of RFC 8126 [RFC8126]). policy (see Section 4.9 of RFC 8126 [RFC8126]).
Registrations of new top-level types have to provide the name of the Registrations of new top-level types have to provide the name of the
top-level type, the defining specification (RFC, or the respective top-level type, the defining specification (RFC, or the respective
draft during the approval process), and, if applicable, some draft during the approval process), and, if applicable, some
comments. The defining specifications have to contain an "IANA comments. The defining specification has to contain an "IANA
Considerations" section requesting addition to the registry of top- Considerations" section requesting addition to the registry of top-
level media types and document security considerations for the top- level media types, and document security considerations for the top-
level types they register. level types they register.
The comments field is empty or contains short comments about the The comments field is empty or contains short comments about the
usage of the type. Comments can be added or updated by the experts usage of the type. Comments can be added or updated by the experts
for subtype registrations under the respective top-level type, and by for subtype registrations under the respective top-level type, and by
IANA itself. IANA itself.
There should be at least one subtype, except for registrations that There should be at least one subtype, except for registrations that
are for demonstration purposes only (e.g. the example top-level are for demonstration purposes only (e.g. the example top-level
type). type).
skipping to change at line 370 skipping to change at line 372
IANA has created the "Top-Level Media Types" registry and populated IANA has created the "Top-Level Media Types" registry and populated
it with the values in Table 1. IANA also added a pointer to this it with the values in Table 1. IANA also added a pointer to this
registry from the "Media Types" registry group. registry from the "Media Types" registry group.
For each top-level media type, the registry contains the name of the For each top-level media type, the registry contains the name of the
type, a pointer to the RFC defining the type, a pointer to IANA's type, a pointer to the RFC defining the type, a pointer to IANA's
registry of subtypes for that type, and a comment field. registry of subtypes for that type, and a comment field.
The initial state of the registry is as follows: The initial state of the registry is as follows:
+===========+=========+==================================+==============+ +=============+==============+==============+===================+
|name |Defining |Registry of Subtypes |Comments | | name | Defining RFC | Registry of | Comments |
| |RFC | | | | | | Subtypes | |
+===========+=========+==================================+==============+ +=============+==============+==============+===================+
|application|[RFC2046]|[Application Media Types |- | | application | [RFC2046] | [Application | - |
| | |(https://www.iana.org/assignments/| | | | | Media Types] | |
| | |media-types/)] | | +-------------+--------------+--------------+-------------------+
+-----------+---------+----------------------------------+--------------+ | audio | [RFC2046] | [Audio Media | - |
|audio |[RFC2046]|[Audio Media Types |- | | | | Types] | |
| | |(https://www.iana.org/assignments/| | +-------------+--------------+--------------+-------------------+
| | |media-types/)] | | | example | [RFC4735] | [Example | no registrations, |
+-----------+---------+----------------------------------+--------------+ | | | Media Types] | for examples only |
|example |[RFC4735]|[Example Media Types] |no | +-------------+--------------+--------------+-------------------+
| | | |registrations,| | font | [RFC8081] | [Font Media | - |
| | | |for examples | | | | Types] | |
| | | |only | +-------------+--------------+--------------+-------------------+
+-----------+---------+----------------------------------+--------------+ | haptics | [RFC9695] | [Haptics | - |
|font |[RFC8081]|[Font Media Types] |- | | | [RFC9695] | Media Types] | |
+-----------+---------+----------------------------------+--------------+ +-------------+--------------+--------------+-------------------+
|haptics |[RFC9695]|[Haptics Media Types] |- | | image | [RFC2046] | [Image Media | - |
| |[RFC9695]| | | | | | Types] | |
+-----------+---------+----------------------------------+--------------+ +-------------+--------------+--------------+-------------------+
|image |[RFC2046]|[Image Media Types] |- | | message | [RFC2046] | [Message | - |
+-----------+---------+----------------------------------+--------------+ | | | Media Types] | |
|message |[RFC2046]|[Message Media Types] |- | +-------------+--------------+--------------+-------------------+
+-----------+---------+----------------------------------+--------------+ | model | [RFC2077] | [Model Media | - |
|model |[RFC2077]|[Model Media Types] |- | | | | Types] | |
+-----------+---------+----------------------------------+--------------+ +-------------+--------------+--------------+-------------------+
|multipart |[RFC2046]|[Multipart Media Types] |- | | multipart | [RFC2046] | [Multipart | - |
+-----------+---------+----------------------------------+--------------+ | | | Media Types] | |
|text |[RFC2046]|[Text Media Types] |requires CRLF | +-------------+--------------+--------------+-------------------+
| | | |for newlines | | text | [RFC2046] | [Text Media | requires CRLF for |
+-----------+---------+----------------------------------+--------------+ | | | Types] | newlines |
|video |[RFC2046]|[Video Media Types] |- | +-------------+--------------+--------------+-------------------+
+-----------+---------+----------------------------------+--------------+ | video | [RFC2046] | [Video Media | - |
| | | Types] | |
+-------------+--------------+--------------+-------------------+
Table 1: Initial Values for the Registry of Top-level Media Types Table 1: Initial Values for the Registry of Top-level Media Types
IANA has also added pointers to this document and to the "Top-Level IANA has also added pointers to this document and to the "Top-Level
Media Types" registry in the application for a media type at Media Types" registry in the application for a media type at
<https://www.iana.org/form/media-types>. <https://www.iana.org/form/media-types>.
5. Security Considerations 5. Security Considerations
This document as such is not expected to introduce any security This document itself is not expected to introduce any security
issues. The security issues related to introducing a new top-level issues. The security issues related to introducing a new top-level
media type MUST be evaluated and documented carefully. media type MUST be evaluated and documented carefully.
Acknowledgements Acknowledgements
Continuous encouragement for writing this document came from Harald Continuous encouragement for writing this document came from Harald
Alvestrand. Further encouragement was provided by Murray Alvestrand. Further encouragement was provided by Murray
S. Kucherawy. Both Harald and Murray also provided ideas for actual S. Kucherawy. Both Harald and Murray also provided ideas for actual
text. Without them, this memo would never have reached even the text. Without them, this memo would never have reached even the
first draft stage. Alexey Melnikov provided the difficult to find first draft stage. Alexey Melnikov provided the difficult to find
skipping to change at line 459 skipping to change at line 463
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Informative References Informative References
[CHEMICAL] Wikipedia, "Chemical file format", 19 July 2024,
<https://en.wikipedia.org/w/
index.php?title=Chemical_file_format&oldid=1235421631>.
[CHEMIME] Rzepa, H.S., Murray-Rust, P., and B. Whitaker, "The [CHEMIME] Rzepa, H.S., Murray-Rust, P., and B. Whitaker, "The
Application of Chemical Multipurpose Internet Mail Application of Chemical Multipurpose Internet Mail
Extensions (Chemical MIME) Internet Standards to Extensions (Chemical MIME) Internet Standards to
Electronic Mail and World Wide Web Information Exchange", Electronic Mail and World Wide Web Information Exchange",
Journal of Chemical Information Computer Science, vol. 38, Journal of Chemical Information Computer Science, vol. 38,
no. 6, pp. 976-982, DOI 10.1021/ci9803233, 14 August 1998, no. 6, pp. 976-982, DOI 10.1021/ci9803233, 14 August 1998,
<https://pubs.acs.org/doi/10.1021/ci9803233>. <https://pubs.acs.org/doi/10.1021/ci9803233>.
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing Mail Extensions): Mechanisms for Specifying and Describing
 End of changes. 10 change blocks. 
51 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48.