Issues with MIME types

As part of my work on defining the multipart/form-data parser, I noticed a couple things in the File API standard related to MIME types:

• The MIME Sniffing standard's "parsable MIME type" definition is no longer present. It was removed as part of whatwg/mimesniff#36.
• Blob's type attribute is defined as an ASCII string, perhaps assuming that every string that would be successfully parsed as a MIME type, as well as every serialization of a MIME type, would be ASCII strings. This is not the case, as per whatwg/mimesniff#141.
• Blob's type attribute is also defined as being lowercase. And while the MIME parsing algorithm does ASCII-lowercase the MIME record's type, subtype, and parameter names, it doesn't lowercase parameter values. See whatwg/html#6251 for a case where it matters.

The second point implies that on a response coming from the fetch API that for whatever reason happened to have the MIME type multipart/form-data; boundary=cadena-de-separación (notice the ó), response.formData() might succeed but response.blob() would fail, which would seem paradoxical.

The third point implies that if, for whatever reason, there was a response coming from the fetch API which contained an actual multipart/form-data payload coming from Chromium or WebKit (since they start their boundary strings with WebKitFormBoundary), and a developer decoded it as a Blob; trying to parse that blob afterwards with new Request(blob).formData() would fail, since the boundary string seems to be parsed case-sensitively.

Start by reviewing the File API definitions for Blob's type attribute and the linked MIME Sniffing and HTML issues. Compare the current requirements for MIME parsing, serialization, casing, and non-ASCII values; the work is done when the affected specifications have an agreed, consistent resolution.