HTML Media Task Force Teleconference -- 17 Mar 2015

<trackbot> Date: 17 March 2015

<paulc> ... waiting for others to join

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Mar/0042.html

<paulc> scribenick: paulc

<scribe> scribenick: joesteele

<scribe> scribe: joesteele

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Mar/0042.html

Issue #39 - MediaKeyStatusMap: Replace maplike with explicit methods

<joesteele_> scribe: joesteele_

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

ddorwin: 2 bugs reported by jwwang about how our Map is defined wrong
... issue does not seem to be going anywhere

<BobLund> zakim aacc is me

ddorwin: this is a proposal to replace map-like with explicit methods

paulc; do we have a concrete proposal

ddorwin: yes -- replacing the methods it would have added with the actual methods - some remaining to resolve

<markw> Ok, sounds good

<paulc> Outstanding questions are: Shall we include all methods and the size getter? Do we need @@iterator if the object does not have bindings to an ES Map?

<joesteele__> scribe: joesteele__

paulc: so those are the comments you added in the bug

ddorwin: my default action would be to add the size and the iterator
... would wait on others

<paulc> Doing "@@iterator if the object does not have bindings to an ES Map" needs info from someone else.

paulc: anyone want to help david with this?

<MattWolenetz> correction: I heard "default action is methods and size, don't know about the iterator"

paulc: anyone thinks we should not add?

markw: don't know and I will take the action to look into it

