Fixup MIME usage

[marcoscaceres]

Closes #69

this is a draft... it doesn't actually address all the issues with MIME usage yet... just a start.

---

Preview | Diff

[chrisn]

This PR replaces valid media MIME type with algorithmic steps. It could lead to similar changes to valid video configuration all the way up to valid MediaConfiguration. Please comment if you see any issues with the direction this is taking.

@aboba One specific question, as we develop this PR: section 2.1.4.2 RTP currently references RFC4855 and RFC6838, which define registration requirements. This PR proposes changing these to reference https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml instead. Is this OK?

[chrisn]

This is ready for review. PTAL @mfoltzgoogle, @aboba, @alastor0325, @marcoscaceres

The PR makes two main changes:

• Replace "valid media MIME type"
• Changes other algorithms to use the abstract-op dfn type

If needed we can tackle "valid video configuration" etc in follow-up PRs.

[markafoltz]

LGTM with one side comment, nice PR @marcoscaceres

I just did a first read of the spec and wondered if a long term possibility is to decouple from mime types along the lines of the WebCodecs registry. However, the registry is missing a bunch of codecs though that may never be supported in WebCodecs, and container parsing support seems to be out of scope for WebCodecs as well.

[chrisn]

There's a similar discussion in this EME issue: w3c/encrypted-media#559. I think a registry could help, but also recognise Joey's concerns in w3c/encrypted-media#559 (comment). This might be one to talk about at TPAC.

[markafoltz]

@adoba, bumping the question above in #222 (comment):

One specific question, as we develop this PR: section 2.1.4.2 RTP currently references RFC4855 and RFC6838, which define registration requirements. This PR proposes changing these to reference https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml instead. Is this OK?

[markafoltz]

@chrisn per https://www.w3.org/2024/09/26-mediawg-minutes.html#a01:

ACTION: cpn to update the Media Capabilities PR to refer to the main MIME type registry

After that is done, this should be ready to merge.

[chrisn]

I've added the link to the IANA media type registry, as well as bringing back the references to the RTP specific RFCs.

[chrisn]

@markafoltz I have removed the RFC4855 reference as we discussed in today's meeting (minutes). The PR is ready for your review. Many thanks.

[markafoltz]

This looks good, with a couple of spots I noted where steps could be simplified or the order changed to be more logical. Nothing that blocks merging IMO.

[markafoltz]

This is ready for another round of review @marcoscaceres

Summary of major changes:

• I removed the slot definition per feedback from @marcoscaceres. It means we are invoking MIME parsing twice per call in the spec, but implementations can surely optimize that away.
• The "correct type" and "single codecs" steps are factored out into a new algorithm, Check MIME Type Validity, so they are not repeated for audio and video configurations. These steps also have to be separate from Check MIME Type Support - they reject, instead of just reporting unsupported.
• Various other bug fixes are applied to the Create a MediaDecodingInfo / Create a MediaEncodingInfo steps and hopefully they are clearer now.

I believe this reflects current browser behavior, except for one specific issue around webrtc (#238), which I do not want to block on. I would ask that further feedback focus on spot editorial fixes and places where the logic is self-inconsistent, and further refinement of logic to match browser behaviors be done in follow-up PRs.