Use "parse a MIME type" to check validity. #105
Conversation
|
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. |
|
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, 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). |
|
I guess I can see what you're going for now. I see these issues:
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., |
This one is tricky to pin down. Chrome supports 3 cases:
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.
How about something like: a single value for codecs= with no spaces or commas?
Awesome. Will clean this up.
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. |
|
@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.
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? |
|
@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. |
|
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 ..."? |
|
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. |
|
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"?
|
|
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).) |
|
I noticed that EME includes a definition for "valid media MIME type" in https://w3c.github.io/encrypted-media/#definitions. |
| codec, the string MUST also have one and only one parameter that is | ||
| named <code>codecs</code> with a value describing a single media codec. | ||
| Otherwise, it MUST contain no parameters. | ||
| To check if a string <var>mimeString</var> is a <dfn>valid media MIME |
There was a problem hiding this comment.
This should be named something else more specific for this specification, to avoid confusion with the one from the MIME Sniff spec.
|
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 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 |
|
"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.) |
|
Closing, as #222 addresses this. |
Resolves #69.
Preview | Diff
Preview | Diff