14:49:07 RRSAgent has joined #html-media
14:49:07 logging to http://www.w3.org/2015/03/17-html-media-irc
14:49:09 RRSAgent, make logs public
14:49:09 Zakim has joined #html-media
14:49:11 Zakim, this will be 63342
14:49:11 ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 11 minutes
14:49:12 Meeting: HTML Media Task Force Teleconference
14:49:12 Date: 17 March 2015
14:54:12 MattWolenetz has joined #html-media
14:55:55 HTML_WG()11:00AM has now started
14:56:02 +??P8
14:57:15 markw has joined #html-media
14:57:42 zakim, [??P8] is MattWolenetz
14:57:42 sorry, paulc, I do not recognize a party named '[??P8]'
14:57:58 zakim, ??P8 is MattWolenetz
14:57:58 +MattWolenetz; got it
14:58:22 zakim, what is the code?
14:58:23 the conference code is 63342 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), paulc
14:58:41 +[Microsoft]
14:58:50 zakim, [Microsoft] is me
14:58:50 +paulc; got it
14:58:52 +markw
14:59:12 ddorwin has joined #html-media
14:59:36 rrsagent, generate the minutes
14:59:36 I have made the request to generate http://www.w3.org/2015/03/17-html-media-minutes.html paulc
14:59:42 zakim, who is on the phone?
14:59:42 On the phone I see MattWolenetz, paulc, markw
15:02:04 + +1.650.458.aaaa
15:02:05 zakim, who is on the phone?
15:02:05 On the phone I see MattWolenetz, paulc, markw, +1.650.458.aaaa
15:02:12 pal has joined #html-media
15:02:30 zakim, aaaa is pal
15:02:30 +pal; got it
15:02:59 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Mar/0042.html
15:03:39 +jdsmith
15:03:40 ... waiting for others to join
15:03:41 jdsmith has joined #html-media
15:03:44 +ddorwin
15:03:55 zakim, who is on the phone?
15:03:55 On the phone I see MattWolenetz, paulc, markw, pal, jdsmith, ddorwin
15:04:27 BobLund has joined #html-media
15:05:08 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Mar/0042.html
15:05:15 scribenick: paulc
15:05:16 joesteele has joined #html-media
15:05:26 + +1.408.536.aabb
15:05:35 Zakim, aabb is me
15:05:35 +joesteele; got it
15:05:49 scribenick: joesteele
15:06:02 chair: paulc
15:06:06 scribe: joesteele
15:06:49 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Mar/0042.html
15:07:29 joesteele_ has joined #html-media
15:07:29 Topic: Issue #39 - MediaKeyStatusMap: Replace maplike with explicit methods
15:07:42 scribe: joesteele_
15:07:43 https://github.com/w3c/encrypted-media/issues/39
15:08:07 + +1.303.661.aacc
15:08:08 ddorwin: 2 bugs reported by jwwang about how our Map is defined wrong
15:08:18 ... issue does not seem to be going anywhere
15:08:22 zakim aacc is me
15:08:29 ... this is a proposal to replace map-like with explicit methods
15:08:42 paulc; do we have a concrete proposal
15:09:03 ddorwin: yes -- replacing the methods it would hav added with the actual methods - some remaining to resolve
15:09:17 Zakim, aacc is me
15:09:17 +BobLund; got it
15:09:19 q+
15:09:36 ack markw
15:10:36 Ok, sounds good
15:10:44 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?
15:10:52 joesteele__ has joined #html-media
15:11:00 scribe: joesteele__
15:11:10 paulc: so those are the comments you added in the bug
15:11:31 ddorwin: my default action would be to add the size and the iterator
15:11:37 ... would wait on others
15:11:40 Doing "@@iterator if the object does not have bindings to an ES Map" needs info from someone else.
15:11:55 paulc: anyone want to help david with this?
15:12:01 correction: I heard "default action is methods and size, don't know about the iterator"
15:12:25 paulc: anyone thinks we should not add?
15:12:34 markw: don't know and I will take the action to look into it
15:12:53 Action: markw to look into @@iterators for Issue 39
15:12:53 Created ACTION-78 - Look into @@iterators for issue 39 [on Mark Watson - due 2015-03-24].
15:13:21 Topic: Issue #41 - generateRequest may result in keys being usable when no key request needs to be sent
15:13:46 https://github.com/w3c/encrypted-media/issues/41
15:13:49 topic: Issue 41 generateRequest may result in keys being usable when no key request needs to be sent
15:13:50 https://github.com/w3c/encrypted-media/issues/41
15:14:38 See Joe's comment: https://github.com/w3c/encrypted-media/issues/41#issuecomment-82107347
15:14:54 ddorwin: think more about this
15:15:02 ... need to understand how this would be supported
15:15:05 Possible F2F topic
15:15:13 joesteele__: lets talk in the face to face
15:15:37 topic: Issue 40 - replace "Distinctive Identifier" with "persistent Distinctive Identifier" where "use distinctive identifier" is false
15:15:42 https://github.com/w3c/encrypted-media/issues/40
15:16:02 ddorwin: think this is down to just three words to add
15:16:10 joesteele__: +1 to this
15:16:33 Joe agrees with text in https://github.com/w3c/encrypted-media/issues/40#issuecomment-79151710
15:16:47 Awaiting Henri's response since he offered original text.
15:17:20 topic: Bug 26776
15:17:29 Action-73?
15:17:29 Action-73 -- Jerry Smith to Make proposal for resolving bug 26776 -- due 2015-03-09 -- OPEN
15:17:29 http://www.w3.org/html/wg/media/track/actions/73
15:17:41 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776
15:18:24 jdsmith: I commented on this -- question about what object the event would be fired on
15:18:33 ... thinking MediaKeySession
15:18:34 Jerry's comment is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c26
15:18:49 ... asked to provide example of errors outside the errors listed in the Promise errors
15:19:08 ... listed some pipeline conditions
15:19:24 ... some could be merged into keyststatuevent but would need a systemcode
15:19:51 ... previously had proposed having a separate information event -- thought we had some concensus that this was desirable
15:19:58 action-73 is closed
15:20:01 paulc: so Action 73 is done?
15:20:04 jdsmith: yes
15:20:09 close action-73
15:20:09 Closed action-73.
15:20:44 ddorwin: answrs questions but not sure we are closer to solving
15:20:57 ... we have three different ways errors are reported should stikc with that
15:21:06 ... but then where does the systemcode go?
15:21:15 ... did not want this to be an event
15:21:22 paulc: how do we make progress?
15:21:51 jdsmith: thought you had some support at one point for doing the informational event at one point?
15:22:00 q+
15:22:24 jdsmith: ok with merging this in with some other event -- but want to retain the system code
15:22:31 ack joe
15:22:52 My previous position: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c20
15:24:12 joesteele__: I also agree with this but I would like to retain the systecode -- don't want to add a parser for our apps
15:24:36 jdsmith: my intent is to not have applications switch on this either but use as informational
15:24:42 q+
15:25:05 paulc: why don't we have that text in the spec? ISO9075 subcode as an example (SQLSTATE)
15:25:23 ... there are words that say the app can pass this on but should not have logic that depends on it
15:25:32 ... sounds like concensus may be around that
15:26:01 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
15:26:08 ... then apps could check the list
15:26:16 joesteele__: and presumably dump for debugggin
15:26:53 markw: I think that a numeric code is the easiest way to deal with this, changes less across applications
15:27:06 ... but we could handle this in a string
15:27:24 ... DOMException could work as well but should be available for all failure modes
15:27:44 ... failures where keys are still usable are not much of a failure
15:27:52 ... this would be a different type of event
15:28:33 s/answrs/answers/
15:28:57 ack markw
15:29:43 jdsmith: mark also said we could again have text that said the systemcode can change over time and should not be relied on
15:29:58 ... for me it seems like an event is the natural way to return this information
15:30:48 paulc: seem to be at an impasse here -- some folks want a systemcode, some are concerned about breaking interop
15:31:05 ... David is concerned that even if we say don't do it -- people will
15:31:30 ... sounds like we should make it difficult for application programs to do the wrong thing.
15:31:38 ... using a text list?
15:32:00 ... think we need a concrete proposal -- like to have on the table by the face-to-face so we can make progress
15:32:11 ddorwin: I updated the bug with this discussion
15:32:27 ... if we do make this a getter - we could provide playback information as well
15:32:42 ... also app could check before closing the session
15:32:49 q?
15:32:53 David's update: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c27
15:33:14 jdsmith: we have made a number of proposals -- if we have some verbal agreement on the approach -- we can move forward
15:33:34 ... david is saying we might be able to expand
15:33:47 ddorwin: if there was a playback error -- an app could check the statuses
15:34:02 paulc: jdsmith you want to write up what you think the agreement is then?
15:34:06 jdsmith: ok
15:34:16 ACTION: jdsmith to draft a proposal for returning errors as per bug 26776
15:34:16 Created ACTION-79 - Draft a proposal for returning errors as per bug 26776 [on Jerry Smith - due 2015-03-24].
15:34:43 topic: Issue 33
15:34:45 https://github.com/w3c/encrypted-media/issues/33
15:34:56 ACTION-74?
15:34:56 ACTION-74 -- Jerry Smith to Comment on issue 33 -- due 2015-03-10 -- OPEN
15:34:56 http://www.w3.org/html/wg/media/track/actions/74
15:35:05 jdsmith: was trying to summarize the purpose
15:35:23 See https://github.com/w3c/encrypted-media/issues/33#issuecomment-82027778
15:35:25 ... believe it is to check for active session (not previously closed) and then support secure release
15:35:46 ... we expect apps to keep track of active sessions and then for secure release to attempt to load that session
15:36:04 ... could not think of a scenario we are blocking an app from tracking
15:36:19 markw has joined #html-media
15:36:21 ... but might need a way for apps to enumerate the sessions -- not convinced it is necessary
15:36:28 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).
15:36:30 paulc: original text
15:36:48 paulc: does anyone else have an opinion?
15:37:03 close Action-74
15:37:04 Closed Action-74.
15:37:41 jdsmith: depends on our philosophy -- we have been biased towards providing facilities to unblock
15:38:07 ddorwin: yes we have been trending towards providing minimal facilities -- if we get it wrong it will be there forever
15:38:57 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
15:39:07 ddorwin: please comment in the bug on this
15:39:20 jdsmith: I will
15:39:25 Jerry and Joe will respond to the issue with their view that they don't want to add this feature.
15:39:26 joesteele__: I will as well
15:39:41 topic: Issue 31
15:39:43 https://github.com/w3c/encrypted-media/issues/31
15:40:03 paulc: long outstanding item for Joe to talk to Chris Pearce
15:40:04 action-75?
15:40:04 action-75 -- Joe Steele to Steele to ask chris pearce to review issue 31 -- due 2015-03-10 -- OPEN
15:40:04 http://www.w3.org/html/wg/media/track/actions/75
15:40:42 ddorwin: there was a comment from a week ago
15:40:42 Chris's reply: https://github.com/w3c/encrypted-media/issues/31#issuecomment-78014726
15:40:56 close ACTION-75
15:40:57 Closed ACTION-75.
15:41:06 paulc: so this closes action-75
15:41:17 ddorwin: I think this one is good to go -- but blocked on 19
15:41:43 ... that is the promises ordering issue
15:41:58 Issue 19: https://github.com/w3c/encrypted-media/issues/19
15:41:59 https://github.com/w3c/encrypted-media/issues/19
15:42:12 paulc: need to work on this at the F2F?
15:42:22 ddorwin: seems like just spec changes at this point
15:42:35 ... don't think anything is surprising anymore
15:43:01 topic: Issue 16 & Issue 18
15:43:05 https://github.com/w3c/encrypted-media/issues/16
15:43:06 https://github.com/w3c/encrypted-media/issues/18
15:43:10 ACTION-76?
15:43:10 ACTION-76 -- Jerry Smith to Review and comment on issues 16 and 18 -- due 2015-03-10 -- OPEN
15:43:10 http://www.w3.org/html/wg/media/track/actions/76
15:43:20 jdsmith: made very short comments
15:43:44 paulc: lets do issue 16 first - mark has already responded
15:43:44 Reply on #16: https://github.com/w3c/encrypted-media/issues/16#issuecomment-82032305
15:44:37 ddorwin: original intent was to figure out what happens to the keys
15:44:46 ... need to walk through the various use cases
15:45:12 ... this is one where there is not a clear proposal -- just needs thinking
15:45:19 q+
15:45:21 paulc: F2F topic?
15:45:28 ddorwin: yes -- but needs whiteboarding
15:45:44 Possible F2F discussion for #16 and #18
15:45:53 jdsmith: think I agree with Marks comments -- temporary keys would disappear when the browser window closes
15:46:07 Mark's comment: https://github.com/w3c/encrypted-media/issues/16#issuecomment-82070667
15:46:39 markw: 2 questions -- when session is closed can cause keys to be released? and we need to document how that happens in that case.
15:47:06 ... 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?
15:47:19 ddorwin: absolutely not -- that is impossible
15:47:29 markw: not for all applications
15:47:39 ddorwin: the application is dead at that point
15:47:47 markw: think it is am implementation issue
15:48:15 ... the system is very much dependent on getting these messages -- the application should be allowed to solve this
15:48:39 ddorwin: I am not sure it is not disallowed by the web arhictecture -- but I think would lead to fragmentation
15:49:16 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
15:49:42 ... don't know what the frequency of these messages will be in the field
15:50:00 ... if we find more cases when we could report them, the specification should allow us to try
15:50:25 paulc: we could say it is "implementation defined" whether the messages are sent when the application disappears
15:50:38 ... if they turn out to be useful as Mark is thinking
15:50:51 markw: think this should be a MAY requirement
15:51:18 paulc: Jerry do you want to say anything about issue 18? it was paired with this
15:51:31 Comment on #18: https://github.com/w3c/encrypted-media/issues/18#issuecomment-82033772
15:51:34 jdsmith: I am greeing with joes comment that key ststatus should be empty in this case
15:51:43 s/not for all applications/not for all implementations/
15:51:53 paulc: so we should have some whiteboard discussion on this at the F2F
15:52:05 close action-76
15:52:05 Closed action-76.
15:52:06 ... let's look at the last item
15:52:15 topic: Issue 9
15:52:17 https://github.com/w3c/encrypted-media/issues/9
15:52:25 ACTION-77?
15:52:25 ACTION-77 -- Mark Watson to Review pushback from apple on issue 9 -- due 2015-03-10 -- OPEN
15:52:25 http://www.w3.org/html/wg/media/track/actions/77
15:52:46 markw: I did exchange some emails from jernoble
15:53:24 ... don't want to speak for them, but can assume the current behavior will continue for awhile
15:53:25 close ACTION-77
15:53:25 Closed ACTION-77.
15:53:33 ... no agreement on the pre-fetching of licenses
15:54:03 ... don't think folks are thinking this is a good thing
15:54:13 ... one option is to leave the note as it it and remove in the future
15:54:29 ... another is to allow for key session that operate without attachment
15:54:52 ... think the option of just removing the note will not be acceptable
15:55:10