Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unprefixed MIME type #460

Open
zkat opened this issue Jan 3, 2025 · 0 comments
Open

Unprefixed MIME type #460

zkat opened this issue Jan 3, 2025 · 0 comments

Comments

@zkat
Copy link
Member

zkat commented Jan 3, 2025

With #159 closing, kdl received an official IANA MIME type of application/vnd.kdl. This was relatively easy because the requirements for the “vendor” tree (vnd.*) are much more relaxed than for “unprefixed” media types.

It was a bit unclear what it would take to establish a new unprefixed one (application/kdl), so I reached out steer noticing that there’s been some recent registrations, like application/toml, that did not seem to meet me stated requirements.

Here is the response from IANA:

What's frequently called the "top level" is actually application, audio, text, etc. "vnd." is referred to as the prefix, and it's used for registrations in the "vendor tree." Another prefix, less common, is "prs.", which indicates registration in the "personal tree."

Registrations without a prefix are (possibly with some older exceptions that I'm not aware of) called "standards tree" registrations, and RFC 6838 (primarily Section 3.1) makes that registration process relatively difficult. One of these approaches is required:

1a) Documented in and registered by an RFC produced within the IETF

1b) Documented in and registered by an "independent submission" RFC (in this case, the type itself also has to be approved by the IESG, the IETF's steering group). This approach requires that the Independent Stream Editor be willing to publish the work, and we haven't seen them take on a media type registration RFC in recent years.

  1. Requested by a standards organization recognized by the IESG (a list of SDOs that have been allowed to request standards tree registrations is available at https://www.iana.org/assignments/iesg-recognized-organizations), then approved via the usual process by IESG-designated experts.

  2. Grandfathered at the suggestion of an IESG-designated expert, with approval from the IESG.

A couple of types (application/stratum, application/toml) have been grandfathered in recent years. In those cases, the expert was interested in seeing evidence of wide use as well as documentation.

I'm going to close this ticket, but let me know if you want to pursue one of the above.

As such, I don’t think we meet any of these requirements as of yet. In order to eventually have application/kdl, I see two paths forward that seem reasonable to generally aim for:

  1. We go through the process of writing a full-on IETF RFC and getting it approved. This is not a simple or easy process at all, and I don’t think it makes sense to start something like that just yet.
  2. KDL becomes so popular that the reviewing expert would be satisfied that it meets some unspecified bar for “widespread use”. If you were to ask me, we’re not there yet, even if there’s thousands and thousands of kdl files on GitHub. For comparison, there are about 4.2 million .toml files on GitHub as of this post. I imagine it would be easy to make the argument for unprefixed registration once we hit the millions. So LFG! See the argument made for TOML to the IANA
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant