{minutes} HTML WG media telecon 2013-08-27 - EME status and bugs discussion

http://www.w3.org/2013/08/27-html-media-minutes.html

Joe Steele
steele@adobe.com
 

HTML Media Task Force Teleconference

27 Aug 2013

Agenda

See also: IRC log

Attendees

Present
glenn, niels_thorwirth, paulc, joesteele, davide, markw, pladd, pal, BobLund, adrianba, ddorwin, [Microsoft]
Regrets
Chair
paulc
Scribe
joesteele
Contents

Topics
Agenda
Heartbeat Docs
Bug#18515
Bug#20966
Bug#20944
Summary of Action Items
<trackbot> Date: 27 August 2013
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 27 August 2013
<scribe> scribenick: joesteele
Agenda

paulc: Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Aug/0038.html
paulc: not sure where to start on the bugs
Heartbeat Docs

<paulc> http://lists.w3.org/Archives/Public/www-archive/2013Aug/0023.html
paulc: last week looked like Adrian agreed to produce the stable doc - checked with Robin and had not seen a response from EME editors
adrianba: said last week we would do in two weeks, can't publish this week
paulc: saw reference to that - was that the consensus?
... were there bugs we should look at and review?
adrianba: conclusion was that we did not need to wait for specific bugs, but felt that with planned work we would have more up to date spec next week
paulc: trying to have two weeks or ready this week?
adrianba: not sure
paulc: moratorium this week, some docs will be published next week, e.g. MSE Last Call
... not obvious that we need to do a CFC at the working group
... need a stable draft to do that
... out of this meeting
... can the participants today look at agenda today and decide which items we want to close today
<markw> I'm just completing ACTION-37 now
joesteele: not ready on bug#17673 yet (action-25) -- apologies
paulc: are you suggesting action-31 is moot now?
ddorwin: tried to resolve a couple of weeks ago, realized we had not made a decision yet
... last comment refers to that
paulc: any other bugs we should focus on for candidate heartbeat?
adrianba: did close ACTION-30 this morning
... closing bug#20966
... reason I had not done this till now was I wanted to add the privacy considerations language
Bug#18515

<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c13
paulc: believe this is the comment to look at
adrianba: ACTION-36 on Gary and I to review the comments David had made and decide what we thought
... at the point where playback locks because of a piece of encrypted media and no key is available
... consensus is that playback should stall
... should media state of the element actually change to reflect the stall
... or should stall just be implicit?
... our position is to not change the ready state
... reason is that is you are using MSE and EME together
... using playback code for adaptive streaming
... changing the ready state might change the playback code and trigger downloading more data
... probably not the right thing to do
joesteele: ok
ddorwin: still need to figure out the wording - any suggestions?
markw: proposal is that the media element could still be playing, and the fact that we are waiting for a key is represented on the key session?
... isn't that strange that the media element cannot play although it indicates it can?
<paulc> (swapping phones to avoid the air flow noise in my office)
adrianba: if you have a counterproposal that can handle the adaptive case, we should consider that
markw: need to check but let's go ahead
adrianba: comment that we still have action-31 to define some text
... does David still want to own that action?
paulc: so action-31 not covered by your proposal?
adrianba: action-31 was the proposal text, our action-36 was to review the question which we have done
... sounds like we have consensus on how to resolve, just need the text now
paulc: david, was that your point?
ddorwin: yes, we have mostly consensus on what to change
... just not how to reflect it
... should not change the media session to reflect it
... maybe in the media element or not at all
<Zakim> ddorwin, you wanted to say that I'm fine not changing readyState, but any state should be reflected in HTMLMediaElement
ddorwin: just have a pseudo-state like it is currently
adrianba: I think it was clear that you would have a session in a pending state to get into this situation
... but it is possible that you have a needKey but have not created the session yet
... don't think I have a problem with adding something to the media element that indicates that
ddorwin: what would that be? event, attribute
adrianba: maybe an attribute, parallel to media element, like an enum
... think we get events already that lead to this
... may not need ot know the point at which it stalled
... what would the app do with the event?
ddorwin: not sure we need to reflect it
... we could add text about what the UA should do
... not about what we provide to the app
... not sure what the app would do
adrianba: could add it but not sure if it would be useful
... maybe start with just being clear in the spec that you are supposed to stall waiting for the key
... if we find some gaps implementing then we can look at adding it
ddorwin: that sounds good to me
... copy "future data or not future data from the spec" or I can seach around
joesteele: not worth adding until we have implementation experience or specific need
<ddorwin> somewhere on this page: http://www.w3.org/TR/html5/embedded-content-0.html
paulc: can we point to that text directly?
... section 4.8?
joesteele: what about 4.8.10.7 "Ready states"?
<ddorwin> Maybe we should fire |waiting|: http://www.w3.org/TR/html5/embedded-content-0.html#event-media-waiting
for text I mean
<adrianba> There is a definition of a blocked media element: http://www.w3.org/TR/html5/embedded-content-0.html#blocked-media-element
ddorwin: we are asking for existing text that could reflect when we are waiting for a key
... nothing exact right now
... about what "should happen" in that state
... probably have to make it up
paulc: should we resolve now or assign to the editors?
... or could leave ACTION-31 open until David can propose some text?
ddorwin: don't need to block the heartbeat on this one
... has some existing text
paulc: reopened ACTION-31 at original state
... David you still have this action
<adrianba> close ACTION-36
<trackbot> Closed ACTION-36.
<paulc> ACTION-31?
<trackbot> ACTION-31 -- David Dorwin to Propose text to resolve bug 18515 -- due 2013-09-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/31
RESOLUTION: David will attend to ACTION-31 with text proposed by ACTION-36
Bug#20966

