Closed Sec-ant closed 11 months ago
It's a mix of the IANA and a bunch of hand collections and corrections. There's probably some minor inconsistencies there that still need to be fixed but we're squashing them as they're noticed.
@patrickmccallum do you think that being rigourous about the sources to justify some minetype to be added here, is a requirement or not?
In my personal opinion, using some official sources (like you said IANA, but also MDN web docs and RFCs) can give this project a lot of credibility.
But it's only my opinion and I'm not trying to impose anything. At this time, you decide the rules, because it's your project. If you think that there shouldn't be any official sources to justify a mimetype in this site, no problem.
I think this project is awesome. I discovered it for accident, but I like it.
Thanks for the info and your hard works. I don't think I have more questions. I'm closing this.
@patrickmccallum do you think that being rigourous about the sources to justify some minetype to be added here, is a requirement or not?
In my personal opinion, using some official sources (like you said IANA, but also MDN web docs and RFCs) can give this project a lot of credibility.
But it's only my opinion and I'm not trying to impose anything. At this time, you decide the rules, because it's your project. If you think that there shouldn't be any official sources to justify a mimetype in this site, no problem.
I think this project is awesome. I discovered it for accident, but I like it.
I've been trying to keep the sources in the further reading section, maybe a way to mark them as "source" or "official" would help?
I think that section is enough, maybe a way to tell 'this is where the mimetype specification came from' kind of thing would help, but I don't think it's a big requirement. Linking the right sources is enough, and that should be a requirement for any new mimetype request.
My question was more related to the project, if someone requests for a new mimetype to be added, the mimetype must be motivated.
I think that section is enough, maybe a way to tell 'this is where the mimetype specification came from' kind of thing would help, but I don't think it's a big requirement. Linking the right sources is enough, and that should be a requirement for any new mimetype request.
My question was more related to the project, if someone requests for a new mimetype to be added, the mimetype must be motivated.
For sure, and there's a section in the new issue template which asks for authoritative sources iirc. There's still a pending merge for a zig file one that I haven't accepted because I can't actually find it anywhere, even in their own mimetype implementation of types to file extensions.
Agreed on properly calling out where the type came from and if it's considered official or not, feel like we made good headway on this with the new notices config in the mimeData for calling out "popular" vs "official", and the new communityContributed and hasNoOfficial tags. Community will be pretty rare, and probably almost always in conjunction with hasNoOfficial, e.g. if browsers are reporting a mimetype but there's zero authoritative sources available.
For sure, and there's a section in the new issue template which asks for authoritative sources iirc.
Good, sorry I didn't see that.
Would you clarify what do you mean by 'community contributed', and 'has no official'? I'm not sure to understand the meanings they have for you.
Is community contributed when someone requests to add a new mimetype? Has no official when there are non authoritative documentation? Are there cases of reported minetypes by browsers, without an authoritative source? I was thinking of audio/wav..
Hi, there, thanks for providing this awesome tool.
May I ask a question as stated in the title: What are the sources of the
mimeData.json
? Are they hand-collected from different places or if there is a major source where most of them come from?