Dear RFC Editors,
First, I'm very sorry for the long delay in answering you. I should have
more time over the next days and weeks, so that we hopefully can
complete this soon.
I have reviewed the diff at
https://www.rfc-editor.org/authors/rfc9694-rfcdiff.html.
Most of the changes are okay, but some need additional tweaks.
I'm attaching an updated xml file including these tweaks. These tweaks
are also visible on github as individual commits, please see
https://github.com/ietf-wg-mediaman/toplevel/commits/main/draft-ietf-mediaman-toplevel.xml
(all commits are on March 1 (or February 28 in your location, depending
on where you are and how github deals with timezones)).
One additional question: In section 2.3, the document mentions "RDF
(Resource Description Framework)". Does this need a citation, or can
people look it up?
The rest of this mail contains answers to your comments, in some cases
with new proposals for text. Except where mentioned, these new proposals
are not yet integrated into the attached xml. Please integrate them
unless you see problems, or tell me to integrate them.
Regards, Martin.
On 2024-12-24 16:07, rfc-edi...@rfc-editor.org wrote:
Martin,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the XML file.
1) <!-- [rfced] This document updates RFC 6838, which is part of BCP 13.
Please note 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).
For more info about BCP 13, see
https://www.rfc-editor.org/info/bcp13
In addition, a complete list of current BCPs is available here:
https://www.rfc-editor.org/bcps
-->
Yes, I think this is correct.
2) <!-- [rfced] Martin, we have removed "J." from the document header
(it remains in the authors' addresses section) to match what appears
in your published RFCs. Please let us know if you prefer otherwise.
-->
That should be okay.
3) <!-- [rfced] Does "wider community" refer to the IETF Community, as
these top-level types can only be introduced via Standards Action? Or,
does this mean the community 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.
-->
"wider community" refers to the community that is using documents that
would fall under the new top-level type (if that top-level type is
approved). I think this will be clear to the reader. If you think it is
not clear enough, I propose to change "wider community" to "wider user
community".
4) <!-- [rfced] For readability, we suggest the following update.
Please let us know 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 was not registered because RFC 1437 is an April Fools RFC that was
published purely for entertainment purposes.
-->
Your proposal looks fine to me.
5) <!-- [rfced] As draft-ietf-mediaman-haptics will be published at the
same time as this document, should this text be updated as follows?
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.
-->
Your edit points in the right direction. However, I think it would be
good if we expanded this as follows:
RFC 9695 [RFC9695] defines a new 'haptics' top-level type. RFC 9695 and
this document were developed in parallel, and RFC 9695 was used to
cross-check the considerations and procedures defined in this document.
6) <!-- [rfced] For clarity, may we update this text and add an informative
reference 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>.
-->
Your proposed change looks good to me.
7) <!-- [rfced] We have changed "They have" to "The defining specifications",
as it's the document (as opposed to the registration) that will have the IANA
Considerations and Security Considerations. Please review and let us know if
updates are needed.
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.
-->
In general, this looks good. However, I'd really want to keep the comma
before the "and", because otherwise, it's way too easy to read
"document" as a noun and get stuck. Also, we don't envision that many
new top-level registrations, so I think singular works better.
The resulting changes are in the attached xml file, please cross-check.
8) <!-- [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 have 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 https://www.iana.org/assignments/media-types/media-types.xhtml
(assuming this is compatible with IANA infrastructure; if not, then
there should be 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.
-->
This should be fine.
9) <!-- [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 IANA, 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.
-->
It seems difficult or impossible to provide direct links from the table
entries in the RFC to the individual registries, both because IANA
cannot guarantee the stability of links to individual registries as well
as because these links would be too long. I propose that we don't use
links at all. As long as it is clear to IANA that they should provide
links in their table (which they already do) and the readers of the RFC
have a pointer to https://www.iana.org/assignments/top-level-media-types
close before or after the table, things should be fine.
10) <!-- [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.
-->
Most probably, this is easier to understand:
This document itself is not expected to introduce any security issues.
11) <!-- [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.
-->
Thank you.
RFC Editor
On Dec 23, 2024, at 10:58 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2024/12/23
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9694.xml
https://www.rfc-editor.org/authors/rfc9694.html
https://www.rfc-editor.org/authors/rfc9694.pdf
https://www.rfc-editor.org/authors/rfc9694.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9694-diff.html
https://www.rfc-editor.org/authors/rfc9694-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9694-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9694
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9694 (draft-ietf-mediaman-toplevel-06)
Title : Guidelines for the Definition of New Top-Level Media Types
Author(s) : M. Dürst
WG Chair(s) : Harald T. Alvestrand
Area Director(s) : Murray Kucherawy, Orie Steele
--
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan
<?xml version='1.0' encoding='utf-8'?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="bcp" consensus="true" docName="draft-ietf-mediaman-toplevel-06" number="9694" ipr="trust200902" obsoletes="" updates="6838" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="New Top-level Media Types">Guidelines for the Definition of New Top-Level Media Types</title>
<seriesInfo name="RFC" value="9694"/>
<!-- [rfced] This document updates RFC 6838, which is part of BCP 13. Please note 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).
For more info about BCP 13, see
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 in 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>
<address>
<postal>
<street>Fuchinobe 5-10-1, Chuo-ku, Sagamihara</street>
<region>Kanagawa</region>
<code>252-5258</code>
<country>Japan</country>
</postal>
<phone>+81 42 759 6329</phone>
<email>due...@it.aoyama.ac.jp</email>
<uri>https://www.sw.it.aoyama.ac.jp/Dürst/</uri>
</address>
</author>
<date year="2024" month="December"/>
<area>ART</area>
<workgroup>mediaman</workgroup>
<keyword>Media Type</keyword>
<keyword>Top-Level</keyword>
<abstract>
<t>This document defines best practices for defining new top-level media types.
It also introduces a registry for top-level media types,
and contains a short history of top-level media types.
It updates RFC 6838.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default"><name>Introduction</name>
<t>This document defines best practices for defining new top-level media types.
Top-level media types ('top-level types' for short) appear to the left of the slash in a media type,
examples being 'text/...', 'application/...', 'image/...', and so on.
Please note that top-level types are different from trees
(standards tree, vendor tree, personal tree), which (except for the standards tree)
are indicated immediately to the right of the slash with a prefix of '.../vnd.' or '.../prs.'.
Section <xref target="RFC6838" sectionFormat="bare" section="4.2.7"/> of RFC 6838 <xref target="RFC6838"/>
only summarily gives criteria for defining additional top-level media types.
This document provides more detailed criteria for defining additional top-level media types.
It therefore updates RFC 6838 <xref target="RFC6838" format="default"></xref>.</t>
<section numbered="true" toc="default"><name>Background</name>
<t>New top-level types are rare enough and different enough from each other
that each application needs to be evaluated separately.
The main protocol extension point for media types are subtypes below each of the main types.
For formats that do not fit below any other top-level type,
the 'application' top-level type can always be used.</t>
<t>The main function of media types and subtypes is
the dispatch of data formats to application code.
In most cases, this requires and is done using the full type
(i.e., including the subtype, and often some parameters).
The top-level type can occasionally serve as a fallback for the tentative dispatch
to applications handling a very wide range of related formats.
Please note that assumptions about the correctness of a media type
must be made carefully, as it could be under the control of an attacker.</t>
<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,
a video recorder for videos, a computer for 'application' subtypes).
However, the current hardware landscape,
where computers and smartphones can handle a very wide variety of media,
makes such a scenario look somewhat far-fetched.</t>
<t>The top-level type can be used for user-directed information.
Besides direct inspection of the type string by the user,
this includes using different types of default icons
for different top-level types.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
</section>
<section><name>Rules and Criteria for the Registration of New Top-Level Media Types</name>
<t>This section describes the rules and criteria for new top-level media types,
including criteria already defined in RFC 6838 <xref target="RFC6838" format="default"/>.</t>
<section><name>Required Criteria</name>
<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>
<ul>
<li>Every new top-level type <bcp14>MUST</bcp14> be defined in a Standards Track RFC
(see Section <xref target="RFC8126" sectionFormat="bare" section="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>
<li>The IANA Considerations section of an RFC defining a new top-level type
<bcp14>MUST</bcp14> request that IANA add this new top-level type to the registry
of top-level types.</li>
<li>The criteria for what types do and do not fall
under the new top-level type <bcp14>MUST</bcp14> be defined clearly.
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
contains the appropriate information.
Criteria that cannot be defined clearly
are a strong indication that whatever is being
talked about is not suitable as a top-level type.</li>
<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>
<li>At a minimum, one subtype <bcp14>MUST</bcp14> be described.
A top-level type without any subtypes serves no purpose.
Please note that the 'example' top-level describes the subtype 'example'.</li>
</ul>
</section>
<section><name>Additional Considerations</name>
<ul>
<li>Existing wide use of an unregistered top-level type may be an indication of a need, and therefore may be an argument for formally defining this new top-level type.</li>
<li>On the other hand, the use of unregistered top-level types is highly discouraged.</li>
<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
without a WG (RFC 2077 <xref target="RFC2077" format="default"/>),
with a short, dedicated WG (RFC 8081 <xref target="RFC8081" format="default"/>),
and with a WG that included other related work
(RFC 9695 <xref target="RFC9695" format="default"/>).</li>
<li>The document defining the new top-level type should include
initial registrations of actual subtypes. The exception may be a
top-level type similar to 'example'. This will help show the need
for the new top-level type, allow checking the appropriateness
of the definition of the new top-level type, avoid separate
work for registering an initial slate of subtypes, and provide
examples of what is considered a valid subtype for future subtype
registrations.</li>
<li>The registration and actual use of a certain number of subtypes 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 similar types may appear in the future.
Otherwise, the creation of a new top-level type is most probably not justified.</li>
<!-- [rfced] Does "wider community" refer to the IETF Community, as these top-level types can only be introduced via Standards Action? Or, does this mean the community 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 should be willing to commit
to emitting and consuming the new top-level type in environments that they control.</li>
<li>Desirability for common parameters: The fact that a group of (potential) types have
(mostly) common parameters may be an indication that they belong under a common new top-level type.</li>
<li>Top-level types can help humans with understanding and debugging.
Therefore, evaluating how a new top-level type helps humans understand types
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.
Examples are the restriction to CRLF line endings for subtypes of type 'text'
(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.
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 handled generically.
Documents with these top-level types can be passed to applications handling a wide variety
of image, audio, or video formats. HTML-generating applications can select different HTML elements
(e.g., <img> or <audio>) for including data of different top-level types.
Applications can select different icons to represent unknown types in different top-level types.</li>
</ul>
</section>
<section><name>Negative Criteria</name>
<t>This subsection lists negative criteria for top-level types;
it identifies criteria that are explicitly not reasons for a top-level type registration.</t>
<ul>
<li>A top-level type is not a pointer into another registration space that offers
duplicate registrations for existing media types. Example: a top-level type
of 'oid', leading to types of the form oid/nnnnn, where nnn is an OID (Object Identifier) designating a
specific media format.</li>
<li>A top-level type <bcp14>MUST NOT</bcp14> be defined for the mapping of other protocol elements
to media types.
For example, while there may be some merit to a mapping from media types
to URIs, e.g., in the context of RDF (Resource Description Framework), there is very limited merit in a reverse 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.
If a mapping is needed, the recommended solution is to choose a
single type/subtype and put the additional information in an appropriately
named parameter.
As an example, information on a file extension '.dcat' can be encoded as
'application/octet-string; filename=foo.dcat'.</li>
<li>Media types are not a general type system.
A top-level type <bcp14>MUST NOT</bcp14> be defined if its main or only purpose is
to map other type systems, e.g., in programming languages or ontologies.</li>
<li>A new top-level type <bcp14>SHOULD NOT</bcp14> generate aliases for existing widely used types or subtypes.</li>
<li>Top-level types with an "X-" prefix cannot be registered, and <bcp14>SHOULD NOT</bcp14> be used.
This is in line with RFC 6648 <xref target="RFC6648" format="default"></xref>.</li>
</ul>
</section>
</section>
<section><name>Top-Level Media Type History</name>
<t>This section briefly describes the history of top-level types.
The emphasis is on the aspects of the history that are relevant
to the adoption of new top-level types.</t>
<t>RFC 1341 <xref target="RFC1341" format="default"/> first defined the
structuring of content types into (top-level) type and subtype, and introduced
the 'text', 'multipart', 'message', 'image', 'audio', 'video', and 'application' top-level types.
That specification also allowed top-level types starting with 'X-'.
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
document. This set of top-level names is intended to be
substantially complete. It is expected that additions to
the larger set of supported types can generally be
accomplished by the creation of new subtypes of these
initial types. In the future, more top-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 given
a name starting with "X-" to indicate its non-standard
status and to avoid a potential conflict with a future
official name.</blockquote>
<!-- [rfced] For readability, we suggest the following update. Please let us know 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 was not registered because RFC 1437 is an April Fools RFC that was published purely for entertainment purposes.
-->
<t>The first time an additional top-level type was defined was in
RFC 1437 <xref target="RFC1437" format="default"/>, but this was
an April Fools RFC, purely for entertainment purposes.</t>
<t>RFC 2046 <xref target="RFC2046" format="default"/> discouraged
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 discouraged.
Implementors should invent subtypes of the existing types whenever
possible. In many cases, a subtype of "application" will be more
appropriate than a new top-level type.</blockquote>
<t>RFC 2048 <xref target="RFC2048" format="default"/>, published
at the same time as RFC 2046 <xref target="RFC2046" format="default"/>,
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 currently
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
defined to accommodate it. Such a definition must be done via
standards-track RFC; no other mechanism can be used to define
additional top-level content types.</blockquote>
<t>The 'model' top-level type was introduced by RFC 2077 <xref target="RFC2077" format="default"/> in 1997.</t>
<t>RFC 4735 <xref target="RFC4735" format="default"/> introduced the
'example' top-level type for use in documentation examples.</t>
<t>The 'font' top-level type was defined in
RFC 8081 <xref target="RFC8081" format="default"/>,
a work of the 'justfont' IETF WG, in 2017.
This was formalizing the widespread use of the unofficial 'font' top-level type
that people were using in preference to official, registered types.
</t>
<!-- [rfced] As draft-ietf-mediaman-haptics will be published at the same time as this document, should this text be updated as follows?
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 reference 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) 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
<xref target="CHEMIME" format='default'/>.
It is in widespread use but remains unregistered.</t>
<t>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 type 'inode/directory' is used.
However, this is a purely local, system-specific use,
and is not intended for exchange. If exchange or standardization
are desired, different types (in all cases, properly registered)
are strongly recommended.
For example, 'x-scheme-handler/http' should be changed
to something like 'application/scheme-handler; scheme=http'.
The type 'inode/directory' should be changed to 'multipart/inode-directory'
or 'application/inode-directory.</t>
<t>The document that previously defined the requirements for new top-level
media types was RFC 6838 <xref target="RFC6838" format="default"/>.
Of particular relevance to the work in the current document are
Sections <xref target="RFC6838" section="4.2.5" sectionFormat="bare"/> (Application Media Types) and
<xref target="RFC6838" section="4.2.7" sectionFormat="bare"/> (Additional Top-Level Types) of <xref target="RFC6838"/>.
These two sections are not strictly aligned, because the first says
that anything that doesn't go under a more specific type
can go under the 'application' top-level type,
while the later section allows for new top-level types.</t>
</section>
<section anchor="IANA" numbered="true" toc="default"><name>IANA Considerations</name>
<section anchor='IANAregister' numbered='true' toc='default'><name>Registration of Top-level Media Types</name>
<t>Registrations of new top-level types follow the "Standards Action" policy
(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
the name of the top-level type,
the defining specification (RFC, or the respective draft during the approval process),
and, if applicable, some comments.
<!-- [rfced] We have changed "They have" to "The defining specifications", as it's the document (as opposed to the registration) that will have the IANA Considerations and Security Considerations. Please review and let us know if updates are needed.
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 specification has to contain an "IANA Considerations" section requesting addition
to the registry of top-level media types, and has to document security considerations for the top-level type they register.</t>
<t>The comments field is empty or contains short comments about the usage of the type.
Comments can be added or updated by the experts for subtype registrations
under the respective top-level type, and by IANA itself.</t>
<t>There should be at least one subtype, except for registrations that are
for demonstration purposes only (e.g. the example top-level type).</t>
</section>
<section anchor='IANAinitial' numbered='true' toc='default'><name>Initialization of the Registry of Top-Level Media Types</name>
<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 registry 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 have 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
https://www.iana.org/assignments/media-types/media-types.xhtml (assuming this is
compatible with IANA infrastructure; if not, then there should be
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 type,
a pointer to the RFC defining the type, a pointer to IANA's registry of subtypes
for that type, and a comment field.</t>
<t>The initial state of the registry is as follows:</t>
<!-- [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 IANA, 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>
<thead><tr><th>Name</th><th>Defining RFC</th><th>Registry of Subtypes</th><th>Comments</th></tr></thead>
<tbody>
<tr><td>application</td><td><xref target="RFC2046"/></td><td>[<eref target="https://www.iana.org/assignments/media-types/";>Application Media Types</eref>]</td><td>-</td></tr>
<tr><td>audio</td><td><xref target="RFC2046"/></td><td>[<eref target="https://www.iana.org/assignments/media-types/";>Audio Media Types</eref>]</td><td>-</td></tr>
<tr><td>example</td><td><xref target="RFC4735"/></td><td>[Example Media Types]</td><td>no registrations, for examples only</td></tr>
<tr><td>font</td><td><xref target="RFC8081"/></td><td>[Font Media Types]</td><td>-</td></tr>
<tr><td>haptics</td><td><xref target="RFC9695"/></td><td>[Haptics Media Types]</td><td>-</td></tr>
<tr><td>image</td><td><xref target="RFC2046"/></td><td>[Image Media Types]</td><td>-</td></tr>
<tr><td>message</td><td><xref target="RFC2046"/></td><td>[Message Media Types] </td><td>-</td></tr>
<tr><td>model</td><td><xref target="RFC2077"/></td><td>[Model Media Types]</td><td>-</td></tr>
<tr><td>multipart</td><td><xref target="RFC2046"/></td><td>[Multipart Media Types]</td><td>-</td></tr>
<tr><td>text</td><td><xref target="RFC2046"/></td><td>[Text Media Types]</td><td>requires CRLF for newlines</td></tr>
<tr><td>video</td><td><xref target="RFC2046"/></td><td>[Video Media Types]</td><td>-</td></tr>
</tbody>
</table>
<t>IANA has also added pointers to this document and to the "Top-Level Media Types" registry in
the application for a media type at <<eref target="https://www.iana.org/form/media-types"/>>.</t>
</section>
</section>
<section anchor="Security" numbered="true" toc="default"><name>Security Considerations</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.
The security issues related to introducing a new top-level media type <bcp14>MUST</bcp14> be evaluated
and documented carefully.</t>
</section>
<section anchor="Acknowledgements" numbered="false" toc="default"><name>Acknowledgements</name>
<t>Continuous encouragement for writing this document came from <contact fullname="Harald Alvestrand"/>.
Further encouragement was provided by <contact fullname="Murray S. Kucherawy"/>. Both Harald and
Murray also provided ideas for actual text. Without them, this memo would
never have reached even the first draft stage.
<contact fullname="Alexey Melnikov"/> provided the difficult to find pointer
to RFC 2077 <xref target="RFC2077" format="default"/>
and examples for applications dispatching on top-level types.
Additional information and comments were received from
<contact fullname="Chris Lilley"/>, <contact fullname="Graham Kline"/>, <contact fullname="Henry S. Rzepa"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Zaheduzzaman Sarker"/>,
<contact fullname="Amanda Baber"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="John Scudder"/>, <contact fullname="Radia Perlman"/>, <contact fullname="Lars Eggert"/>,
and <contact fullname="Antoine Fressancourt"/>.
Inspiration for negative criteria or examples was provided by <contact fullname="Phillip Hallam-Baker"/>,
<contact fullname="Donald E. Eastlake 3rd"/>, <contact fullname="Petter Reinholdtsen"/>, and <contact fullname="Christian Heller"/>.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1437.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2048.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2077.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4735.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8081.xml"/>
<!-- reference if earlier update is approved.
<reference anchor="CHEMICAL"
target="https://en.wikipedia.org/w/index.php?title=Chemical_file_format&oldid=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='CHEMIME' target='https://pubs.acs.org/doi/10.1021/ci9803233'>
<front>
<title>The Application of Chemical Multipurpose Internet Mail Extensions
(Chemical MIME) Internet Standards
to Electronic Mail and World Wide Web Information Exchange</title>
<author initials='H.S.' surname='Rzepa' fullname='Henry S. Rzepa'><organization/></author>
<author initials='P.' surname='Murray-Rust' fullname='Peter Murray-Rust'><organization/></author>
<author initials='B.' surname='Whitaker' fullname='Benjamin Whitaker'><organization/></author>
<date year='1998' month='August' day='14' />
</front>
<seriesInfo name='DOI' value='10.1021/ci9803233'/>
<refcontent>Journal of Chemical Information Computer Science, vol. 38, no. 6, pp. 976-982</refcontent>
</reference>
<!-- [I-D.ietf-mediaman-haptics] RFC-to-be 9695-->
<reference anchor='RFC9695' target='https://www.rfc-editor.org/info/rfc9695'>
<front>
<title abbrev="The 'haptics' Top-level Media Type">The 'haptics' Top-level Media Type</title>
<author fullname="Yeshwant K. Muthusamy" surname="Muthusamy" initials="Y. K.">
<organization>Immersion Corporation</organization>
</author>
<author fullname="Chris Ullrich" surname="Ullrich" initials="C.">
<organization>Immersion Corporation</organization>
</author>
<date month="December" year="2024"/>
</front>
<seriesInfo name="RFC" value="9695"/>
<seriesInfo name="DOI" value="10.17487/RFC9695"/>
</reference>
</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>
</rfc>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
