Use "parse a MIME type" to check validity.

[chcunningham]

Resolves #69.

---

Preview | Diff

---

Preview | Diff

[chcunningham]

@annevk @foolip LMK if this is more what you had in mind.

[annevk]

I think this still confuses requirements on implementations and requirements on web developers. Implementations don't have to care about validity typically. You'd parse and then do some checks on the resulting construct and that's that. And then use the resulting construct throughout the rest of your processing model.

[chcunningham]

I assume you're referring to things like how I require that at exactly one codec be supplied. This is deliberate. Past mime APIs were very relaxed and that leads to ambiguity in the API response. For instance, <video>.canPlayType("video/mp4") returns "maybe" because we don't know what codec is used. With MediaCapabilities we want to define a "valid" mime string as a way to remove this ambiguity.

Another part of that validity is ensuring that only one codec is supplied, and that it describes audio or video depending on whether it lives (VideoConfiguration vs AudioConfiguration).

[annevk]

I guess I can see what you're going for now. I see these issues:

• "imply" is not defined
• "single media codec" is not defined

We also stopped using terminology like "substeps" and when you return steps are automatically aborted so no need to state that (and no need for otherwise if the previous step would have returned if true).

The other thing I would change is that I wouldn't use "valid" here, but instead something more neutral like "correct". E.g., video/webm; might be correct (assuming it "implies" a "single media codec" for the moment), but wouldn't be valid (due to the trailing ;).

[chcunningham]

"imply" is not defined

This one is tricky to pin down. Chrome supports 3 cases:

• audio/mpeg (and nonstandard equivalents audio/mp3 and audio-xmp3 for historical reasons)
• audio/aac
• aduio/flac

AAC and Mpeg are both mpeg packet streams. Flac is its own thing. There will probably be others in the future. Any thoughts on better language here? I find myself using the word "implies" to define "imply"... not great.

"single media codec" is not defined

How about something like: a single value for codecs= with no spaces or commas?

We also stopped using terminology like "substeps" and when you return steps are automatically aborted so no need to state that (and no need for otherwise if the previous step would have returned if true).

Awesome. Will clean this up.

The other thing I would change is that I wouldn't use "valid" here...

Are you strongly opposed? "Valid" is used in some other media specs like eme and mse, and we use it elsewhere in the MediaCapabilities spec.

[annevk]

@chcunningham I think you'd basically have to define a list (including the non-standard equivalents as other browsers would presumably have to copy support for that) of MIME types that do not require a parameter.

How about something like: a single value for codecs= with no spaces or commas?

What does the implementation do here? It seems better to describe the actual algorithm. That definition is at least a little ambiguous as spaces are sometimes inclusive of different code points and sometimes mean just U+0020. I also got the impression you meant to fail if other parameters are present; that also isn't clear from this necessarily.

I'm not strongly opposed to valid, but how would you distinguish for my example? audio/aac; would be an invalid MIME type, but a valid media MIME type? That seems rather weird.

[chcunningham]

@mounirlamouri, see points about creating a list of "implies-a-codec" mime types. Should we make a registry for this similar to MSE's bytestream registry? Also, welcome input on discussion in general.

[mounirlamouri]

I found the "imply" a bit confusing too when reading the spec. My understanding is that those are special cases where "codecs" isn't required, is this correct? I think whitelisting them would work but we may want to make sure that at least the ones we put are widely supported (at least 2 implementations).

Regarding "validity", would it clarify if we were using "valid codec MIME type" instead of "valid media ..."?

[annevk]

I think avoiding the word "valid" is still best, given what it means in the context of MIME types, and that not being the meaning you're looking for here.

EME also doesn't mean "valid" I think and MSE just talks about supported. "Supported" might be an okay word to use.

[mounirlamouri]

Supported has a different meaning as we would have to check if the mime type is "valid" to check if it is supported. What if we call the algorithm "a mime type represents a media codec"?

[annevk]

Fair, in that case I'll defer back to my earlier "correct" suggestion or perhaps "parsable" or some such. (Rationale is at the end of #105 (comment).)

[chrisn]

I noticed that EME includes a definition for "valid media MIME type" in https://w3c.github.io/encrypted-media/#definitions.

[marcoscaceres]

This should be named something else more specific for this specification, to avoid confusion with the one from the MIME Sniff spec.

[marcoscaceres]

Requesting name change to dfn.

[chrisn]

This PR is a bit out of date with the latest spec changes (e.g., we now have "valid audio MIME type" and "valid video MIME type").

Anne said:

I think you'd basically have to define a list (including the non-standard equivalents as other browsers would presumably have to copy support for that) of MIME types that do not require a parameter.

I wonder if the way ahead should be to create a registry of the accepted (is this a better word than "valid" here?) audio and video mime types, which would identify those where a codecs parameter is can be used or not.

[annevk]

"Valid" is really a requirement about meeting some syntax definition, but user agents do not implement validators. They implement parsers. So you want to parse MIME type inputs into MIME types (using https://mimesniff.spec.whatwg.org/#parse-a-mime-type to get https://mimesniff.spec.whatwg.org/#mime-type) and then inspect their various properties.

"Accepted" or "supported" might make sense, depending on what you are trying to define. It might also make sense to make it an algorithm that determines whether some input "is an audio/video MIME type". (Similar to how we have https://mimesniff.spec.whatwg.org/#javascript-mime-type for JavaScript, which is likely a fair bit simpler.)