paulc: you closed ACTION-30?
ACTION-30?
<trackbot> ACTION-30 -- Adrian Bateman to Implement closing 20966 -- due 2013-08-27 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/30
paulc: referred to comment #9 that it was resolved pointing to August 6th minutes
<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=20966#c9
adrianba: this bug has been around for awhile and reopened without specific information
... just realized that I need to remove the note in the document about the state of this bug
... bug#20965 is the main placeholder for privacy issues
glenn: 22909 is the generic bug I would recommend to handle this
paulc: if this bug depends on bug#22909 how do we resolve?
adrianba: looks like we have duplicate bugs
... 20966 is a dup of 20965 unless there is more information
... I resolved that adding the privacy condierations section later today
... should resolve the other also
<paulc> Security considerations? https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909#c1
paulc: if you add this security considerations section - that is from this comment
... ?
adrianba: we have ended up with lots of bugs that say the same thing
... original plan was to add this section with a placeholder
... added the text from 22910 verbatim from Glenns proposal without review
... needs review
... bit more discussion on the security considerations
... on whether the right suggestions are being made
<paulc> Privacy considerations are proposed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910#c1
adrianba: still recommend keeping the master bug open
... from prior to FPWD
paulc: so 20966 is resolved as NEEDSINFO
... what do we do with the dependency on bug#22909?
adrianba: remove it
ddorwin: think it is useful as a reference
glenn: 20966 has been closed and ir marked. as dependant -- dependency can continue to exist
paulc: adrian you were proposing to add a security section as per bug#22909 and privacy section from bug#22910
... does that resolve?
adrianba: I believe so
<paulc> Security section from https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909#c2
<paulc> Privacy section from https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910#c1
<paulc> That can resolve 22909 and 22910 leaving open 20965
paulc: this can resolve these bugs, leaving open 20965
adrianba: yes
paulc: so bug#20965 will remain open as the master bug
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965
RESOLUTION bug#22909, bug#22910, bug#20966 will be closed and bug#20965 will remain open
paulc: other candidate bug#17673 was mentioned but joe said is not done
... any other items we can look at?
... ACTION-35 was on me -- still need to do it
... putting in heartbeat means this is slightly changed
ACTION-37?
<trackbot> ACTION-37 -- Mark Watson to Update wiki provided for bug 20944 to cover the case where the drm is supporting by the os -- due 2013-08-20 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/37
markw: did that this morning
Bug#20944

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
s/ tps:\/\//https:\/\//
<paulc> What is the status with this bug given ACTION-37 is closed.
<paulc> ACTION-37?
<trackbot> ACTION-37 -- Mark Watson to Update wiki provided for bug 20944 to cover the case where the drm is supporting by the os -- due 2013-08-20 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/37
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c30
glenn: I can implement the change to the registry text as suggested
paulc: on Feb 13th we added a note to the abstract that this was an open issue
... if we close would need to make that cascading change
<paulc> Glenn's proposal in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c15
paulc: comment #15 is where you proposed a resolution
... simple registry and informative note, clearkey as the first entry
... Robert Callahan said "this is not as strong as I proposed"
glenn: not clear what Robert is proposing - he has not written it down clearly
... I referred to this in comment#22 with the draft registry text
... comments since then by a number of people
paulc: maybe best best is to implement the changes to the wiki and the doc to refer to wiki
... and then ask for feedback in the status section and leave the bug open
markw: open issues
... I think what Robert proposed is fairly clear
<paulc> Mark's comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c23
markw: one -- we require that a key system that uses private system APIs be not allowed to be registered
<paulc> Mark's suggestion is still outstanding.
markw: second -- Roberts question is to ask why can't we do his proposal
... think we should explain why this would not work (CDM implementors)
ddorwin: as far as adding to the spec, not sure whether folks would use it or that this would solve anything
... we do have an improve interop issue already
paulc: would like to resolve the issues that Mark pointed to
... any volunteers?
glenn: two implementors on this call (Microsoft and Adobe), maybe Cisco as well
joesteele: Google is also a CDM implementor
glenn: most specs require very strict NDAs to get the keys and/or implementations
pal: I am not sure how the W3C or any standards org can compel an implementor to publish their source code
<markw> @pal: the proposal is a specification, not source code
pal: could be thirdparty source as well
... don't see how this can be resolved except by making this requirement
<markw> @pal: and we can't compel anyone, but Robert question is to ask why we can't make it a requirement of compliance to the specification
paulc: will put this bug#20944 on the agenda for next time
pal: what information would you like to see to help the group close the bug?
paulc: Marks comment #23 should be either refuted or supported
... and also respond to Roberts question about why we can't do what he is suggesting
markw: my first suggestion seems to be non-controversial about public APIs, second suggestion about private APIs is more interesting, should we require that to be documented
paulc: suggesting that we continue the dialog along these lines
pal: Marks first suggestion is captured in comment #30
... other part of the comment on private APIs - where is that captured?
markw: comment #23
pal: open comments on those two suggestions, but not sure that would satisfy the questioner
... the commenter had asked for specific opinions from implementors, will bug remain open until then?
paulc: won't predict
... adrian do you have clear instructions on what to do?
... assume he does
... past time but we will continue to propose we meet until we have closed more bugs
<markw> @pal: it may not be obvious to people why the drm specifications are covered by NDAs etc. when a more common approach to security is to publish algorithms (NIST etc.). If noone can explain why that approach shouldn't apply to DRM too, why not publish is ?
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-08-27 16:11:26 $