W3C home > Mailing lists > Public > public-html-media@w3.org > July 2014

Re: Request for feedback on EME Use Cases

From: David Dorwin <ddorwin@google.com>
Date: Thu, 24 Jul 2014 12:03:45 -0700
Message-ID: <CAHD2rsgxzyStryBRQ+FcE7Fetix08rzh1aPRFNHYkPQnfcxL8A@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Joe Steele <steele@adobe.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
I believe the text as of July 22nd was correct.

"persistent" is a **session** type and does not specify the license type.
This was intentional. Is there text that is inconsistent with this?
"persistent" is used as part of the normative algorithms to define allowed
behavior. For example, session loading and removal is supported. (The
license specifies whether to persist the keys.)

I have updated the wiki at
https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Release
to describe the behavior. I'll continue this discussion in the loadSession
thread.

David

On Tuesday, July 22, 2014, Mark Watson <watsonm@netflix.com> wrote:

> Hi Joe,
>
> I don't think the description for secure proof of key release is correct,
> This should definitely not require a "persistent" license (the secure proof
> of key release and license persistence are orthogonal). Now I look at this,
> there is confusion in the specification between "persistent session" and
> "persistent license". Secure proof of key release needs the session to be
> recoverable later, in case the key release could not be delivered, but does
> not require the license to be persistent.
>
> ...Mark
>
>
> On Mon, Jul 14, 2014 at 1:59 PM, Joe Steele <steele@adobe.com> wrote:
>
>> I have completed my changes to the EME Use Cases wiki (
>> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases).
>> I don’t think I can add much more to the general use cases without more
>> constructive feedback from the group.
>> Thanks to those of you who have looked and given feedback. For the rest —
>> please take a look.
>>
>> I think we specifically need feedback on:
>>
>> * Are there general use cases that we should be supporting that are not
>> there?
>> * Are any of these use cases unsupportable by your DRM?
>> * Is the level of detail sufficient?
>> * Any additional key delivery mechanisms?
>> * Are any of the current key delivery mechanisms objectionable?
>>
>> Joe Steele
>>
>> p.s. I apologize for not sending this sooner — it was sitting in my
>> Outbox during my vacation. :-(
>>
>
>
Received on Thursday, 24 July 2014 19:04:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:04 UTC