W3C home > Mailing lists > Public > public-html-media@w3.org > January 2016

[encrypted-media] Gracefully handling implementations that do not support setServerCertificate()

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Jan 2016 20:38:07 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-129574070-1454013486-sysbot+gh@w3.org>
ddorwin has just created a new issue for 

== Gracefully handling implementations that do not support 
setServerCertificate() ==
As noted in the algorithm, Key Systems and specific CDM 
implementations may not support server certificates or providing them 
 For such implementations, the spec says to reject the promise with 

An application that uses this method but does not explicitly handle 
`NotSupportedError` could unnecessarily fail when run on such 

One option is to add a Note explicitly noting that applications should
 gracefully handle a rejection with `NotSupportedError` (while still 
seeing other rejections as unexpected failures). However, that seems 
like a strange requirement to place on applications when not 
supporting this method is allowed _and_ this "failure" does not 
negatively affect the rest of the application. (In other words, there 
is no exceptional behavior that needs to be executed.)

Alternatively, we could change the algorithm to resolve (while 
indicating that that the call did not actually do anything). This 
seems more consistent with 
 (This was the same principle that resulted in 
[`load()`](https://w3c.github.io/encrypted-media/#load) of an 
unrecognized session resolving with `false`.

Therefore, I propose changing `setServerCertificate()` to return a 
`Promise<boolean>` where the Boolean is `true` on success (current 
step 6) and `false` when the CDM does not support the operation 
(current step 2).

Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/145 using your GitHub 
Received on Thursday, 28 January 2016 20:38:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:07 UTC