<paulc> ACTION: markw to look into @@iterators for Issue 39 [recorded in http://www.w3.org/2015/03/17-html-media-minutes.html#action01]

<trackbot> Created ACTION-78 - Look into @@iterators for issue 39 [on Mark Watson - due 2015-03-24].

Issue #41 - generateRequest may result in keys being usable when no key request needs to be sent

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

Issue 41 generateRequest may result in keys being usable when no key request needs to be sent

https://github.com/w3c/encrypted-media/issues/41

<paulc> See Joe's comment: https://github.com/w3c/encrypted-media/issues/41#issuecomment-82107347

ddorwin: think more about this
... need to understand how this would be supported

<paulc> Possible F2F topic

joesteele__: lets talk in the face to face

Issue 40 - replace "Distinctive Identifier" with "persistent Distinctive Identifier" where "use distinctive identifier" is false

https://github.com/w3c/encrypted-media/issues/40

ddorwin: think this is down to just three words to add

joesteele__: +1 to this

<paulc> Joe agrees with text in https://github.com/w3c/encrypted-media/issues/40#issuecomment-79151710

<paulc> Awaiting Henri's response since he offered original text.

Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode

<paulc> Action-73?

<trackbot> Action-73 -- Jerry Smith to Make proposal for resolving bug 26776 -- due 2015-03-09 -- OPEN

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

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

jdsmith: I commented on this -- question about what object the event would be fired on
... thinking MediaKeySession

<paulc> Jerry's comment is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c26

jdsmith: asked to provide example of errors outside the errors listed in the Promise errors
... listed some pipeline conditions
... some could be merged into keystatuseschange but would need a systemcode
... previously had proposed having a separate information event -- thought we had some concensus that this was desirable

<paulc> action-73 is closed

paulc: so Action 73 is done?

jdsmith: yes

<paulc> close action-73

<trackbot> Closed action-73.

ddorwin: answers questions but not sure we are closer to solving
... we have three different ways errors are reported should stick with that
... but then where does the systemcode go?
... did not want this to be an event

paulc: how do we make progress?

jdsmith: thought you had some support at one point for doing the informational event at one point?
... ok with merging this in with some other event -- but want to retain the system code

<ddorwin> My previous position: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c20

joesteele__: I also agree with this but I would like to retain the systemcode -- don't want to add a parser for our apps

jdsmith: my intent is to not have applications switch on this either but use as informational

paulc: why don't we have that text in the spec? take ISO9075 subcode as an example (SQLSTATE)
... there are words that say the app can pass this on but should not have logic that depends on it
... sounds like concensus may be around that

ddorwin: another option would be to provide an accessor to show all the error codes seen by that session -- this allows to show a list
... then apps could check the list

joesteele__: and presumably dump for debugging

markw: I think that a numeric code is the easiest way to deal with this, changes less across applications
... but we could handle this in a string
... DOMException could work as well but should be available for all failure modes
... failures where keys are still usable are not much of a failure
... this would be a different type of event

jdsmith: mark also said we could again have text that said the systemcode can change over time and should not be relied on
... for me it seems like an event is the natural way to return this information

paulc: seem to be at an impasse here -- some folks want a systemcode, some are concerned about breaking interop
... David is concerned that even if we say don't do it -- people will
... sounds like we should make it difficult for application programs to do the wrong thing.
... using a text list?
... think we need a concrete proposal -- like to have on the table by the face-to-face so we can make progress

ddorwin: I updated the bug with this discussion
... if we do make this a getter - we could provide playback information as well
... also app could check before closing the session

<paulc> David's update: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c27

jdsmith: we have made a number of proposals -- if we have some verbal agreement on the approach -- we can move forward
... david is saying we might be able to expand

ddorwin: if there was a playback error -- an app could check the statuses

paulc: jdsmith you want to write up what you think the agreement is then?

jdsmith: ok

<paulc> ACTION: jdsmith to draft a proposal for returning errors as per bug 26776 [recorded in http://www.w3.org/2015/03/17-html-media-minutes.html#action02]

<trackbot> Created ACTION-79 - Draft a proposal for returning errors as per bug 26776 [on Jerry Smith - due 2015-03-24].

Issue 33 - Expose unclosed and unremoved MediaKeySessions on MediaKeys

https://github.com/w3c/encrypted-media/issues/33

<paulc> ACTION-74?

<trackbot> ACTION-74 -- Jerry Smith to Comment on issue 33 -- due 2015-03-10 -- OPEN

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

jdsmith: was trying to summarize the purpose

<paulc> See https://github.com/w3c/encrypted-media/issues/33#issuecomment-82027778

jdsmith: believe it is to check for active session (not previously closed) and then support secure release
... we expect apps to keep track of active sessions and then for secure release to attempt to load that session
... could not think of a scenario we are blocking an app from tracking
... but might need a way for apps to enumerate the sessions -- not convinced it is necessary

<paulc> Original request: It seems to me that having access to the non-removed, non-closed set of MediaKeySessions would be handy for EME application developers, and consistent with other media element extensions (activeSourceBuffers on Media Sources, for instance).

paulc: original text
... does anyone else have an opinion?

<paulc> close Action-74

<trackbot> Closed Action-74.

jdsmith: depends on our philosophy -- we have been biased towards providing facilities to unblock

ddorwin: yes we have been trending towards providing minimal facilities -- if we get it wrong it will be there forever

joesteele__: I would like to leave this out for now, don't like the current behavior and would like to leave the door open to change

ddorwin: please comment in the bug on this

jdsmith: I will

<paulc> Jerry and Joe will respond to the issue with their view that they don't want to add this feature.

joesteele__: I will as well

Issue 31 - generateRequest() should allow the first message to not be a license request based on initData

https://github.com/w3c/encrypted-media/issues/31

paulc: long outstanding item for Joe to talk to Chris Pearce

<paulc> action-75?

<trackbot> action-75 -- Joe Steele to Steele to ask chris pearce to review issue 31 -- due 2015-03-10 -- OPEN

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

ddorwin: there was a comment from a week ago

<paulc> Chris's reply: https://github.com/w3c/encrypted-media/issues/31#issuecomment-78014726

<paulc> close ACTION-75

<trackbot> Closed ACTION-75.

paulc: so this closes action-75

ddorwin: I think this one is good to go -- but blocked on 19
... that is the promises ordering issue

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

https://github.com/w3c/encrypted-media/issues/19

paulc: need to work on this at the F2F?

ddorwin: seems like just spec changes at this point
... don't think anything is surprising anymore

Issue 16 & Issue 18

https://github.com/w3c/encrypted-media/issues/16

https://github.com/w3c/encrypted-media/issues/18

<paulc> ACTION-76?

<trackbot> ACTION-76 -- Jerry Smith to Review and comment on issues 16 and 18 -- due 2015-03-10 -- OPEN

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

jdsmith: made very short comments

paulc: lets do issue 16 first - mark has already responded

<paulc> Reply on #16: https://github.com/w3c/encrypted-media/issues/16#issuecomment-82032305

ddorwin: original intent was to figure out what happens to the keys
... need to walk through the various use cases
... this is one where there is not a clear proposal -- just needs thinking

paulc: F2F topic?

ddorwin: yes -- but needs whiteboarding

<paulc> Possible F2F discussion for #16 and #18

jdsmith: think I agree with Marks comments -- temporary keys would disappear when the browser window closes

<paulc> Mark's comment: https://github.com/w3c/encrypted-media/issues/16#issuecomment-82070667

markw: 2 questions -- when session is closed can cause keys to be released? and we need to document how that happens in that case.
... other question is if the session is closed because of the UA - should the UA be attempting to send the key release message to the server?

ddorwin: absolutely not -- that is impossible

markw: not for all implementations

ddorwin: the application is dead at that point

markw: think it is am implementation issue
... the system is very much dependent on getting these messages -- the application should be allowed to solve this

ddorwin: I am not sure it is not disallowed by the web arhictecture -- but I think would lead to fragmentation

markw: get the issue when the session is closed independant of the application, all apps have to deal with this so would not be interop issue
... don't know what the frequency of these messages will be in the field
... if we find more cases when we could report them, the specification should allow us to try

paulc: we could say it is "implementation defined" whether the messages are sent when the application disappears
... if they turn out to be useful as Mark is thinking

markw: think this should be a MAY requirement

paulc: Jerry do you want to say anything about issue 18? it was paired with this

<paulc> Comment on #18: https://github.com/w3c/encrypted-media/issues/18#issuecomment-82033772

jdsmith: I am greeing with joes comment that key ststatus should be empty in this case

paulc: so we should have some whiteboard discussion on this at the F2F

<paulc> close action-76

<trackbot> Closed action-76.

paulc: let's look at the last item

Issue 9 - Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element

https://github.com/w3c/encrypted-media/issues/9

ACTION-77?

<trackbot> ACTION-77 -- Mark Watson to Review pushback from apple on issue 9 -- due 2015-03-10 -- OPEN

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

markw: I did exchange some emails from jernoble
... don't want to speak for them, but can assume the current behavior will continue for awhile

<paulc> close ACTION-77

<trackbot> Closed ACTION-77.

markw: no agreement on the pre-fetching of licenses
... don't think folks are thinking this is a good thing
... one option is to leave the note as it it and remove in the future
... another is to explicitly allow for key sessions that do not operate without attachment and make this discoverable
... think the option of just removing the note will not be acceptable

ddorwin: interesting to know whether when they implement the latest spec they can do this

<ddorwin> If not, one option would be to prevent createSession() from being called on the MediaKeys (throw an exception) on such implementations. We would include a note that implementations should not do this but some do, and this is the behavior

paulc: someone should add these options to the bug and get Apple to respond

ddorwin: Mark can you summarize your discussion in the bug?

markw: yes

Heartbeat publication

paulc: discussion going on amongst the chairs in how to handle the registries
... some pointers sent to David

ddorwin: neither of those bugs contain the word "patent" in them
... if we go to editors draft and we still have patent policies -- that does not seem right

paulc: not being able to meet with the team has slowed this down a bit

F2F mtg

paulc: we are not necessarily marching through all bugs -- need the list to be divided in two
... some folks have not filled out the survey yet

ddorwin: would like to see folks list bugs they are interested in
... on the survey

paulc: is there a way to tag the issues with which ones oare being handled by the editord already?

ddorwin: the "to be implemented" tag is what I have been using

<ddorwin> https://github.com/w3c/encrypted-media/issues?q=is%3Aopen+-label%3A%22to+be+implemented%22+

ddorwin: can also do this

<ddorwin> ^ bugs that don't have a solution waiting to be implemented

ddorwin: to filter the bugs

paulc: that is a start -- thanks
... so we should prioritize those bugs for discussion?

ddorwin: we have not agreed on the outcome for those yet

paulc: thanks everyone!

- DRAFT -

HTML Media Task Force Teleconference

17 Mar 2015

Attendees

Contents