Fix normative notes and clarify/simplify robustness rules #549
Conversation
joeyparrish
requested review from
chrisn,
gregwfreedman,
marcoscaceres and
xhwang-chromium
| levels specified in the configuration of the {{MediaKeySystemAccess}} object used | ||
| to create the {{MediaKeys}} object. |
There was a problem hiding this comment.
| levels specified in the configuration of the {{MediaKeySystemAccess}} object used | |
| to create the {{MediaKeys}} object. | |
| levels specified in the configuration of the {{MediaKeySystemAccess}} dictionary used | |
| to create the {{MediaKeys}} instance. |
There was a problem hiding this comment.
I think "MediaKeySystemAccess object" is right here - it's an interface, whereas MediaKeySystemConfiguration is a dictionary.
| Applications are recommended to specify the robustness level(s) they require, | ||
| if any, to avoid unexpected client incompatibilities. |
There was a problem hiding this comment.
| Applications are recommended to specify the robustness level(s) they require, | |
| if any, to avoid unexpected client incompatibilities. | |
| To avoid unexpected interoperability issues, developers are encouraged to provide the robustness level(s) | |
| (if any). |
marcoscaceres
left a comment
marcoscaceres
left a comment
There was a problem hiding this comment.
Couple of wording suggestions... I'm not very familiar with how EME works, so would need someone else to check the technical details.
chrisn
left a comment
chrisn
left a comment
There was a problem hiding this comment.
Sorry for taking so long to respond. I left one comment for consideration.
I notice there's a few other Notes that contain normative statements that we'll need to review too.
| highest robustness level in the configuration even if a higher robustness level | ||
| is available. If only the empty string is specified, implementations MAY be | ||
| configured to use the lowest robustness level the implementation supports. | ||
| Exact configuration of the [=CDM=] is implementation-specific. |
There was a problem hiding this comment.
We may want to remove the note entirely, and keep the "implementations MAY configure" language.
Issue #521
This clarifies current reality in implementation, and may be enough to close the issue on that basis. But I plan to propose one small behavioral change after this clarification, which there may or may not be consensus on.
Preview | Diff