This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The canPlayType() method provides a simple capability detection mechanism for Key System capabilities. If multiple versions of a protection system exist with different capabilities, these can be allocated distinct identifiers by the owner of that Key System. This can be extended even to feature discovery, for example "com.example.somesystem.ignite" and "com.example.somesystem.explode" might identify features of the "com.example.somesystem" keysystem. Is this usage is desirable and sufficient ?
In order to support interoperability I believe that this needs to be specified within a given Key System at least. It may be sufficient to require that any supported Key System must define a common mechanism for identifying capabilities across implementations. I believe we are unlikely to succeed in specifying capabilities in a useful but cross-Key System way but defining the framework has value in my opinion. Specifically defining how versions and capabilities can be queried and what the behaviour is when querying in a version-less manner, if this is supported. I assume from the current issue description that this would cover concepts such as domain support and embedded licenses? Would it allow things like querying whether the UA is a member of a given domain?
(In reply to comment #1) > I assume from the current issue description that this would cover concepts such > as domain support and embedded licenses? Would it allow things like querying > whether the UA is a member of a given domain? The key system string is targeted at determining the presence of a specific system and telling the UA to use it. The intent is to allow an application to make quick synchronous decisions on the type of license to request and possibly which content stream to provide. In this way, the application can avoid providing content and licenses that the UA cannot use. It seems reasonable to expect that specific versions or even sub-products of a key system might need to be identified. These might even indicate a "level" of robustness. The key system string does not provide any assurances of capabilities, so the server and CDM are responsible for actual enforcement via their message exchange. The key system string in generateKeyRequest() might indicate to the CDM some configuration class (to be used in preparing the message), but specific requirements should be specified in the license provided to addKey(). The question is whether this is sufficient. For example, does the application need to be able to determine current platform state and not just CDM capabilities. I don't think key system is appropriate for current state because at least some states likely cannot be determined synchronously. Also, the strings used for canPlayType() and generateKeyRequest() should probably be identical, so using strings to perform detailed capability queries in canPlayType() should probably be avoided. To answer your question, I think querying for a given domain should either be done within the key exchange flow or using some TBD mechanism. Support for embedded licenses (with the assumption that one would exist if supported) might fall under "robustness level" identification.
We propose not overloading key system strings with capability detection. We should consider if we need a separate capability detection system.