search

w3c / encrypted-media

Encrypted Media Extensions
https://w3c.github.io/encrypted-media/
Other
180 stars 79 forks source link

Get Supported Capabilities algorithm appears to conflict with RFCs specifying MIME types #373

Open jrummell-chromium opened 7 years ago

jrummell-chromium commented 7 years ago

Currently the algorithm "3.1.1.3 Get Supported Capabilities for Audio/Video Type" [1] has step: 3.8 If the user agent does not recognize one or more parameters, continue to the next iteration.

However, RFC2045 ("Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"), which defines the basic rules for parsing MIME types, has the statement "MIME implementations must ignore any parameters whose names they do not recognize." This seems to imply that unrecognized parameters should always be ignored.

RFC2045 is not directly referenced from the spec. However, RFC6381, which is referenced in the algorithm, includes "The syntax in this document uses the BNF rules specified in [RFC2045] and [RFC2231]."

I also note that RFC6381 documents the "profiles" parameter (in addition to "codecs"). Since it is up to the implementation whether they support "profiles", it may affect cross-browser compatibility to skip capabilities with unrecognized parameters.

[1] http://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type

ddorwin commented 7 years ago

The following statements appear at the beginning of that same paragraph:

Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype.

I do not believe the first statement is true, especially for codecs. The second statement could be true, but I'm not sure this is enforced, such as by RFC6381.

Also, I'm not sure that using MIME types as defined by RFC2045 makes EME a "MIME implementation," which is what the referenced statement applies to.

From a practical perspective, I think the uses and needs of MIME types in RFC2045 and EME (and generally media content type strings on the web) are very different. In the former case, a MIME implementation should try to handle the content. In the latter, we want to tell the app that the user agent is confident that it can play the content. Since there is a mechanism for picking another piece of content, not accepting something the user agent is unsure of seems appropriate.

On a related note, #415 deals with how the spec references MIME types.

/cc @mounirlamouri