[encrypted-media] Steps regarding satisfying robustness requirements in "Get Supported Capabilities for Audio/Video Type" algorithm can be misinterpreted

cpearce has just created a new issue for 
https://github.com/w3c/encrypted-media:

== Steps regarding satisfying robustness requirements in "Get 
Supported Capabilities for Audio/Video Type" algorithm can be 
misinterpreted ==
The "Get Supported Capabilities for Audio/Video Type" algorithm as 
specified can be interpreted in several ways. The language needs to be
 tightened up.

In step 13 of the algorithm, it states:

>13. If the user agent and implementation definitely support playback 
of encrypted media data for the combination of container, media types,
 robustness and local accumulated configuration in combination with 
restrictions:
>NOTE  requested media capability (content type and robustness) must 
be supported with all previously added requested media capabilities.
>> 1. Add requested media capability to supported media capabilities. 

...and in step 2 after adding the requested media capability to the 
local accumulated configuration, the algorithm states:

>> NOTE  This step ensures that configurations are always checked with
 configurations from previous iterations, including from previous 
calls to this algorithm. Otherwise, only configurations from previous 
calls to this algorithm would be checked in subsequent calls.

It seems to me that one way to read that would be that all robustness 
requirements in previously added MediaKeySystemMediaCapabilitys must 
be also be satisfied in any new MediaKeySystemMediaCapabilitys that we
 add. That means we'd need to apply video restrictions to audio for 
example, which seems wrong.

For example, if we've added a video capability with secure-decode 
robustness, then we considered adding an audio capability with only 
secure-decrypt capability, we'd be obliged to refuse to add the audio 
capability, since secure-decrypt is not as robust as secure-decode.

Another way to read this would be that every 
MediaKeySystemMediaCapability that we add must satisfy its own 
robustness requirements, and that implies that all added 
MediaKeySystemMediaCapabilitys satisfy their requirements. But if that
 was the interpretation, then why would we need the _local accumulated
 configuration_?

Or another interpretation could be that all previously added 
MediaKeySystemMediaCapability's robustness requirements can be 
supported _when used together with_ the MediaKeySystemMediaCapability 
being considered for addition?

That last interpretation I think would make the most sense. The 
wording should be made clearer here.


Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/262 using your GitHub 
account

Received on Tuesday, 5 July 2016 23:23:50 UTC