"valid MIME type" does not link to the definition of a valid MIME type

[ddorwin]

In the contentType defintion, the link for "valid MIME type" currently links to [1]. The definition of "valid MIME type" is actually at [2].

Note that while other sections in the page at [1] link to [2], the section at [1] does not link to [2]. It only references [3].

[1] is nice because it provides a media-specific view of MIME types, including mention of RFC 6381, but it does not define validity. It would be nice if there was a definition for "valid media MIME type." In the meantime, we may want to change the wording.

Related to this, the actual algorithm that processes contentType does not reference a definition for "invalid or unrecognized MIME type." We may want to apply the same fix there.

[1] https://www.w3.org/TR/html51/semantics-embedded-content.html#mime-types. [2] https://www.w3.org/TR/html51/infrastructure.html#valid-mime-type [3] https://www.w3.org/TR/html51/infrastructure.html#mime-type

[ddorwin]

For reference/comparison, Media Capabilities has a MIME types section that defines "valid media MIME type" in terms of (the WHATWG equivalent of) [2].

While Media Capabilities mentions a "parameter that is named codecs," it does not reference RFC 6381. In contrast, EME mentions codecs but generically allows the "the RFC 6381 [RFC6381] parameters." (In practice, only the "codecs" parameter is used with EME.)

Most of these inconsistencies and needs could be addressed by a central definition of "valid media MIME type" if available.

/cc @mounirlamouri

[ddorwin]

For now, I suggest we add a definition to EME for "valid media MIME type" that uses [2] but references [1] and (explicitly) RFC 6381.

We can then use that definition in the contentType defintion and related algorithm.

[jdsmith3000]

This seems reasonable. The reference 1 is currently used for "valid MIME type", and reference 2 is better for that.