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?