Define "mimetypes"

[HarHarLinks]

Link to problem area: https://spec.matrix.org

Issue
The spec references "mimetypes" all over (32 times, incl identifiers), however as far as I can tell without defining what a "mimetype" is.

I propose to

• define the meaning as "Media Types" (formerly known as MIME types) per RFC2046,
• correct the spelling across the spec to either "media types" or "MIME types",
• reference the list of types https://www.iana.org/assignments/media-types/media-types.xhtml per RFC2046 plus list any additional custom types the spec might introduce in a central place (e.g. appendix),
• leave existing identifiers untouched and continue to maintain it as a consistent name across the spec until an opportunity arises to refactor them comprehensively.

[justjanne]

Note that according to RFC 6838 Media Type Specifications and Registration Procedures media types can also contain parameters

This is actually in use in the wild, as seen e.g. in https://developers.google.com/cast/docs/media#media_type_strings or https://www.w3.org/International/articles/http-charset/index#charset

[HarHarLinks]

The parameters mentioned by Janne could in fact be pretty useful for Matrix clients, e.g. the "mimetype" as currently used usually indicates a media file's container but that fails to communicate the actual codecs in use, which could be much more helpful for a client to determine support without inspecting the file itself.

[justjanne]

This is especially useful for web clients, as the JS canPlayType API can also take a codec parameter to provide more accurate results.

[HarHarLinks]

From https://matrix.to/#/!nD4Jy1hp0We0VmIM9ubjqWLBX_uV8YlTBBPa3a_v2uk/$zj0FYgk81UCqY65sczmZFmFU-8gMji1NCK1ESxDHzOQ?via=element.io&via=matrix.org&via=starstruck.systems:

TravisR:

As base judgement, whatever Synapse and MMR consider to be a "mimetype" would be the thing to document. If there are changes beyond that, then an MSC is required. If there are places outside of the media repository which need consideration, then those should probably be documented on the issue for discussion.
Because it parses the Content-Type header (or maybe it doesn't anymore - that would be something to cite in the issue)
I'd suggest just opening a clarification PR. Worst case is someone says "uh, actually this needs an MSC", in which case the spec PR for that MSC is already written.

clokep:

I’m pretty sure synapse at least uses those various RFCs and handles parameters in MIME types. This really just feels like a clarification to me.

[HarHarLinks]

In practice, clients might sometimes send MIME types not registered at IANA, e.g. image/jpg being one of them. I think it would be reasonable for the spec to ask clients they SHOULD use registered types, but also SHOULD try to handle others as best they can.