HTML Media Task Force Teleconference -- 15 Oct 2013

paulc: seemed to be some discussion of taking away the offending text in the goal section
... want to return to this now?
... should we assign to someone to deal with these three bugs?

adrianba: reading the bug -- think they have the same resolution
... someone asking for use cases

paulc: so you are saying 23341 and 23342

<paulc> 23341 and 23342 are about the Goals while 23340 is about the Intro

paulc: how to deal with these?
... assign to to someone, proposed action

adrianba: proposal was made to remove the goal section -- is there consensus?

glenn: proposed we remove the goals section

<paulc> Glenn supports removing the Goals section.

<pal> I second

paulc: anyone who can't live with that?
... then proposed to resolve 23341 and 23342 by removing the goals section and ask the editors to take care of it
... do we want to do anything about the intro related bug?
... noone from task force has responded

pal: if we remove that sentence - to the end that might resolve this

<paulc> See https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#introduction

pal: could remove or change to read "this is an example flow"

<paulc> "This is just an example flow and is not intended to show all possible communication or uses."

pal: removing probably does not hurt much
... figure below just illustrates the API

<ddorwin> How about: "This is just an example flow; other combinations of APIs and events are possible."

paulc: wonder if the right way to do this is to state factually what is there?

<paulc> This diagram shows some of the interactions between the components making up a EME implementation.

glenn: figure itself probably needs some updating

<adrianba> I have removed the goals section and resolved 23341 and 23342

ddorwin: will do that once other items have stabilized

paulc: this is not meant to be proscriptive right?

<paulc> What about "This diagram shows an example flow: other combinations of API calls and events are possible."

paulc: what about this?

<ddorwin> +1

ddorwin: sounds good to me

paulc: proposal is to resolve 23340 with that text
... should remind the person in the bug that this text is non-normative

ddorwin: they are worried that this is not showing all messages

paulc: editors will respond to this then
... want to go over the tasks from last meeting

Bugs from last meeting

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854

<paulc> Next step: Update spec with resolution for issues 1 and 2.

paulc: Adrian is this what you actually did?

<adrianba> I have resolved 23340

<paulc> Marked as RESOLVED FIXED. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c22

adrianba: was actually three small simple changes to remove the keyadded event
... the step that added it, the mention and the table entry

subtopic: bug 19809

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19809

<paulc> Next step: David will re-evaluate 19809 after Ade's changes 21854 are completed.

paulc: still pending?

ddorwin: yes will take care of now

paulc: need more help from TF?

ddorwin: will read through updated text and see if anything is relevant

subtopic: bug 17202

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202

<paulc> ACTION-40?

<trackbot> ACTION-40 -- Joe Steele to Propose text for bug 17202 to propose how to share keys without leakage of information -- due 2013-10-15 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/40

joesteele: not completed

<paulc> ACTION-40 is due Oct 29

<adrianba> ACTION-40 due oct 29

<trackbot> Set ACTION-40 Propose text for bug 17202 to propose how to share keys without leakage of information due date to 2013-10-29.

paulc: last item from last time

Davids Open Bug Summary (part 2)

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0001.html

ddorwin: 17682 we did talk about and just need to resolve

<paulc> 17682 P2 Clear Key: Document how keys and key IDs are associated

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17862 is in David's hands for implementation

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

subtopic: bug 17750

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750

paulc: you and Adrian were talking about this, what is this status now?

adrianba: on this, I updated the link when I was editing this morning, rest is for David
... discussion in the bug, arriving at some agreement
... some interrelated bugs here

paulc: nothing listed as dependents

adrianba: graph would be a cycle probably
... other bugs were 21855, 17199

paulc: 21855 is on David list
... can we take action on 17750 while waiting for action? or do we need to wait?

adrianba: think the status of 21855 may be slightly different than it was two weeks ago

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855#c9 is Adrian's latest update.

paulc: do you want to discuss now?

adrianba: yes

<ddorwin> original proposal: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855#c7

paulc: is there an explicit change you are proposing?

adrianba: think that what is in the spec explicitly supports what I described

paulc: do you want to make a more detailed proposal

adrianba: everything normative is in the spec today. discussion in the bug is about the events fired for a shared key
... how does application know which events were related to a shared key?
... two session related to a shared key - not sure which gets the update call
... thats a complication we don't need to solve for
... think we would need to solve for that then

ddorwin: think there is some difference betwene the type of shared keys being discussed
... joes key is shared key between different versions of the application
... we were thinking about sharing keys between the video and audio streams
... difference in times
... firing a key message should be up to the CDM

