There are some particular bugs caused by the fact, that IANA has registered MIME types, which are used de-facto as a "container" MIME type, as image/, audio/ or video/, however container MIME types should be application/ of multipart/. It causes problems to RFC compliant applications, which consider suffix and contents MIME types in conflict, if both MIME types are image/, audio/ or video/. For more see discussion in bug 1608 and http://bugzilla.gnome.org/show_bug.cgi?id=138033 This proposal says: If heuristic used in shared-mime-info can detect only data envelope, we should use non-standard application/x-type instead of standard but problematic image/, audio/, video/, official MIME types. Example: image/tiff: If heuristics will detect only TIFF file format container, it should return application/x-tiff. Only if there will be a heuristics, which can guarantee, that data inside is a regular TIFF image (and not EXIF or camera RAW file), such heuristics can use image/tiff. There is an incomplete list of affected MIME types: - image/tiff (can be exif, digital camera raw) - something needs to be done with text/xml and text/sgml (can be html, svg) - video/quicktime (can be e. g. audio/3gpp) and other A/V container data types - maybe for compressed files, where compression can be considered as a type of container, consider also ZIP or gzip as container
MIME subclassing now works, as expected, so there is no problem to use incorrectly assigned (in conflict with RFC 2046, part 1. Introduction), but standard MIME types. The only remaining drawback of using standard MIME types: We don't know, whether used heuristics recognize container MIME type or image. But it is not a big problem, because MIME type assigning can work even without this knowledge. Feel free to close this bug as INVALID or WONTFIX.
OK, thanks for the patience.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.