HTML Media Task Force Teleconference -- 18 Aug 2015

<trackbot> Date: 18 August 2015

<paulc> Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html

<jdsmith> jdsmith +present

<paulc> help present

<joesteele> scribe: joesteele_

<paulc> Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html

Issue 45, pull request 54

<joesteele> paulc: Google presented a technical position paper

<joesteele> … multiple calls for secure release to be put back in the spec

<joesteele> … late emails still addressing this

<joesteele> … let’s go around and discuss what should happen

<joesteele> … and find out how much concensus we have

<joesteele> … unless folks have questions, we probably don’t need to dig much more on this

<joesteele> markw: David raised some interesting points but don’t think it fully replaces the secure release outlined

<joesteele> … David has pointed out some client spec issues, but don’t believe they cannot be addressed by all browsers

<markw> I don't think the client issues raised are "web architecture: issues suitable for the TAG

<joesteele> jdsmith: I did not respond in a technical manner to the license renewal post, but we have some concerns about scalability

<joesteele> … but we do have partners asking for this, industry demand

<joesteele> … we think it should be in the spec to be interoperable and not too difficult to address

<joesteele> … agree that this should be addressed in the task force

<paulc> Is BobLund on the phone?

<joesteele> joesteele: we agree that the license renewal is interesting but do not feel it 100% replaces the secure release as we have implemented

<joesteele> BobLund: I can comment in a minute — hold on

<joesteele> q:

<joesteele> paulc: David do you want to speak?

<joesteele> BobLund: I want to re-iterate our support for seure release — we have service provides who want to use it

<ddorwin> Can people hear me (before Bob started talking)?

<joesteele> … we are seeing multiple browsers, and multiple service providers implementing this

<paulc> No we could not hear you. Sorry.

<jdsmith> To ddorwin: I didn't hear you speak...

<joesteele> paulc: do you have a position on license renewal?

<joesteele> BobLund: License renewal is also used in some cases, but at least one of our members sees a need for both

<joesteele> … dont think one is a replacement for the other

<joesteele> paulc: David we could not hear you before — try again please

<ddorwin> sorry. i'll try calling again

<joesteele> ddorwin: <no audio>

<ddorwin> our position is in the email I sent last night. I'll follow up on Mark's reply.

<BobLund> dial in /irc

<paulc> Is Davide on the phone call?

<davide> i am using webex voip

<joesteele> ddorwin: I responded in the email thread last night

<davide> but i have nothing to say on this matter :)

<joesteele> … if folks are sure this is not a web architecture issue we can move one

<joesteele> jdsmith: can you summarize your concenrs about lifetime of objects?

<paulc> See https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0025.html for David's position on web architecture issue

<joesteele> ddorwin: unless you have persistent storage, when you close the application you can’t specifiy anything afterwards. there is no way of specifying something to happen after the apps is closed.

<joesteele> … there is no other feature that has this

<joesteele> markw: if you define what happens at close to not include this then it will not happen

<joesteele> … I understand the req to not allow the web app to control how long it takes, but the browser could actually make this happen

<joesteele> ddorwin: 2 of the browsers uses OS based systems that are very different

<joesteele> … the question is not whether it can be done but whether it should be done

<joesteele> … by definition the feature requires that after the apps is closed something ahppens

<joesteele> markw: this is an implementation detail, not a web architecture issue

<joesteele> ddorwin: I am suggesting we get input because neither of us are epxerts here

<joesteele> BobLund: as far as I know there are no specs in W3C for user agent behavior other than algorithem behaviors for an API

<joesteele> … this seems like an implementation detail

<joesteele> ddorwin: this feature can only be implemented with this behavior

<joesteele> … the implication is that the browser has to do this

<joesteele> markw: there are things in the web platform that happen when the app is closed, ie. the onClose event

<joesteele> … this does not seem out of sync with those, no lack of precedence here

<joesteele> ddorwin: TAG has proposed some things as anti-features and they are being phased out

<joesteele> paulc: we have two questions

<joesteele> … 1) should we accept pull request 54 — seems to be substantial support

<joesteele> … 2) even if we accept the request, should we get addiitonal feedback from TAG

<joesteele> … seeems to me that the task force should decide here

<joesteele> … is there anyone that cannot live with accepting this?

<joesteele> ddorwin: until I answer the architectural question,

<joesteele> paulc: these are things we can do after the pull request

<joesteele> … so you are saying you object to the pull request?

<joesteele> ddorwin: yes we have been working 4-5 months and are still working

