You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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:
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.
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
The text was updated successfully, but these errors were encountered:
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, likeapplication/toml
, that did not seem to meet me stated requirements.Here is the response from IANA:
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:The text was updated successfully, but these errors were encountered: