HTML Media Task Force Teleconference -- 27 Aug 2013

<trackbot> Date: 27 August 2013

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 27 August 2013

<scribe> scribenick: joesteele

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Aug/0038.html

Agenda

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
... cpoy "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

s/makred/marked/

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 ?

s/s\/makred\/marked\///

- DRAFT -

HTML Media Task Force Teleconference

27 Aug 2013

Attendees

Contents

Agenda

Heartbeat Docs

Bug#18515

Bug#20966

Bug#20944

Summary of Action Items

Scribe.perl diagnostic output