W3C home > Mailing lists > Public > public-html-media@w3.org > November 2012

Re: [Bug 19809] New: Specify which portion of addKey() algorithm to run when updating license for a key

From: David Dorwin <ddorwin@google.com>
Date: Thu, 1 Nov 2012 09:25:10 +0100
Message-ID: <CAHD2rsiBzj6iwx7V3T_hQV5JKTUWn4fChtKUDvPWqtoLjEAnVg@mail.gmail.com>
To: Martin Soukup <martin.soukup@irdeto.com>
Cc: "public-html-media@w3.org" <public-html-media@w3.org>
On Thu, Nov 1, 2012 at 8:56 AM, Martin Soukup <martin.soukup@irdeto.com>wrote:

>
>
> -----Original Message-----
> From: bugzilla@jessica.w3.org [mailto:bugzilla@jessica.w3.org]
> Sent: Wednesday, October 31, 2012 8:31 PM
> To: public-html-media@w3.org
> Subject: [Bug 19809] New: Specify which portion of addKey() algorithm to
> run when updating license for a key
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19809
>
>           Priority: P3
>             Bug ID: 19809
>                 CC: mike@w3.org, public-html-media@w3.org
>           Assignee: adrianba@microsoft.com
>            Summary: Specify which portion of addKey() algorithm to run
>                     when updating license for a key
>         QA Contact: public-html-bugzilla@w3.org
>           Severity: normal
>     Classification: Unclassified
>                 OS: All
>           Reporter: ddorwin@google.com
>           Hardware: All
>             Status: NEW
>            Version: unspecified
>          Component: Encrypted Media Extensions
>            Product: HTML WG
>
>
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-addkey
> describes the behavior "For each individual key in |key|". This would seem
> to mean any time |key| includes a key, these operations should be
> performed, even if the CDM already had a specific key.
>
> [msoukup] the text already includes "The replacement algorithm is Key
> System-dependent." on step 3 - perhaps steps 2 and 3 should be replaced
> with this text
>

[ddorwin] Which of the many steps 2 and 3 are you referring to?

[ddorwin] The replacement algorithm was made a quality of implementation
issue because we did not want to specify how many keys are can be
stored. Since this issue relates to when events are fired at the object, it
seems like something that should be specified and consistent across
implementations. What do others think?

>
> Questions:
> #1 If a new license (i.e. renewal, update, policy change) is received with
> the same |key|, should those operations be performed?
> #2 If so, should we say "For each individual key _represented_ in |key|"
> since these subsequent licenses may not actually specify the key itself
> again?
>
> The most debatable issue might be whether to fire keyadded in this case.
> It probably makes sense to always "attempt to resume playback" because it's
> possible that the new license will allow previously stalled playback to
> resume.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
>
Received on Thursday, 1 November 2012 08:25:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 November 2012 08:25:58 GMT