[Bug 27124] Add "individualizationrequest" to the MediaKeyMessageType enum

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124

--- Comment #13 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #11)
> (In reply to Joe Steele from comment #9)
> > Looking back at bug 26683, where this change was introduced, I notice that
> > the list of enums you chose to put in the changelist did not include two of
> > the message types you referred to in the bugs initial description [1]. You
> > referred to heartbeat and initialization as known use cases. The omission of
> > those use cases seems to be rather arbitrary, since you did not include any
> > justification for it in your closing comment.
> 
> My reference to "heartbeat" was a mistake - the use case I was thinking of
> was renewal, which I did include. I didn't know anyone else wanted heartbeat.
> 
> The main goal of that bug and the changeset was to implement the API change,
> not necessarily all possible types. The initialization was (and is) pretty
> unclear to me, and I didn't add things I didn't understand or wasn't sure we
> would need (better to add than have to remove). My closing comment said, "We
> can add more types to the enum if necessary (file a bug)." This all seems to
> have worked as intended.
> > 
> > In addition to the "initializationRquest" Henri mentioned -- I would like to
> > see "heartbeatRequest" added as well. Would you like me to file a separate
> > bug?
> 
> Do you have a use case for heartbeat or is this just for completeness with
> bug 26683? If the former, please file a bug. We may want to discuss whether
> we need/want both renewal and heartbeat types.

We do actually have a "heartbeat" use case. The usage up till now has
apparently been confusing -- I thought we were talking about the same thing. In
our heartbeat use case, the server is providing a time check for the client.
Since desktop devices rarely have anti-rollback clocks (at least that are
accessible) this allows the client to verify its own clock for checking license
expiry.

I don't believe this use case is critical for the initial release (although I
will need to double check). If it is -- I will submit a separate bug. We should
probably update the Use Case wiki to reflect this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 24 October 2014 23:54:41 UTC