See also: IRC log
<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
paulc: not sure where to start on the bugs
<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
<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
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
<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\///
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/considerations spec/considerations language/ Succeeded: s/proboably/probably/ Succeeded: s/attend the/attend to/ Succeeded: s/dependcey/dependency/ Succeeded: s/makred/marked./ FAILED: s/makred/marked/ WARNING: Bad s/// command: s/ tps:\/\//https:\/\// Succeeded: s/private system APIs be documented/private system APIs be not allowed to be registered/ Succeeded: s/bug already/issue already/ Succeeded: s/what about/joesteele\: what about/ Succeeded: s/RESOLVED/RESOLUTION/ Succeeded: s/from tps/from https/ WARNING: Bad s/// command: s/s\/makred\/marked\/// Succeeded: s/implememtations/implementations/ Found ScribeNick: joesteele Inferring Scribes: joesteele Default Present: glenn, niels_thorwirth, paulc, joesteele, davide, markw, pladd, pal, BobLund, adrianba, ddorwin, [Microsoft] Present: glenn niels_thorwirth paulc joesteele davide markw pladd pal BobLund adrianba ddorwin [Microsoft] Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Aug/0038.html Found Date: 27 Aug 2013 Guessing minutes URL: http://www.w3.org/2013/08/27-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]