joesteele: I agree that there are two types of keys

<glenn> yes

joesteele: ephemeral keys like video versus audio for thes application
... and long lived keys like domain and machine keys shared between applications
... to adrians points -- I am not looking for text that explicitly supports shared keys, rather that we don't have text that explicitly prevents it

glenn: my question is related to the WebCrypto key discovery spec -- provides a mechanism for sharing machine keys, might not handle domain keys

paulc: orthogonal to this bug?

glenn: posing that question to Joe

<ddorwin> I think we should have non-normative text that the CDM should ensure all sessions appear distinct (in events/states) regardless of the underlying implementation, and maybe we should call out the CREATED-to-READY transition is possible since most of the spec uses/describes the flow that includes keymessage/PENDING.

joesteele: thinking that robustness would come into play here -- would have to review the spec to make sure

ddorwin: we may also want to call out in non-normative text that applications need to handle the ready state

<Zakim> ddorwin, you wanted to note that I think we should have non-normative text that the CDM should ensure all sessions appear distinct (in events/states) regardless of the underlying

paulc: do we need a concrete proposal for 21855?

<paulc> Did we need a concrete change proposal for https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855

adrianba: think David made that proposal

joesteele: think I am ok with that text

<paulc> Editors are asked to resolve 21855 with David's proposed text.

joesteele: since it is non-normative

paulc: back to 17750 or 17919?

subtopic: bug 17750 again

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c12

paulc: you and David had come to some agreement

adrianba: some dependency on 21855 because if we want to solve for explicit sharing of keys
... that would impact the text about flow
... since we are not doing that, simplifies the resolution of this bug
... prev. I argued that we should not have close unless we had a use case for it
... Joe proposed that we would like to retain the close and be a hint to the implementation
... Mark proposed a related solution as a piece to key release
... I made a new proposal to add a CLOSED state

<paulc> Mark's related proposal is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199#c17

adrianba: and have the closed method b esomething that the application can use to ask to move to the closed state

paulc: so this is ready to be dealt with?

adrianba: think David and I are on the same page
... waiting for group consensus

s/b esomthing/be something/

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c8 for Ade's proposal.

paulc: motion to resolve using text in comment #8

<johnsim> +1

<ddorwin> +1

<paulc> In addition the c8 proposal will give us what we need to resolves 17199

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

paulc: we will resolve 17750 as proposed
... see if this produces a solution for 17919 as well
... on to waiting for action

<adrianba> ACTION: adrianba to implement proposal in bug 17750 comment #8 [recorded in http://www.w3.org/2013/10/15-html-media-minutes.html#action01]

<trackbot> Created ACTION-41 - Implement proposal in bug 17750 comment #8 [on Adrian Bateman - due 2013-10-22].

subtopic: bug 17673

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673

paulc: David had a note Sept 30 - still waiting for action?

ddorwin: are you saying we would have a CENC section and other BMFF section?

<paulc> See John's update at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c30

johnsim: we would have a CENC section and either add other sections as needed or add a generalized BMFF section
... at this point retaining the general formalization seems like a good way to move forward

ddorwin: this seems to leave the door open but contradicts the idea that we know about no other schemes

johnsim: the general formula that David Singer was proposing could be included
... another approach would be to remove all but CENC from the spec
... seems like folks on the call think specifying CENC should be specifying PSSH boxes
... adding too much complexity by making it general
... it is certain that we should have a CENC section as simple as I described
... question is whtether we need the more general section or just add new sections as demand is created

ddorwin: if we say that CENC passed back PSSH and others pass back SINF box then applications that get this won't know how to interpret the data

paulc: propose we queue up for next time, John has put in a proposal

johnsim: David you and I can exchange email on this

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991

adrianba: re: bug 20991

<adrianba> MediaKeys constructor: make CDM loading asynchronous and fix the load failure algorithm

adrianba: about loading the CDM asynchronously
... spec text as it was was broken - made an attempt at fixing
... think my change is better than what is there, but please review
... make suggestions as needed

paulc: marked as REOPENED

<ddorwin> all: Please review the event name change proposal I sent in email yesterday.

s/REOPND/REOPENED/

<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0015.html

paulc: lots of progress today
... any other business?

s/s\/REOPND\/REOPENED\///

- DRAFT -

HTML Media Task Force Teleconference

15 Oct 2013

Attendees

Contents

Agenda

previous minutes

EME status and bugs

Davids Open Bug Summary

Bugs on the goal section

Bugs from last meeting

Davids Open Bug Summary (part 2)

Summary of Action Items

Scribe.perl diagnostic output