Intersect the contents of Hdr:FileTypes post 2015 with the IANA MIME type allocations, for those entries which are missing. Those being:
Additionally:
ROOL (0501d155) at 23 Mar 11:51
Backfill MIME types for recent filetype allocations
This integrates the MimeTypes file from DigitalCD, with minor modifications to sort by IANA registration status.
ROOL (5bd81563) at 23 Mar 11:50
Update MimeMap with more audio formats
ROOL (a389f58d) at 15 Mar 23:00
Updated trusted root CA data
ROOL (e320ec97) at 15 Dec 23:00
Updated trusted root CA data
I've added an extra entry for Monkey's Audio, which was provided by André in a follow-up email.
OK, I've removed it for now.
If it's correct (without the 'a') rather than a typo, it should be left alone - the filetype name is an allocated quantity so can't be changed without doing an allocation request.
According to André, "For "FstTk" instead of "FastTk", I think it came from the fact that FastTracker was often referred to as Fst in reference to the .fst extension version 1 used (MOD format but with more channels)."
Personally, I have a slight preference for FstTk
over FastTk
, but I can change it anyway if necessary.
I emailed André Timmermans yesterday, and the response I got was "I have seen your merge request and have no problem with it."
This integrates the MimeTypes file from DigitalCD
Is the author of DigitalCD aware of this? The license included with it defines The Software as being DigitalCD and related files (which would include the MimeMap file), yet later has a clause that no charge may be made other than media costs. RISC OS is used in situations where it is sold with a computer or SD card for more than media cost, contravening that clause.
According to google XM files are written by Fasttracker 2, any reason why it's not FastTk
which is within the 8 character limit?
Copy/paste mistake? This looks like Mac types, which MimeMap doesn't support.
When !18 was merged, the entries for the personal use types were removed, but the extensions for the various application/x-zmachine
entries weren't added to the one that was kept. This merge request fixes that.
A round trip via MIME types will, in effect, re-type z1-z8 to &11A as well because they all go via
application/x-zmachine
.
This should only be an issue for people editing the MimeMap file to add entries for file types &061-&068. At the moment, a file with the extension ".z5" won't be mapped to &065 or &11a, and will instead just use a generic default type.