(In general it would be good to build more on the MIME Sniffing infrastructure here.)

@foolip @annevk questions as I'm taking a look at this.

I see the mimesniff spec defines both #valid-mime-type and the algorithm #parsing-a-mime-type.

Why doesn't #valid-mime-type reference #parsing-a-mime-type? Then we could take a reference on #valid-mime-type and transitively reference the parsing algo.

As I write the steps to define a valid mime type from MC perspective its counter intuitive to reference #parsing-a-mime-type rather than #valid-mime-type. Especially since #valid-mime-type seems to be more strict.

One is for web developers and the other for user agents. User agents have historically been somewhat forgiving, so we cannot really make them stricter, but it makes sense for web developers to be recommended to use a subset if you will for maximum interoperability (and in case we ever need to make some breaking change outside of that subset for extensions or some such).

Thanks, makes sense. I think I missed the note:
"A valid MIME type string is supposed to be used for conformance checkers only."

Related: w3c/encrypted-media#511

Ok, we have some interop issues here:

Given:

await navigator.mediaCapabilities.decodingInfo({ type: "file", audio: {contentType: "audio/mp3;" }})

Chrome rejects. Firefox and WebKit don't. The spec (although not using MIME Sniff) says that it should reject.

I think you probably want to make that work. And it would probably make sense to run a bunch of the MIME type parser tests through that API (they're in mimesniff/ in WPT somewhere).