rfc9694.original.xml   rfc9694.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<?xml-model href="rfc7991bis.rnc"?>
<!--<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>--> <!-- draft submitted in xml v3 -->
<!-- This third-party XSLT can be enabled for direct transformations in XML proc
essors, including most browsers -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- If further character entities are required then they should be added to the
DOCTYPE above.
Use of an external entity file is not recommended. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="bcp"
consensus="true"
docName="draft-ietf-mediaman-toplevel-06"
ipr="trust200902"
obsoletes=""
updates="6838"
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.38.1 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" consensus="true" docName="draft-ietf-mediaman-toplevel-06" number="9694" ipr="trust200902" obsole tes="" updates="6838" submissionType="IETF" xml:lang="en" tocInclude="true" tocD epth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="New Top-level Media Types">Guidelines for the Definition of Ne w Top-Level Media Types</title> <title abbrev="New Top-level Media Types">Guidelines for the Definition of Ne w Top-Level Media Types</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mediaman-toplevel-06"/> <seriesInfo name="RFC" value="9694"/>
<!-- [rfced] This document updates RFC 6838, which is part of BCP 13. Please no
te that we have marked this RFC as being part of BCP 13 as well. Please verify
that this is correct (i.e., please verify that it should not be part of another
existing BCP and that a new BCP number is not needed).
<!-- add 'role="editor"' below for the editors if appropriate --> For more info about BCP 13, see
<author fullname="Martin J. Dürst" initials="M.J." surname="Dürst"> https://www.rfc-editor.org/info/bcp13
In addition, a complete list of current BCPs is available here:
https://www.rfc-editor.org/bcps
-->
<seriesInfo name="BCP" value="13"/>
<!-- [rfced] Martin, we have removed "J." from the document header (it remains i
n the authors' addresses section) to match what appears in your published RFCs.
Please let us know if you prefer otherwise.
-->
<author fullname="Martin J. Dürst" initials="M." surname="Dürst">
<organization>Aoyama Gakuin University</organization> <organization>Aoyama Gakuin University</organization>
<address> <address>
<postal> <postal>
<street>Fuchinobe 5-10-1, Chuo-ku, Sagamihara</street> <street>Fuchinobe 5-10-1, Chuo-ku, Sagamihara</street>
<region>Kanagawa</region> <region>Kanagawa</region>
<code>252-5258</code> <code>252-5258</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<phone>+81 42 759 6329</phone> <phone>+81 42 759 6329</phone>
<email>duerst@it.aoyama.ac.jp</email> <email>duerst@it.aoyama.ac.jp</email>
<uri>https://www.sw.it.aoyama.ac.jp/Dürst/</uri> <uri>https://www.sw.it.aoyama.ac.jp/Dürst/</uri>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2024"/> <date year="2024" month="December"/>
<!-- If the month and year are both specified and are the current ones, xml2 <area>ART</area>
rfc will fill <workgroup>mediaman</workgroup>
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Applications and Real-Time</area>
<workgroup>MEDIAMAN</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Media Type, Top-Level</keyword> <keyword>Media Type</keyword>
<!-- Keywords will be incorporated into HTML output <keyword>Top-Level</keyword>
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document defines best practices for defining new top-level media t ypes. <t>This document defines best practices for defining new top-level media t ypes.
It also introduces a registry for top-level media types, It also introduces a registry for top-level media types,
and contains a short history of top-level media types. and contains a short history of top-level media types.
It updates RFC 6838.</t> It updates RFC 6838.</t>
<t>[RFC Editor, please remove this paragraph.]
Comments and discussion about this document should be directed to media-
types@ietf.org,
the mailing list of the Media Type Maintenance (mediaman) WG. Alternativ
ely, issues can
be raised on GitHub at https://github.com/ietf-wg-mediaman/toplevel.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"><name>Introduction</name> <section numbered="true" toc="default"><name>Introduction</name>
<t>This document defines best practices for defining new top-level media t ypes. <t>This document defines best practices for defining new top-level media t ypes.
Top-level media types ('top-level types' for short) Top-level media types ('top-level types' for short) appear to the left o
appear to the left of the slash in a media type, f the slash in a media type,
examples being 'text/...', 'application/...', 'image/...', and so on. examples being 'text/...', 'application/...', 'image/...', and so on.
Please note that top-level types are different from trees Please note that top-level types are different from trees
(standards tree, vendor tree, personal tree), which (except for the stan dards tree) (standards tree, vendor tree, personal tree), which (except for the stan dards tree)
are indicated immediately to the right of the slash with a prefix of '.. ./vnd.' or '.../prs.'. are indicated immediately to the right of the slash with a prefix of '.. ./vnd.' or '.../prs.'.
<xref target="RFC6838" format="default">RFC&nbsp;6838</xref>, Section 4. Section <xref target="RFC6838" sectionFormat="bare" section="4.2.7"/> of
2.7 RFC 6838 <xref target="RFC6838"/>
only summarily gave criteria for defining additional top-level types. only summarily gives criteria for defining additional top-level media ty
This document provides more detailed criteria for defining additional to pes.
p-level types. This document provides more detailed criteria for defining additional to
It therefore updates <xref target="RFC6838" format="default">RFC&nbsp;68 p-level media types.
38</xref>.</t> It therefore updates RFC 6838 <xref target="RFC6838" format="default"></
xref>.</t>
<section numbered="true" toc="default"><name>Background</name> <section numbered="true" toc="default"><name>Background</name>
<t>New top-level types are rare enough and different enough from each ot her <t>New top-level types are rare enough and different enough from each ot her
that each application needs to be evaluated separately. that each application needs to be evaluated separately.
The main protocol extension point for media types are subtypes below eac h of the main types. The main protocol extension point for media types are subtypes below eac h of the main types.
For formats that do not fit below any other top-level type, For formats that do not fit below any other top-level type,
the 'application' top-level type can always be used.</t> the 'application' top-level type can always be used.</t>
<t>The main function of media types and subtypes is <t>The main function of media types and subtypes is
the dispatch of data formats to application code. the dispatch of data formats to application code.
In most cases, this requires and is done using the full type In most cases, this requires and is done using the full type
(i.e. including the subtype, and often some parameters). (i.e., including the subtype, and often some parameters).
The top-level type can occasionally serve as a fallback for the tentat ive dispatch The top-level type can occasionally serve as a fallback for the tentat ive dispatch
to applications handling a very wide range of related formats. to applications handling a very wide range of related formats.
Please note that assumptions about the correctness of a media type Please note that assumptions about the correctness of a media type
must be made carefully, as it could be under the control of an attacke r.</t> must be made carefully, as it could be under the control of an attacke r.</t>
<t>In some older scenarios, it may also have been possible to identify a device <t>In some older scenarios, it may also have been possible to identify a device
(e.g. a phone for audio messages, a printer or fax device for images, (e.g., a phone for audio messages, a printer or fax device for images,
a video recorder for videos, a computer for 'application' subtypes). a video recorder for videos, a computer for 'application' subtypes).
However, the current hardware landscape, However, the current hardware landscape,
where computers and smartphones can handle a very wide variety of medi a, where computers and smartphones can handle a very wide variety of medi a,
makes such a scenario look somewhat far-fetched.</t> makes such a scenario look somewhat far-fetched.</t>
<t>The top-level type can be used for user-directed information. <t>The top-level type can be used for user-directed information.
Besides direct inspection of the type string by the user, Besides direct inspection of the type string by the user,
this includes using different types of default icons this includes using different types of default icons
for different top-level types.</t> for different top-level types.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
described in BCP 14 <xref target="RFC2119" format="default"></xref> ",
<xref target="RFC8174" format="default"></xref> when, and only when, t "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
hey "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section><name>Rules and Criteria for the Registration of New Top-Level Medi a Types</name> <section><name>Rules and Criteria for the Registration of New Top-Level Medi a Types</name>
<t>This section describes the rules and criteria for new top-level types, <t>This section describes the rules and criteria for new top-level media t
including criteria already defined in <xref target="RFC6838" format="def ypes,
ault">RFC 6838</xref>.</t> including criteria already defined in RFC 6838 <xref target="RFC6838" fo
rmat="default"/>.</t>
<section><name>Required Criteria</name> <section><name>Required Criteria</name>
<t>The following is the list of required criteria for the definition of a new top-level type. <t>The following is the list of required criteria for the definition of a new top-level type.
Motivations for the requirements are also included.</t> Motivations for the requirements are also included.</t>
<ul> <ul>
<li>Every new top-level type MUST be defined in a Standards Track RFC <li>Every new top-level type <bcp14>MUST</bcp14> be defined in a Stand
(see <xref target="RFC8126" format="default">RFC 8126, Section 4.9 ards Track RFC
</xref>). (see Section <xref target="RFC8126" sectionFormat="bare" section="
This will make sure there is sufficient community interest, review 4.9"/> of RFC 8126 <xref target="RFC8126"/>).
, This will ensure there is sufficient community interest, review,
and consensus appropriate for a new top-level type.</li> and consensus appropriate for a new top-level type.</li>
<li>The IANA Considerations section of an RFC defining a new top-level type <li>The IANA Considerations section of an RFC defining a new top-level type
MUST request that IANA add this new top-level type to the registry <bcp14>MUST</bcp14> request that IANA add this new top-level type to the registry
of top-level types.</li> of top-level types.</li>
<li>The criteria for what types do and do not fall <li>The criteria for what types do and do not fall
under the new top-level type MUST be defined clearly. under the new top-level type <bcp14>MUST</bcp14> be defined clearl
Clear criteria are expected to help expert reviewers to evaluate y.
whether a subtype belongs below the new type or not, Clear criteria are expected to help expert reviewers evaluate
whether or not a subtype belongs below the new type,
and whether the registration template for a subtype and whether the registration template for a subtype
contains the appropriate information. contains the appropriate information.
If the criteria cannot be defined clearly, Criteria that cannot be defined clearly
this is a strong indication that whatever is being is a strong indication that whatever is being
talked about is not suitable as a top-level type.</li> talked about is not suitable as a top-level type.</li>
<li>Any RFC defining a new top-level type MUST clearly document the se curity considerations <li>Any RFC defining a new top-level type <bcp14>MUST</bcp14> clearly document the security considerations
applying to all or a significant subset of subtypes.</li> applying to all or a significant subset of subtypes.</li>
<li>At the minimum, one subtype MUST be described. <li>At a minimum, one subtype <bcp14>MUST</bcp14> be described.
A top-level type without any subtype serves no purpose. A top-level type without any subtypes serves no purpose.
Please note that the 'example' top-level describes a subtype 'exam Please note that the 'example' top-level describes the subtype 'ex
ple'.</li> ample'.</li>
</ul> </ul>
</section> </section>
<section><name>Additional Considerations</name> <section><name>Additional Considerations</name>
<ul> <ul>
<li>Existing wide use of an unregistered top-level type may be an indi <li>Existing wide use of an unregistered top-level type may be an indi
cation of a need, cation of a need, and therefore may be an argument for formally defining this ne
and therefore an argument for formally defining this new top-level t w top-level type.</li>
ype.</li>
<li>On the other hand, the use of unregistered top-level types is high ly discouraged.</li> <li>On the other hand, the use of unregistered top-level types is high ly discouraged.</li>
<li>Use of an IETF WG to define a new top-level type is not needed, <li>Use of an IETF WG to define a new top-level type is not needed,
but may be advisable in some cases. There are examples of new top- level type definitions but may be advisable in some cases. There are examples of new top- level type definitions
without a WG (<xref target="RFC2077" format="default">RFC 2077</xr without a WG (RFC 2077 <xref target="RFC2077" format="default"/>),
ef>), with a short, dedicated WG (RFC 8081 <xref target="RFC8081" format
with a short, dedicated WG (<xref target="RFC8081" format="default ="default"/>),
">RFC 8081</xref>),
and with a WG that included other related work and with a WG that included other related work
(<xref target="HAPTICS" format="default">draft-ietf-mediaman-hapti cs</xref>).</li> (RFC 9695 <xref target="RFC9695" format="default"/>).</li>
<li>The document defining the new top-level type should include <li>The document defining the new top-level type should include
initial registrations of actual subtypes. initial registrations of actual subtypes. The exception may be a
The exception may be a top-level type similar to 'example'. top-level type similar to 'example'. This will help show the need
This will help to show the need for the new top-level type, for the new top-level type, allow checking the appropriateness
will allow checking the appropriateness of the definition of the n of the definition of the new top-level type, avoid separate
ew top-level type, work for registering an initial slate of subtypes, and provide
will avoid separate work for registering an initial slate of subty examples of what is considered a valid subtype for future subtype
pes, registrations.</li>
and will provide examples of what is considered a valid subtype fo
r future subtype registrations.</li>
<li>The registration and actual use of a certain number of subtypes un der the new top-level type should be expected. <li>The registration and actual use of a certain number of subtypes un der the new top-level type should be expected.
The existence of a single subtype should not be enough; The existence of a single subtype should not be enough;
it should be clear that new similar types may appear in the future . it should be clear that new similar types may appear in the future .
Otherwise, the creation of a new top-level type is most probably n ot justified.</li> Otherwise, the creation of a new top-level type is most probably n ot justified.</li>
<!-- [rfced] Does "wider community" refer to the IETF Community, as these top-le
vel types can only be introduced via Standards Action? Or, does this mean the c
ommunity interested in using the new top-level type? Will this be clear to the
reader?
Original:
* The proposers of the new top-level type and the wider community
should be willing to commit to emitting and consuming the new top-
level type in environments that they control.
-->
<li>The proposers of the new top-level type and the wider community sh ould be willing to commit <li>The proposers of the new top-level type and the wider community sh ould be willing to commit
to emitting and consuming the new top-level type in environments t hat they control.</li> to emitting and consuming the new top-level type in environments t hat they control.</li>
<li>Desirability for common parameters: The fact that a group of (pote ntial) types have <li>Desirability for common parameters: The fact that a group of (pote ntial) types have
(mostly) common parameters may be an indication that these belong un der a common new top-level type.</li> (mostly) common parameters may be an indication that they belong und er a common new top-level type.</li>
<li>Top-level types can help humans with understanding and debugging. <li>Top-level types can help humans with understanding and debugging.
Therefore, evaluating how a new top-level type helps humans understa nd types Therefore, evaluating how a new top-level type helps humans understa nd types
may be crucial. But as often with humans, opinions may widely differ .</li> may be crucial. But as often with humans, opinions may widely differ .</li>
<li>Common restrictions may apply to all subtypes of a top-level type. <li>Common restrictions may apply to all subtypes of a top-level type.
Examples are the restriction to CRLF line endings for subtypes of ty pe 'text' Examples are the restriction to CRLF line endings for subtypes of ty pe 'text'
(at least in the context of electronic mail), or on subtypes of type 'multipart'.</li> (at least in the context of electronic mail), or on subtypes of type 'multipart'.</li>
<li>Top-level types are also used frequently in dispatching code. <li>Top-level types are also used frequently in dispatching code.
For example "multipart/*" is frequently handled as multipart/mixed, without understanding of a specific subtype. For example, "multipart/*" is frequently handled as multipart/mixed, without understanding of a specific subtype.
The top-level types 'image', 'audio', and 'video' are also often han dled generically. The top-level types 'image', 'audio', and 'video' are also often han dled generically.
Documents with these top-level types can be passed to applications h andling a wide variety Documents with these top-level types can be passed to applications h andling a wide variety
of image, audio, or video formats. HTML generating applications can of image, audio, or video formats. HTML-generating applications can
select different HTML elements select different HTML elements
(e.g. &lt;img> or &lt;audio>) for including data of different top-le (e.g., &lt;img> or &lt;audio>) for including data of different top-l
vel types. evel types.
Applications can select different icons to represent unknown types i n different top-level types.</li> Applications can select different icons to represent unknown types i n different top-level types.</li>
</ul> </ul>
</section> </section>
<section><name>Negative Criteria</name> <section><name>Negative Criteria</name>
<t>This subsection lists negative criteria for top-level types, <t>This subsection lists negative criteria for top-level types;
identifying criteria that are explicitly not reasons for a top-level t it identifies criteria that are explicitly not reasons for a top-level
ype registration.</t> type registration.</t>
<ul> <ul>
<li>A top-level type is not a pointer into another registration space that offers <li>A top-level type is not a pointer into another registration space that offers
duplicate registrations for existing media types. Example: a top-lev el type duplicate registrations for existing media types. Example: a top-lev el type
of 'oid', leading to types of the form oid/nnnnn, where nnn is an OI of 'oid', leading to types of the form oid/nnnnn, where nnn is an OI
D D (Object Identifier) designating a
(Object Identifier) designating a specific media format,</li> specific media format.</li>
<li>A top-level type MUST NOT be defined for the mapping of other prot <li>A top-level type <bcp14>MUST NOT</bcp14> be defined for the mappin
ocol elements g of other protocol elements
to media types. to media types.
For example, while there may be some merit to a mapping from media t ypes For example, while there may be some merit to a mapping from media t ypes
to URIs, e.g. in the context of RDF (Resource Description Framework) to URIs, e.g., in the context of RDF (Resource Description Framework
, ), there is very limited merit in a reverse mapping,
there is very limited merit in a reverse mapping,
and even less merit in creating a top-level type for such a mapping. and even less merit in creating a top-level type for such a mapping.
The same applies to other protocol elements such as file extensions or URI schemes. The same applies to other protocol elements such as file extensions or URI schemes.
The recommended solution in case a mapping is needed is to choose a If a mapping is needed, the recommended solution is to choose a
single type/subtype and put the additional information in an appropr iately single type/subtype and put the additional information in an appropr iately
named parameter. named parameter.
As an example, information on a file extension '.dcat' can be encode d as As an example, information on a file extension '.dcat' can be encode d as
'application/octet-string; filename=foo.dcat'.</li> 'application/octet-string; filename=foo.dcat'.</li>
<li>Media types are not a general type system. <li>Media types are not a general type system.
A top-level type MUST NOT be defined if its main or only purpose is A top-level type <bcp14>MUST NOT</bcp14> be defined if its main or o
to map other type systems, e.g. in programming languages or ontologi nly purpose is
es.</li> to map other type systems, e.g., in programming languages or ontolog
<li>A new top-level type SHOULD NOT generate aliases for existing wide ies.</li>
ly used types or subtypes.</li> <li>A new top-level type <bcp14>SHOULD NOT</bcp14> generate aliases fo
<li>Top-level types with an "X-" prefix cannot be registered, and SHOU r existing widely used types or subtypes.</li>
LD NOT be used. <li>Top-level types with an "X-" prefix cannot be registered, and <bcp
This is in line with RFC <xref target="RFC6648" format="default"></x 14>SHOULD NOT</bcp14> be used.
ref>.</li> This is in line with RFC 6648 <xref target="RFC6648" format="default
"></xref>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section><name>Top-Level Media Type History</name> <section><name>Top-Level Media Type History</name>
<t>This section briefly describes the history of top-level types. <t>This section briefly describes the history of top-level types.
The emphasis is on the aspects of the history that are relevant The emphasis is on the aspects of the history that are relevant
to the adoption of new top-level types.</t> to the adoption of new top-level types.</t>
<t><xref target="RFC1341" format="default">RFC 1341</xref> first defined t he <t>RFC 1341 <xref target="RFC1341" format="default"/> first defined the
structuring of content types into (top-level) type and subtype, and introd uced structuring of content types into (top-level) type and subtype, and introd uced
the 'text', 'multipart', 'message', 'image', 'audio', 'video', and 'applic ation' top-level types. the 'text', 'multipart', 'message', 'image', 'audio', 'video', and 'applic ation' top-level types.
That specification also allowed top-level types starting with 'X-'. That specification also allowed top-level types starting with 'X-'.
With respect to new top-level types, it said the following:</t> With respect to new top-level types, it said the following:</t>
<!-- Quoted text in blockquote is correct -->
<blockquote>An initial set of seven Content-Types is defined by this <blockquote>An initial set of seven Content-Types is defined by this
document. This set of top-level names is intended to be document. This set of top-level names is intended to be
substantially complete. It is expected that additions to substantially complete. It is expected that additions to
the larger set of supported types can generally be the larger set of supported types can generally be
accomplished by the creation of new subtypes of these accomplished by the creation of new subtypes of these
initial types. In the future, more top-level types may be initial types. In the future, more top-level types may be
defined only by an extension to this standard. If another defined only by an extension to this standard. If another
primary type is to be used for any reason, it must be given primary type is to be used for any reason, it must be given
a name starting with "X-" to indicate its non-standard a name starting with "X-" to indicate its non-standard
status and to avoid a potential conflict with a future status and to avoid a potential conflict with a future
official name.</blockquote> official name.</blockquote>
<!-- [rfced] For readability, we suggest the following update. Please let us kn
ow if this is acceptable.
Original:
The first time an additional top-level type was defined was in RFC
1437 [RFC1437], but this was an April Fools RFC, purely for
entertainment purposes.
Perhaps:
RFC 1437 [RFC1437] defined the first additional top-level type; however, it w
as not registered because RFC 1437 is an April Fools RFC that was published pure
ly for entertainment purposes.
-->
<t>The first time an additional top-level type was defined was in <t>The first time an additional top-level type was defined was in
<xref target="RFC1437" format="default">RFC 1437</xref>, but this was RFC 1437 <xref target="RFC1437" format="default"/>, but this was
an April Fools RFC, purely for entertainment purposes.</t> an April Fools RFC, purely for entertainment purposes.</t>
<t><xref target="RFC2046" format="default">RFC 2046</xref> discouraged <t>RFC 2046 <xref target="RFC2046" format="default"/> discouraged
the use of "X-" for (new) top-level types, with the following words:</t> the use of "X-" for (new) top-level types, with the following words:</t>
<!-- Quoted text in blockquote is correct -->
<blockquote>In general, the use of "X-" top-level types is strongly discou raged. <blockquote>In general, the use of "X-" top-level types is strongly discou raged.
Implementors should invent subtypes of the existing types whenever Implementors should invent subtypes of the existing types whenever
possible. In many cases, a subtype of "application" will be more possible. In many cases, a subtype of "application" will be more
appropriate than a new top-level type.</blockquote> appropriate than a new top-level type.</blockquote>
<t><xref target="RFC2048" format="default">RFC 2048</xref>, published <t>RFC 2048 <xref target="RFC2048" format="default"/>, published
at the same time as <xref target="RFC2046" format="default">RFC 2046</xr at the same time as RFC 2046 <xref target="RFC2046" format="default"/>,
ef>,
defined requirements for the definition of new top-level types:</t> defined requirements for the definition of new top-level types:</t>
<!-- Quoted text in blockquote is correct -->
<blockquote>In some cases a new media type may not "fit" under any current ly <blockquote>In some cases a new media type may not "fit" under any current ly
defined top-level content type. Such cases are expected to be quite defined top-level content type. Such cases are expected to be quite
rare. However, if such a case arises a new top-level type can be rare. However, if such a case arises a new top-level type can be
defined to accommodate it. Such a definition must be done via defined to accommodate it. Such a definition must be done via
standards-track RFC; no other mechanism can be used to define standards-track RFC; no other mechanism can be used to define
additional top-level content types.</blockquote> additional top-level content types.</blockquote>
<t>The 'model' top-level type was introduced by <xref target="RFC2077" for <t>The 'model' top-level type was introduced by RFC 2077 <xref target="RFC
mat="default">RFC 2077</xref> in 1997.</t> 2077" format="default"/> in 1997.</t>
<t><xref target="RFC4735" format="default">RFC 4735</xref> introduced the <t>RFC 4735 <xref target="RFC4735" format="default"/> introduced the
'example' top-level type for use in documentation examples.</t> 'example' top-level type for use in documentation examples.</t>
<t>The 'font' top-level type was defined in <t>The 'font' top-level type was defined in
<xref target="RFC8081" format="default">RFC 8081</xref>, RFC 8081 <xref target="RFC8081" format="default"/>,
a work of the 'justfont' IETF WG, in 2017. a work of the 'justfont' IETF WG, in 2017.
This was formalizing the widespread use of the unofficial 'font' top-lev el type This was formalizing the widespread use of the unofficial 'font' top-lev el type
which people were using in preference to official, registered types. that people were using in preference to official, registered types.
</t> </t>
<t>There is ongoing work on defining a new 'haptics' top-level type <!-- [rfced] As draft-ietf-mediaman-haptics will be published at the same time a
in <xref target="HAPTICS" format="default">draft-ietf-mediaman-haptics</ s this document, should this text be updated as follows?
xref>.</t>
Original:
There is ongoing work on defining a new 'haptics' top-level type in
draft-ietf-mediaman-haptics [HAPTICS].
Perhaps:
RFC 9695 [RFC9695] defines a new 'haptics' top-level type.
-->
<t>There is ongoing work to define a new 'haptics' top-level media type
in RFC 9695 <xref target="RFC9695" format="default"/>.</t>
<!-- [rfced] For clarity, may we update this text and add an informative referen
ce for the wikipedia page to https://en.wikipedia.org/wiki/Chemical_file_format?
Original:
Wikipedia (at https://en.wikipedia.org/wiki/Chemical_file_format)
reports the unofficial use of a 'chemical' top-level type. This top-
level type was proposed by Peter Murray-Rust and Henry Rzepa at a
workshop at the First WWW conference in May 1994 CHEMIME [CHEMIME].
It is in widespread use, but remains unregistered.
Perhaps:
The "Chemical file format" Wikipedia page [CHEMICAL]
reports the unofficial use of a 'chemical' top-level type. This top-
level type was proposed by Peter Murray-Rust and Henry Rzepa at a
workshop at the First WWW conference in May 1994 CHEMIME [CHEMIME].
It is in widespread use, but remains unregistered.
[CHEMICAL] Wikipedia, "Chemical file format", 19 July 2024,
<https://en.wikipedia.org/w/
index.php?title=Chemical_file_format&oldid=1235421631>.
-->
<t>Wikipedia (at https://en.wikipedia.org/wiki/Chemical_file_format) repor ts <t>Wikipedia (at https://en.wikipedia.org/wiki/Chemical_file_format) repor ts
the unofficial use of a 'chemical' top-level type. the unofficial use of a 'chemical' top-level type.
This top-level type was proposed by Peter Murray-Rust and Henry Rzepa This top-level type was proposed by Peter Murray-Rust and Henry Rzepa
at a workshop at the First WWW conference in May 1994 at a workshop at the First WWW conference in May 1994
<xref target="CHEMIME" format='default'>CHEMIME</xref>. <xref target="CHEMIME" format='default'/>.
It is in widespread use, but remains unregistered.</t> It is in widespread use but remains unregistered.</t>
<t>Some Linux desktop logic uses what looks like a top-level type <t>Some Linux desktop logic uses what looks like a top-level type
of 'x-scheme-handler' to map URI schemes to applications. of 'x-scheme-handler' to map URI schemes to applications.
In addition, the type 'inode/directory' is used. In addition, the type 'inode/directory' is used.
However, this is a purely local, system-specific use, However, this is a purely local, system-specific use,
not intended for exchange. If exchange or standardization and is not intended for exchange. If exchange or standardization
are desired, a change from e.g. 'x-scheme-handler/http' are desired, a change from, for example, 'x-scheme-handler/http'
to something like 'application/scheme-handler; scheme=http' to something like 'application/scheme-handler; scheme=http'
or 'inode/directory' to 'multipart/inode-directory' or 'inode/directory' to 'multipart/inode-directory'
or 'application/inode-directory (in all cases, properly registered) or 'application/inode-directory (in all cases, properly registered)
is strongly recommended.</t> is strongly recommended.</t>
<t>The document currently defining the requirements for new top-level <t>The document currently defining the requirements for new top-level
media types is <xref target="RFC6838" format="default">RFC 6838</xref>. media types is RFC 6838 <xref target="RFC6838" format="default"/>.
Of particular relevance to the work in this document are Of particular relevance to the work in this document are
Section 4.2.5 (Application Media Types) and Sections <xref target="RFC6838" section="4.2.5" sectionFormat="bare"/> (
Section 4.2.7 (Additional Top-Level Types). Application Media Types) and
<xref target="RFC6838" section="4.2.7" sectionFormat="bare"/> (Additiona
l Top-Level Types) of <xref target="RFC6838"/>.
These two sections are not strictly aligned, because the first says These two sections are not strictly aligned, because the first says
that anything that doesn't go under a more specific type that anything that doesn't go under a more specific type
can go under the 'application' top-level type, can go under the 'application' top-level type,
while the later section allows for new top-level types.</t> while the later section allows for new top-level types.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"><name>IANA Consideratio ns</name> <section anchor="IANA" numbered="true" toc="default"><name>IANA Consideratio ns</name>
<section anchor='IANAregister' numbered='true' toc='default'><name>Registr ation of Top-level Media Types</name> <section anchor='IANAregister' numbered='true' toc='default'><name>Registr ation of Top-level Media Types</name>
<t>Registrations of new top-level types follow the "Standards Action" po licy <t>Registrations of new top-level types follow the "Standards Action" po licy
(see <xref target="RFC8126" format="default">RFC 8126, Section 4.9</xref >).</t> (see Section <xref target="RFC8126" sectionFormat="bare" section="4.9"/> of RFC 8126 <xref target="RFC8126"/>).</t>
<t>Registrations of new top-level types have to provide <t>Registrations of new top-level types have to provide
the name of the top-level type, the name of the top-level type,
the defining specification (RFC, or the respective draft during the ap proval process), the defining specification (RFC, or the respective draft during the ap proval process),
and, if applicable, some comments. and, if applicable, some comments.
They have to contain a "IANA Considerations" section requesting additi <!-- [rfced] We have changed "They have" to "The defining specifications", as it
on 's the document (as opposed to the registration) that will have the IANA Conside
to the registry of top-level media types, rations and Security Considerations. Please review and let us know if updates a
and have to document security considerations for the top-level types t re needed.
hey register.</t>
Original (the first sentence is provided for context):
Registrations of new top-level types have to provide the name of the
top-level type, the defining specification (RFC, or the respective
draft during the approval process), and, if applicable, some
comments. They have to contain a "IANA Considerations" section
requesting addition to the registry of top-level media types, and
have to document security considerations for the top-level types they
register.
Current:
The defining specifications have to contain an "IANA
Considerations" section requesting addition to the registry of top-
level media types and document security considerations for the top-
level types they register.
-->
The defining specifications have to contain an "IANA Considerations" s
ection requesting addition
to the registry of top-level media types and document security conside
rations for the top-level types they register.</t>
<t>The comments field is empty or contains short comments about the usag e of the type. <t>The comments field is empty or contains short comments about the usag e of the type.
Comments can be added or updated by the experts for subtype registrati ons Comments can be added or updated by the experts for subtype registrati ons
under the respective top-level type, and by IANA itself.</t> under the respective top-level type, and by IANA itself.</t>
<t>There should be at least one subtype, except for registrations that a re <t>There should be at least one subtype, except for registrations that a re
for demonstration purposes only (e.g. the example top-level type).</t> for demonstration purposes only (e.g. the example top-level type).</t>
</section> </section>
<section anchor='IANAinitial' numbered='true' toc='default'><name>Initiali
zation of the Registry of Top-level Media Types</name> <section anchor='IANAinitial' numbered='true' toc='default'><name>Initiali
<t>IANA is requested to create and populate a registry of top-level media zation of the Registry of Top-Level Media Types</name>
types, <t>IANA has created the "Top-Level Media Types" registry and populated it
with the values in <xref target="tab1"/>. IANA also added a pointer to this reg
istry from the "Media Types" registry group.</t>
<!-- [rfced] The following text has been removed as directives to IANA. We note
that IANA has created a new registry for Top-Level Media Types (see https://www
.iana.org/assignments/top-level-media-types/top-level-media-types.xhtml) and hav
e added a pointer to the Top-Level Media Types from the Media Types registry.
This should be done by expanding the "Registries included below" section of This should be done by expanding the "Registries included below" section of
https://www.iana.org/assignments/media-types/media-types.xhtml (assuming this is https://www.iana.org/assignments/media-types/media-types.xhtml (assuming this is
compatible with IANA infrastructure; if not, then there should be compatible with IANA infrastructure; if not, then there should be
at least a pointer from that page to this new registry).</t> at least a pointer from that page to this new registry).
Note that IANA provided this information related to the registry:
NOTE: the first paragraph of Section 4.2 will have to be adjusted.
For architectural reasons related to iana.org/protocols, we were
unable to place the new Top-Level Media Types registry at
https://www.iana.org/assignments/media-types.
Please let us know if any corrections are needed.
-->
<t>For each top-level media type, the registry contains the name of the ty pe, <t>For each top-level media type, the registry contains the name of the ty pe,
a pointer to the RFC defining the type, a pointer to IANA's registry of subtypes a pointer to the RFC defining the type, a pointer to IANA's registry of subtypes
for that type, and a comment field.</t> for that type, and a comment field.</t>
<t>The initial state of the registry is as follows:</t> <t>The initial state of the registry is as follows:</t>
<table> <!-- [rfced] Currently, instances of "[pointer to be added by IANA]" in table 1
have been updated to match the text that appears in the IANA registry. However,
we are experimenting with how these should be linked as using <eref> to link to
the registries causes the table to extend beyond the 69-character limit in the
text output, and forcing a break within <eref> causes the links to break.
Notes:
- The links go to the registry group, rather than individual registries. Per IA
NA, they prefer that links be to the registry group (see "Other considerations"
on https://www.iana.org/help/protocol-registration for more details).
- We will continue to seek a solution while you review the other updates to the
RFC. Please let us know if you have a suggestion regarding how the table could
be updated.
-->
<table anchor="tab1">
<name>Initial Values for the Registry of Top-level Media Types</name> <name>Initial Values for the Registry of Top-level Media Types</name>
<thead><tr><th>name</th><th>Defining RFC</th><th>Registry of Subtypes</t h><th>Comments</th></tr></thead> <thead><tr><th>name</th><th>Defining RFC</th><th>Registry of Subtypes</t h><th>Comments</th></tr></thead>
<tbody> <tbody>
<tr><td>application</td><td>RFC 2046</td><td>[pointer to be added by I <tr><td>application</td><td><xref target="RFC2046"/></td><td>[<eref ta
ANA]</td><td>-</td></tr> rget="https://www.iana.org/assignments/media-types/">Application Media Types</er
<tr><td>audio</td><td>RFC 2046</td><td>[pointer to be added by IANA]</ ef>]</td><td>-</td></tr>
td><td>-</td></tr> <tr><td>audio</td><td><xref target="RFC2046"/></td><td>[<eref target="
<tr><td>example</td><td>RFC 4735</td><td>-</td><td>no registrations, f https://www.iana.org/assignments/media-types/">Audio Media Types</eref>]</td><td
or examples only</td></tr> >-</td></tr>
<tr><td>font</td><td>RFC 8081</td><td>[pointer to be added by IANA]</t <tr><td>example</td><td><xref target="RFC4735"/></td><td>[Example Medi
d><td>-</td></tr> a Types]</td><td>no registrations, for examples only</td></tr>
<tr><td>haptics</td><td>RFC <xref target="HAPTICS" format="default" /> <tr><td>font</td><td><xref target="RFC8081"/></td><td>[Font Media Type
</td><td>[pointer to be added by IANA]</td><td>-</td></tr> s]</td><td>-</td></tr>
<tr><td>image</td><td>RFC 2046</td><td>[pointer to be added by IANA]</ <tr><td>haptics</td><td><xref target="RFC9695"/> <xref target="RFC9695
td><td>-</td></tr> " format="default" /></td><td>[Haptics Media Types]</td><td>-</td></tr>
<tr><td>message</td><td>RFC 2046</td><td>[pointer to be added by IANA] <tr><td>image</td><td><xref target="RFC2046"/></td><td>[Image Media Ty
</td><td>-</td></tr> pes]</td><td>-</td></tr>
<tr><td>model</td><td>RFC 2077</td><td>[pointer to be added by IANA]</ <tr><td>message</td><td><xref target="RFC2046"/></td><td>[Message Medi
td><td>-</td></tr> a Types] </td><td>-</td></tr>
<tr><td>multipart</td><td>RFC 2046</td><td>[pointer to be added by IAN <tr><td>model</td><td><xref target="RFC2077"/></td><td>[Model Media Ty
A]</td><td>-</td></tr> pes]</td><td>-</td></tr>
<tr><td>text</td><td>RFC 2046</td><td>[pointer to be added by IANA]</t <tr><td>multipart</td><td><xref target="RFC2046"/></td><td>[Multipart
d><td>requires CRLF for newlines</td></tr> Media Types]</td><td>-</td></tr>
<tr><td>video</td><td>RFC 2046</td><td>[pointer to be added by IANA]</ <tr><td>text</td><td><xref target="RFC2046"/></td><td>[Text Media Type
td><td>-</td></tr> s]</td><td>requires CRLF for newlines</td></tr>
<tr><td>video</td><td><xref target="RFC2046"/></td><td>[Video Media Ty
pes]</td><td>-</td></tr>
</tbody> </tbody>
</table> </table>
<t>IANA is also requested to add pointers to this document and to the new <t>IANA has also added pointers to this document and to the "Top-Level Med
registry in ia Types" registry in
the application page at https://www.iana.org/form/media-types.</t> the application for a media type at &lt;<eref target="https://www.iana.org
/form/media-types"/>&gt;.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"><name>Security Cons iderations</name> <section anchor="Security" numbered="true" toc="default"><name>Security Cons iderations</name>
<!-- [rfced] To what does "as such" refer? Is there text missing?
Original:
5. Security Considerations
This document as such is not expected to introduce any security
issues.
-->
<t>This document as such is not expected to introduce any security issues. <t>This document as such is not expected to introduce any security issues.
The security issues of introducing a new top-level media type MUST be ev aluated The security issues related to introducing a new top-level media type <b cp14>MUST</bcp14> be evaluated
and documented carefully.</t> and documented carefully.</t>
</section> </section>
<section anchor="Changelog" numbered='false' toc='default'><name>Changelog</
name>
<t>RFC Editor, please remove this section before publication.</t>
<section numbered='false'><name>Changes from draft-ietf-mediaman-toplevel-
01 Onwards</name>
<ul>
<li>See https://github.com/ietf-wg-mediaman/toplevel/commits/main/draf
t-ietf-mediaman-toplevel.xml.</li>
</ul>
</section>
<section numbered='false'><name>Changes from draft-ietf-mediaman-toplevel-
00
to draft-ietf-mediaman-toplevel-00</name>
<ul>
<li>In the Introduction, add a Background section.</li>
<li>Reorganized so that criteria come first, and split criteria sectio
n into
various subsections.</li>
<li>Add reasons to criteria.</li>
<li>Fixes to status and related text pieces.</li>
<li>Cosmetic fixes, in particular getting rid of 'references in your f
ace' (e.g. "RFC ABCD [RFC ABCD]") little by little.</li>
</ul>
</section>
<section numbered='false'><name>Changes from draft-duerst-mediaman-topleve
l-00
to draft-ietf-mediaman-toplevel-01</name>
<ul>
<li>Add reference to <xref target="RFC2077" format="default">RFC 2077<
/xref> for definition of 'model' type.</li>
<li>Add examples of use of top-level types for dispatch.</li>
<li>Remove a stray '&gt;' before the mention of <xref target="RFC4735"
format="default">RFC 4735</xref>.</li>
<li>Change link to chemical/* Wikipedia page.</li>
<li>Remove reference in abstract (pointed out by idnits).</li>
</ul>
</section>
</section>
<section anchor="Acknowledgements" numbered="false" toc="default"><name>Ackn owledgements</name> <section anchor="Acknowledgements" numbered="false" toc="default"><name>Ackn owledgements</name>
<t>Continuous encouragement for writing this draft came from Harald Alvest <t>Continuous encouragement for writing this document came from <contact f
rand. ullname="Harald Alvestrand"/>.
Further encouragement was provided by Murray S. Kucherawy. Both Harald and Further encouragement was provided by <contact fullname="Murray S. Kuchera
wy"/>. Both Harald and
Murray also provided ideas for actual text. Without them, this memo would Murray also provided ideas for actual text. Without them, this memo would
never have reached even the first draft stage. never have reached even the first draft stage.
Alexey Melnikov provided the difficult to find pointer <contact fullname="Alexey Melnikov"/> provided the difficult to find point
to <xref target="RFC2077" format="default">RFC 2077</xref> er
to RFC 2077 <xref target="RFC2077" format="default"/>
and examples for applications dispatching on top-level types. and examples for applications dispatching on top-level types.
Additional information and comments were received from Additional information and comments were received from
Chris Lilley, Graham Kline, Henry S. Rzepa, Francesca Palombini, Zaheduzza <contact fullname="Chris Lilley"/>, <contact fullname="Graham Kline"/>, <c
man Sarker, ontact fullname="Henry S. Rzepa"/>, <contact fullname="Francesca Palombini"/>, <
Amanda Baber, Paul Wouters, Roman Danyliw, John Scudder, Radia Perlman, La contact fullname="Zaheduzzaman Sarker"/>,
rs Eggert, <contact fullname="Amanda Baber"/>, <contact fullname="Paul Wouters"/>, <c
and Antoine Fressancourt. ontact fullname="Roman Danyliw"/>, <contact fullname="John Scudder"/>, <contact
Inspiration for negative criteria or examples was provided by Phillip Hall fullname="Radia Perlman"/>, <contact fullname="Lars Eggert"/>,
am-Baker, and <contact fullname="Antoine Fressancourt"/>.
Donald E. Eastlake 3rd, Petter Reinholdtsen, and Christian Heller.</t> Inspiration for negative criteria or examples were provided by <contact fu
llname="Phillip Hallam-Baker"/>,
<contact fullname="Donald E. Eastlake 3rd"/>, <contact fullname="Petter Re
inholdtsen"/>, and <contact fullname="Christian Heller"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- References split into informative and normative -->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
C.2119.xml"?--> 19.xml"/>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.68
" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119. 38.xml"/>
xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<front> 74.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
le> 26.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor='RFC6838' target='https://www.rfc-editor.org/info/rfc6838
'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization
/></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organizat
ion /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organizatio
n /></author>
<date year='2013' month='January' />
<abstract><t>This document defines procedures for the specification and
registration of media types for use in HTTP, MIME, and other Internet protocols.
This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications.
This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage
of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor='RFC8126' target='https://www.rfc-editor.org/rfc/rfc81
26.html#section-4.9'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.13
41.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.14
37.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.20
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.20
48.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.20
77.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.47
35.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66
48.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
81.xml"/>
<!-- reference if earlier update is approved.
<reference anchor="CHEMICAL"
target="https://en.wikipedia.org/w/index.php?title=Chemical_file_format&amp;oldi
d=1235421631">
<front>
<title>Chemical file format</title>
<author initials="" surname="" fullname="">
<organization>Wikipedia</organization>
</author>
<date month="July" day="19" year="2024" />
</front>
</reference>
-->
<reference anchor='RFC1341' target='https://www.rfc-editor.org/info/rfc
1341'>
<front>
<title>MIME (Multipurpose Internet Mail Extensions): Mechanisms for
Specifying and Describing the Format of Internet Message Bodies</title>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'>
<organization /></author>
<author initials='N.' surname='Freed' fullname='N. Freed'><organizat
ion /></author>
<date year='1992' month='June' />
<abstract><t>This document redefines the format of message bodies to
allow multi-part textual and non-textual message bodies to be represented and e
xchanged without loss of information. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1341'/>
<seriesInfo name='DOI' value='10.17487/RFC1341'/>
</reference>
<reference anchor='RFC1437' target='https://www.rfc-editor.org/info/rfc
1437'>
<front>
<title>The Extension of MIME Content-Types to a New Medium</title>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'>
<organization /></author>
<author initials='M.' surname='Linimon' fullname='M. Linimon'><organ
ization /></author>
<date year='1993' month='April' />
<abstract><t>This document defines one particular type of MIME data,
the matter- transport/sentient-life-form type.
This memo provides information for the Internet community. It doe
s not specify an Internet standard.</t></abstract>
</front>
<seriesInfo name='RFC' value='1437'/>
<seriesInfo name='DOI' value='10.17487/RFC1437'/>
</reference>
<reference anchor='RFC2046' target='https://www.rfc-editor.org/info/rfc
2046'>
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organizat
ion /></author>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'>
<organization /></author>
<date year='1996' month='November' />
<abstract><t>This second document defines the general structure of t
he MIME media typing system and defines an initial set of media types. [STANDAR
DS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2046'/>
<seriesInfo name='DOI' value='10.17487/RFC2046'/>
</reference>
<reference anchor='RFC2048' target='https://www.rfc-editor.org/info/rfc
2048'>
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Four: Regis
tration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organizat
ion /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organ
ization /></author>
<author initials='J.' surname='Postel' fullname='J. Postel'><organiz
ation /></author>
<date year='1996' month='November' />
<abstract><t>This set of documents, collectively called the Multipur
pose Internet Mail Extensions, or MIME, redefines the format of messages. This
fourth document, RFC 2048, specifies various IANA registration procedures for so
me MIME facilities. This document specifies an Internet Best Current Practices
for the Internet Community, and requests discussion and suggestions for improvem
ents.</t></abstract>
</front>
<seriesInfo name='RFC' value='2048'/>
<seriesInfo name='DOI' value='10.17487/RFC2048'/>
</reference>
<reference anchor='RFC2077' target='https://www.rfc-editor.org/info/rfc
2077'>
<front>
<title>The Model Primary Content Type for Multipurpose Internet Mail
Extensions</title>
<author initials='S.' surname='Nelson' fullname='S. Nelson'><organiz
ation /></author>
<author initials='C.' surname='Parks' fullname='C. Parks'><organizat
ion /></author>
<author initials='Mitra' surname='' fullname='Mitra'><organization /
></author>
<date year='1997' month='January' />
<abstract><t>The purpose of this memo is to propose an update to Int
ernet RFC 2045 to include a new primary content-type to be known as &quot;model&
quot;. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2077'/>
<seriesInfo name='DOI' value='10.17487/RFC2077'/>
</reference>
<reference anchor='RFC4735' target='https://www.rfc-editor.org/info/rfc
4735'>
<front>
<title>Example Media Types for Use in Documentation</title>
<author initials='T.' surname='Taylor' fullname='T. Taylor'><organiz
ation /></author>
<date year='2006' month='October' />
<abstract><t>This document is registration for the 'example' media t
ype and 'example' subtypes within the standards tree. The 'example/*' and '*/ex
ample' media types are defined for documentation purposes only. [STANDARDS-TRAC
K]</t></abstract>
</front>
<seriesInfo name='RFC' value='4735'/>
<seriesInfo name='DOI' value='10.17487/RFC4735'/>
</reference>
<reference anchor='RFC6648' target='https://www.rfc-editor.org/info/rfc
6648'>
<front>
<title>Deprecating the &quot;X-&quot; Prefix and Similar Constructs
in Application Protocols</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre
'><organization /></author>
<author initials='D.' surname='Crocker' fullname='D. Crocker'><organ
ization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
<organization /></author>
<date year='2012' month='June' />
<abstract><t>Historically, designers and implementers of application
protocols have often distinguished between standardized and unstandardized para
meters by prefixing the names of unstandardized parameters with the string &quot
;X-&quot; or similar constructs. In practice, that convention causes more probl
ems than it solves. Therefore, this document deprecates the convention for newl
y defined parameters with textual (as opposed to numerical) names in application
protocols. This memo documents an Internet Best Current Practice.</t></abstract
>
</front>
<seriesInfo name='BCP' value='178'/>
<seriesInfo name='RFC' value='6648'/>
<seriesInfo name='DOI' value='10.17487/RFC6648'/>
</reference>
<reference anchor='RFC8081' target='https://www.rfc-editor.org/info/rfc
8081'>
<front>
<title>The &quot;font&quot; Top-Level Media Type</title>
<author initials='C.' surname='Lilley' fullname='C. Lilley'><organiz
ation /></author>
<date year='2017' month='February' />
<abstract><t>This memo serves to register and document the &quot;fon
t&quot; top-level media type,
under which subtypes for representation formats for fonts may be r
egistered.
This document also serves as a registration application for a set
of intended subtypes,
which are representative of some existing subtypes already in use,
and currently registered under the &quot;application&quot; tree by their separa
te registrations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8081'/>
<seriesInfo name='DOI' value='10.17487/RFC8081'/>
</reference>
<reference anchor='CHEMIME' target='https://pubs.acs.org/doi/10.1021/ci9 803233'> <reference anchor='CHEMIME' target='https://pubs.acs.org/doi/10.1021/ci9 803233'>
<front> <front>
<title>The Application of Chemical Multipurpose Internet Mail Extens ions <title>The Application of Chemical Multipurpose Internet Mail Extens ions
(Chemical MIME) Internet Standards (Chemical MIME) Internet Standards
to Electronic Mail and World Wide Web Information Exchange</title> to Electronic Mail and World Wide Web Information Exchange</title>
<author initials='H.S.' surname='Rzepa' fullname='Henry S. Rzepa'><o rganization/></author> <author initials='H.S.' surname='Rzepa' fullname='Henry S. Rzepa'><o rganization/></author>
<author initials='P.' surname='Murray-Rust' fullname='Peter Murray-R ust'><organization/></author> <author initials='P.' surname='Murray-Rust' fullname='Peter Murray-R ust'><organization/></author>
<author initials='B.' surname='Whitaker' fullname='Benjamin Whitaker '><organization/></author> <author initials='B.' surname='Whitaker' fullname='Benjamin Whitaker '><organization/></author>
<date year='1998' month='August' day='14' /> <date year='1998' month='August' day='14' />
<note><t>J. Chem. Inf. Comput. Sci. 1998, 38, 6, 976–982</t></note>
</front> </front>
<seriesInfo name='DOI' value='10.1021/ci9803233'/> <seriesInfo name='DOI' value='10.1021/ci9803233'/>
<refcontent>Journal of Chemical Information Computer Science, vol. 38, no. 6, pp. 976-982</refcontent>
</reference> </reference>
<reference anchor='HAPTICS' target='https://datatracker.ietf.org/doc/dra
ft-ietf-mediaman-haptics/'> <!-- [I-D.ietf-mediaman-haptics] RFC-to-be 9695-->
<reference anchor='RFC9695' target='https://www.rfc-editor.org/info/rfc9
695'>
<front> <front>
<title abbrev="The 'haptics' Top-level Media Type">The 'haptics' Top -level Media Type</title> <title abbrev="The 'haptics' Top-level Media Type">The 'haptics' Top -level Media Type</title>
<seriesInfo name="RFC" status="standards" stream="IETF" value="XXXX" />
<author fullname="Yeshwant K. Muthusamy" surname="Muthusamy" initial s="Y. K."> <author fullname="Yeshwant K. Muthusamy" surname="Muthusamy" initial s="Y. K.">
<organization>Immersion Corporation</organization> <organization>Immersion Corporation</organization>
</author> </author>
<author fullname="Chris Ullrich" surname="Ullrich" initials="C."> <author fullname="Chris Ullrich" surname="Ullrich" initials="C.">
<organization>Immersion Corporation</organization> <organization>Immersion Corporation</organization>
</author> </author>
<date/> <date month="December" year="2024"/>
<area>Internet</area>
<workgroup>MEDIAMAN</workgroup>
<abstract>
<t>This memo serves to register and document the 'haptics' top-lev
el media type,
under which subtypes for representation formats for haptics may
be registered.
This document also serves as a registration application for a se
t of intended subtypes,
which are representative of some existing subtypes already in us
e.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9695"/>
<seriesInfo name="DOI" value="10.17487/RFC9695"/>
</reference> </reference>
</references> </references>
</references> </references>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 77 change blocks. 
531 lines changed or deleted 379 lines changed or added

This html diff was produced by rfcdiff 1.48.