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

Is there an official mime type for KDL? #159

Open
IceDragon200 opened this issue Sep 14, 2021 · 9 comments
Open

Is there an official mime type for KDL? #159

IceDragon200 opened this issue Sep 14, 2021 · 9 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@IceDragon200
Copy link
Contributor

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

@zkat
Copy link
Member

zkat commented Sep 14, 2021

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

@zkat zkat added enhancement New feature or request help wanted Extra attention is needed labels Sep 14, 2021
@IceDragon200
Copy link
Contributor Author

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
Copy link
Contributor

larsgw commented Sep 14, 2021

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
Copy link

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
Copy link
Member

zkat commented Sep 14, 2021

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
Copy link
Contributor Author

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

@marrus-sh
Copy link

marrus-sh commented Sep 5, 2022

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
Copy link

bathos commented Oct 1, 2022

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

7 participants