Is there an official mime type for KDL?

[IceDragon200]

Something like text/kdl or application/kdl, or application/vnd.api+kdl?

[zkat]

There is not. What should it be? I like text/kdl personally but idk what the rules or expectations actually are

[IceDragon200]

It depends on the usecase for example text/csv is used for plain old csv documents think of any files you would download, but application/csv would be used for APIs that generate a csv document as output, application/vnd.api+ext can be used without registration, it would be used exclusively for APIs however.

tl;dr While on disk, text/* is the expected mime, when served over an API application/* is expected.

That's my understanding of how mimes generally work, I'm not sure of the legal workings to get a mime registered which is required for text/kdl and application/kdl; application/vnd.api+kdl could be the (un)official type for apis.

[larsgw]

I understand less about the text/application distinction than I thought, I would have to take some more time to find that out. Anyway, from what I gather both text/kdl and text/vnd.kdl (the + part is a separate thing) would need to be registered, or are supposed to be at least. text/x-kdl (or text/x.kdl maybe?) is not supposed to be registered, and this kind of MIME type is used for many formats. I think the problem there is either you spend to time (and money maybe, I don't know how the registration goes) to register it immediately, or you do not and your userbase settles on a MIME type that cannot be fully registered/standardized.

[DiegoPino]

Info on how to register a new mime-type at iana is described here https://www.iana.org/assignments/media-types/media-types.xhtml, in specific this document explains the different trees and how those are handed https://www.rfc-editor.org/rfc/rfc6838.html

I would recommend on going for the vendor tree. Here are the requirements which are lower than something in the main tree (e.g text/kdl)

https://datatracker.ietf.org/doc/html/rfc6838#section-3.2,

Vendor-tree registrations will be distinguished by the leading facet
"vnd.". That may be followed, at the discretion of the registrant,
by either a media subtype name from a well-known producer (e.g.,
"vnd.mudpie") or by an IANA-approved designation of the producer's
name that is followed by a media type or product designation (e.g.,
vnd.bigcompany.funnypictures).
While public exposure and review of media types to be registered in
the vendor tree are not required, using the [email protected]
mailing list for review is encouraged, to improve the quality of
those specifications. Registrations in the vendor tree may be
submitted directly to the IANA, where they will undergo Expert Review
[RFC5226] prior to approval

[zkat]

This all sounds like we want more notability/traction in order to do any of this. So I propose we table this until #82 is able to close, at least, and revisit this then? Thoughts on that?

[IceDragon200]

I think in the meantime we could use text/x-kdl as a placeholder until there is more recognition

[marrus-sh]

You should use application/ not text/ as text/ assumes that the document is ASCII. This is the reason why the MIME type for XML, which defaults to a UTF-8 encoding, is application/xml, and why it is important to always serve HTML files as text/html;charset=UTF-8.

(There are a great many other restrictions on text/, for example they MUST canonically encode linebreaks as CRLF. See RFC2046 for the whole list, but this is why application/ is what most modern types use now.)

[bathos]

You should use application/ not text/ as text/ assumes that the document is ASCII.

@marrus-sh That hasn’t been true for a long time now — RFC 6657 is well-established. Text formats can either require a charset parameter or forbid it due to encoding being a consideration of the format itself. That includes not just cases where it’s in-band like XML, but also cases where the format itself definitionally adheres to a particular encoding (by which I mean the encoding) like certain “application” formats do.

(For HTML the rules are very convoluted for don’t-break-the-web reasons, so it’s definitely still best to set utf-8 explicitly even though it can “land there” for free now, but that’s all pretty far outside of IANA media type stuff a new format would need to worry about.)

There’s not a lot of rhyme or reason to how these top-level categories are used in practice, so while text fits the original spirit of what the category was for (a human being can read and write it; it’s not binary), it probably will make very little difference either way — I would just suggest the historical default need not be a factor for brand new media types unless there’s some specific scenario that makes it a “thing”. Open interchange of non-UTF-8 is to 2022 what open interchange of EBCDIC was to 1998.

[tabatkins]

Cool, so following 6657 we'd declare that KDL must not be specified with a charset (because it's "determined internally" and always set to utf-8). (But I would indeed wait for #82 as Kat said.)

and why it is important to always serve HTML files as text/html;charset=UTF-8.

That has nothing to do the mime type; it's just that, for historical reasons, HTML has to default to the Windows-1252 encoding.

[zkat]

I have officially submitted text/vnd.kdl to IANA for consideration. :)

[zkat]

thread here: https://mailarchive.ietf.org/arch/msg/media-types/RwIji45tSGiSFS-K0O97_0cAhK8/

[zkat]

for the record: We're required to have an actual standard, managed by an Official Standards Org (think an actual official RFC or similar) in order to remove the vnd. prefix. I thiiiiink this requirement gets "waived" for extremely popular formats that are already being widely used without the prefix even though they're not in the database (toml seems to have done this, for example), but that's a very very high bar.

It might be cool to write an RFC for KDL some day but wow that's a lot of work for very little (current) reward. Maybe when we take over the world.