<joesteele> paulc: we have substantial support for accepting this

<joesteele> … we don’t want to wait on getting the TAGs opinion

<joesteele> … I propose we accept the pull request

<joesteele> … and keep the other discussion orthogonal

<joesteele> … there are avenues for you to object if you feel it necessary

<joesteele> … would Mark or Jerry implement the pull request?

<joesteele> jdsmith: I will handle the request since Mark offered

<joesteele> ddorwin: I am already having discussions with the TAG so I can handle the other discussion

<joesteele> paulc: let’s make that discussion transparent

<joesteele> ddorwin: yes. I was just confirming this was an appropriate TAG discussion

<ddorwin> For the record, I object to inclusion before resolving the architectural issues.

<joesteele> paulc: if you have other questions on this, please open new issues

Issue 41, 52, 53 cluster

<joesteele> paulc: we can try to get the positions out before we have to leave

<markw> \me oh, I guess I meant I would still be on the phone

<paulc> ISSUE-41 Update algorithms to reflect keys being provided in the Initialization Data https://github.com/w3c/encrypted-media/issues/41

<joesteele> ddorwin: Joe and Mark countered with examples of where issue 52 is blocked and non supported by the algoithsm

<joesteele> paulc: do we have enough to resolve issue 41?

<joesteele> ddorwin: made a proposal but not enough feedback yet

<ddorwin> The proposal for resolving issue 52, is at the end of https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0023.html

<joesteele> joesteele: I have not had a chance to review

<joesteele> … and won’t have time on this call

<joesteele> joesteele: 52 blocks 41 and 41 blocks 53

<joesteele> paulc: so David your proposal is how to handle issue 52?

<paulc> ISSUE-52 Remove reference to keys in Initialization Data definition https://github.com/w3c/encrypted-media/issues/52

<joesteele> ddorwin: yes

<ddorwin> Issue 52 is basically independent and relates to a bug in the existing text. The other Issues are new features.

<joesteele> paulc: any other comments on Davids proposal

<joesteele> … Joe we need you to respond on this item

<joesteele> ddorwin: 41 would need algorithm design if we resolve 52

<joesteele> joesteele: agreed

<paulc> Issue-41 and ISSUE-53 need further elaboration after we resolved ISSUE-52

<paulc> Most of what is needed is there for ISSUE-41 but ISSUE-53 certainly needs more description if we decide to do that feature.

<joesteele> joesteele: I believe I have provided much of the detail for 41, but needs more work.

<joesteele> paulc: if you and David can get concensus on 52, would be good to specify how 41 should move forward

<joesteele> joesteele: makes sense

<joesteele> paulc: 53 will remain on hold then until the others are done

ISSUE-63 and Pull Request-66

<joesteele> paulc: action on David

<joesteele> ddorwin: have not had a chance to finish this - try to do in the next two weeks

<paulc> https://github.com/w3c/encrypted-media/pull/66 will be reviewed by David

ISSUE-77 - Correct object name at the beginning of section 6.3 MediaKeyStatusMap

<joesteele> paulc: no comments on this yet

<joesteele> jdsmith: just a typo I think

<paulc> https://github.com/w3c/encrypted-media/issues/77

<joesteele> paulc: if you are confident it is editorial, please assign to yourself and make the change

ISSUE-17 - Replace "fire a simple event" with "fire an event" for non-simple Events

<paulc> https://github.com/w3c/encrypted-media/issues/71

<joesteele> paulc: Jerry this was where you went to the WG to get advice

<joesteele> … and you now have a proposal in hand?

<joesteele> jdsmith: I got some additional advice after I made the proposal

<joesteele> … David is right, these are not simple events

<joesteele> … we have a named event, the change I made was to fire the named event

<joesteele> … but I have an additional comment i need to digest

<paulc> https://github.com/w3c/encrypted-media/issues/17

<joesteele> … my proposal was essentialy David’s proposed language but with the named event from our spec.

<joesteele> paulc: is the feedback in the response?

<paulc> Proposal in https://github.com/w3c/encrypted-media/issues/17#issuecomment-128855753 and feedback in https://github.com/w3c/encrypted-media/issues/17#issuecomment-129374107

<joesteele> paulc: joe please look at issue 71

<joesteele> … folks review the rest of the agenda

Next meeting

<paulc> We will try for an EME meeting on Tue Sep 1.

<joesteele> : rrsagent, generate minutes

- DRAFT -

HTML Media Task Force Teleconference

18 Aug 2015

Attendees

Contents