This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. 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.
I don't think we can make any changes here until we resolve bug 20688.
Bug 21854 replaces bug 20688.
Discussed on telcon 2013-10-01. David will evaluate to see if any new action is need once bug 21854 is resolved.
keyadded will be removed per bug 21854. I'll reevaluate after keyadded is removed to see where we can simplify. Resuming playback seems to be the remaining item we want to include.
(In reply to David Dorwin from comment #0) > #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? Other information related to keys may be stored, though not explicitly listed in the steps. The storage algorithm specifically relates to keys, so I think it's fine as is. More importantly, the key storage algorithm describes deleting and replacing keys but does not specify the context - that is, whether it is within the session or the MediaKeys. This text was originally written in the context of HTMLMediaElement, so it is referring to MediaKeys. However, deletion is probably not the right action when sessions overlap. I'm leaning towards deleting the key storage algorithm and noting that it is CDM specific. I think overlapping keys should not be deleted such that when one session is closed, an overlapped key in another session is available. (In reply to David Dorwin from comment #0) > 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. There may be cases where no new key is stored (as in the current algorithm) but playback becomes possible. Given this and the possible removal of the key storage algorithm, we may want to remove "did store key" and always try to resume playback when waiting for a key. Finally, |key| is a misleading and inappropriate name for update()'s parameter. We should rename it. I can file a separate bug, but this is a good context to be thinking about that as well.
(In reply to David Dorwin from comment #5) ... > I'm leaning towards deleting the key storage algorithm and noting that it is > CDM specific. I think overlapping keys should not be deleted such that when > one session is closed, an overlapped key in another session is available. Changeset https://dvcs.w3.org/hg/html-media/rev/6b1b0aa1415c removes the key storage algorithm and adds non-normative text about CDM behavior related to keys and sessions. ... > There may be cases where no new key is stored (as in the current algorithm) > but playback becomes possible. Given this and the possible removal of the > key storage algorithm, we may want to remove "did store key" and always try > to resume playback when waiting for a key. Changeset https://dvcs.w3.org/hg/html-media/rev/6b1b0aa1415c removes "did store key" and changes the algorithm to always attempt to resume playback when waiting for a key unless an error occurred. > Finally, |key| is a misleading and inappropriate name for update()'s > parameter. We should rename it. I can file a separate bug, but this is a > good context to be thinking about that as well. Changeset https://dvcs.w3.org/hg/html-media/rev/cf1786f8f616 renames |key| to |response|. We can iterate on the name, but this at least removes the confusion.