Re: Request for feedback on EME Use Cases

In createSession(), step 7.3.3, we have: If sessionType is "temporary", the
request is for a temporary non-persisted license. If sessionType is
"persistent", the request is for a persistable license."

​and possible in other places. So this is where there is an explicit
linkage made between persistent *sessions* and persistent *licenses*.​

...Mark


On Thu, Jul 24, 2014 at 12:03 PM, David Dorwin <ddorwin@google.com> wrote:

> 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. :-(
>>>
>>
>>