Re: {minutes} HTML WG media telecon 2013-02-26 - EME bugs discussion

I am a little concerned with the way in which bugs that all for genuine
information, more details and clarifications are brushed off as won't fix,
needs info, or resolve later in an apparent drive tho get to a next CfC as
quickly as possible. (At least that's how the minutes read.)

After the intensive discussions in the WG, I would have liked to see more
actions distributed to task force members, more analysis being done on DRMs
(even if they are out of score for this effort - they still need to be
understood be the WG to make an informed decision), more discussions
started with opponents like Henri and Robert.

Instead of working with the opponents, this seems to be an effort in
bashing the spec through against the opponents.

I am deeply concerned that this will likely result in just another
rejection of the next CfC - it seems impossible that the group could have
dealt with all the open issues in such a short timeframe.

HTH.

Cheers,
Silvia.
On 27 Feb 2013 04:56, "Joe Steele" <steele@adobe.com> wrote:

> http://www.w3.org/2013/02/26-html-media-minutes.html
>
> ------------------------------
>
> - DRAFT -
> HTML Media Task Force Teleconference26 Feb 2013
>
> Agenda<http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0111.html>
>
> See also: IRC log <http://www.w3.org/2013/02/26-html-media-irc>
> Attendees
> Present+1.425.269.aaaa, ddorwin, joesteele, pal, markw, paulc, johnsim,
> adrianba, +1.303.503.aabb, boblundRegretsChairPaul CottonScribejoesteele
> Contents
>
>    - Topics <http://www.w3.org/2013/02/26-html-media-minutes.html#agenda>
>       1. #5 progression to FPWD<http://www.w3.org/2013/02/26-html-media-minutes.html#item01>
>       2. Bugs discussed last time<http://www.w3.org/2013/02/26-html-media-minutes.html#item02>
>    - Summary of Action Items<http://www.w3.org/2013/02/26-html-media-minutes.html#ActionSummary>
>
> ------------------------------
>
> <trackbot> Date: 26 February 2013
> <scribe> scribe: joesteele
> <scribe> chair: paulc
> trackbot-ng, start telcon
> <trackbot> Meeting: HTML Media Task Force Teleconference
> <trackbot> Date: 26 February 2013
> #5 progression to FPWD
> <paulc> agenda:
> http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0111.html
> paulc: Topic is bugs discussed during previous meeting
> Bugs discussed last time
> <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
> Bug #20944
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
> paulc: Is this done?
> ... adrian called this out? any more to do?
> adrian: that was it
> paulc; Bug 20960
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20960
> paulc: EME not limited to video
> ... lots of discussion
> markw: not sure I have made progress
> +q
> markw: topic is roving across several bugs
> ... general theme is that EME is not constrained by the spec
> ... not sure how to address this
> ... the intention is for browsers to place constraints, but not sure how
> to express
> ... because we are not locking it down -- CDM can implement anything
> ... that is the argument
> ... certainly possible, what can we do?
> paulc: doesn't look like we can close down
> ... we can add some general spec
> joesteele: not sure we can address because the questions are not
> well-formed
> <adrianba> "This proposal extends HTMLMediaElement providing APIs to
> control playback of protected content."
> adrianba: this line specifies what the spec is for
> ... we can't do anything in the spec to control what the user agent can do
> ... we can only say what the spec is for
> paulc: mark this as "Won't Fix" with what Adrian says
> … "We believe the spec is constrained to video elements and anything else
> is out of scope"
> Bug 20961
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20961
> paulc: Bugs says -- please include scope of priviledges CDM require so we
> can evaluate
> ... do we agree with his statement?
> ddorwin: has been a discussion of what DRM is and whether it is targeted
> by this spec
> ... his argument is that the most limiting case is what is proposed
> ... we should not be talking about the other cases
> paulc: Mark says this is clearly not required in comment #4
> markw: reporters keeps coming back to claim only full DRM is supported
> paulc: I think we should resolve as "Won't Fix" and repeat Marks
> statement. His comment #4 is the definitive answer
> adrianba: we decided last week to resolve one of the bugs as not to
> define the CDM in the EME but abstract that away
> ... someone else can define that
> paulc: we decided to make that dependent on all of the other bugs
> ... several of the bugs were going to be marked as dependent
> ... did someone do that?
> adrianba: we decided that we would not decide the patented technology bug
> that way
> ... CDM specifics are outside the scope of EME
> paulc: suggesting we should use the same style resolution for 61?
> adrianba: yes
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20962
> paulc: moving on
> Bug 20962
> adrianba: resolving as we go
> Bug 20963
> paulc: made dependent on 20961 and 20944
> ... no discussion needed
> Bug 20965
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965
> Bug 20966
> paulc: please split ClearKey out
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016
> adrianba: asked Glen to respond and he did
> ddorwin: would be ok with "should" but it is already included
> paulc: how should we resolve?
> ... could mark and resolved to force the comment
> ... or we could change the MUST to a SHOULD
> adrianba: don't think that makes a substantial difference
> ... happy with the spec as it is written today
> ... could change SHOULD to MAY
> ddorwin: this should be discussed as a normal bug (for normative text)
> paulc: do we have an advocate for MAY?
> adrianba: not me, no change advocated
> pal: would this resolve the issue?
> paulc: probably not
> ... would meet most of his requirement by making it a MAY
> pal: we can ask Henri in the thread if this will resolve it
> paulc: don't ask permission, ask forgiveness - let's resolve and he can
> comment if this is a problem
> ... unless there is not concensus to change it
> joesteele: I think optional is good
> paulc: does anyone object to the change?
> no objections voiced
> <paulc> adrian
> paulc: resolve as WONT FIX and the group agrees
> adrianba: we should resolve later once we have implementation experience
> paulc: trying to encourage action on this
> ... any objection to RESOLVE LATER?
> ... add the comment about implementation experience
> ... no objections
> Bug 20964
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20964
> EME Supports content that depends on server with finite life
> paulc: was marked as dup but unmarked by reporter
> adrianba: look at the end
> markw: should just close this. Was agreed that the bugs title is a true
> statement
> paulc: resolve WONT FIX as this is not a bug
> ... any discussion?
> Bug 20966
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20966
> paulc: looks like a dup of 20965
> ... he agrees that is 20965 is resolved this bug is no longer relevant
> I think we could do something about 20965
> <adrianba> 20965 has a comment added to the SOTD
> pal: no discussion about this bug yet
> paulc: added as an open issue
> ... treat this one as the same
> ... can we treat them as siblings?
> johnsim: don't understand what the 20966 is saying
> markw: it seems to be saying that for EME to work you have to lose
> privacy and spec should explain that instead of glossing over
> paulc: let's treat this as 20965 for now, other folks can add comments
> for more clarity
> adrianba: comment that I added said this is an open issue
> ... is the proposal to add this bug to that list?
> paulc: yes
> ddorwin: should we change the title of the bug?
> paulc: not sure we understand the bug enough to do that yet -- clarify
> what trivialize means in this context
> johnsim: need to get that clarification
> paulc: can you draw that out of the reporter John?
> johnsim: yes
> Bug 20967
> EME does not allow independent implementation
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20967
> paulc: this was re-opened
> ... he wants an independent implementation of the CDM
> pal: nothing in the spec that precludes this, specifically with a shim
> ... if there is something that prevents the shim being written we should
> know about that
> paulc: should we use that argument in this argument?
> markw: we have said that CDM can use platform capabilities, the counters
> that come back for that are
> ... 1. how are they defined and how
> ... 2. how do I get access
> ... 2. ok for proprietary platforms but what about open source?
> boblund: nothing in EME that requires a shim to use platform capabilities
> ... could be part of the user agent?
> markw: could be part of the UA
> boblund: premise of the bug is wrong then, the UA could provide this
> pal: separate these issues, issue of the bug itself
> ... does not allow independent implementation -- bug can be resolved
> purely on that basis
> ... EME clearly does not disallow this
> ... could explore the issue of how EME works with platform
> johnsim: independent implementation is the question here?
> ... he is saying noone but the implementers would use this - but this is
> false
> ... the phrase independent implementation is the meat of the bug
> ... anyone could implement a CDM
> ... but commercial distributors use a limited number of CDMs
> ... since anyone can implement, the premise of the bug is wrong
> adrianba: I think we can state that we propose the prior resolution that
> the CDM implementation is out of scope
> paulc: in the past we have use WONT FIX or NEEDS INFO
> adrianba: WONT FIX or NEEDS INFO works
> Bug 20968
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20968
> paulc: this has been re-opened
> pal: 2 aspects to this bug
> ... bug as filed we cannot take action on without specific actions
> requested - could not resolve on that basis
> ... more generally people interested in how EME could be implemented could
> be addressed by this group, but could be indepedent
> paulc: open another bug?
> pal: could get there based on the email threads we have seen - not
> another bug
> paulc: any other opinions?
> markw: do we have a NON ISSUE resolution?
> ... don't want to seem to ignore, but disagree with the premise of the bug
> pal: can resolve INVALID
> paulc: suggesting we mark as INVALID?
> adrianba: I think the spec is fine, but we could also use INVALID
> ... INVALID usually means that this is not a real bug, misreporting etc
> ... but I am happy to use INVALID in this case
> paulc: we should use what is right
> adrianba: debatable if we mark INVALID, but current spec works for me
> paulc: we are stretching over time period
> Bug 20978
> <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20978
> paulc: related to 20963
> ... that one was reopened
> ... can we treat this as 20963?
> ... could mark this as a dup
> ddorwin: this is one where the CDM is not specified
> adrianba: we used that for a couple of bugs
> ... 20963 says more things are needed in the spec, wrong level of
> granularity
> ... this one says that if you specified this in the spec, the need for CDM
> would disappear
> <ddorwin> Similar to this comment:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20961#c8
> markw: yes, there can be proprietary CDMs not expected to be object level
> plugins, could be generic plugins
> adrianba: comment #8 is the resolution we had previously used. we will
> use the same resolution
> Bug 20982
> EME should define a VM for CDMs to run in
> <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20992
> johnsim: this is specifying how CDMs work not how EME works
> ddorwin: this is also about the interop
> boblund: 1st sentence is incorrect on the face of it
> adrianba: I disagree with John here - I think this is trying to propose a
> different level of abstraction for CDMs
> ... think it is about defining the environment for a CDM to run in
> ... it is a proposal for how to solve the interop problem
> ... could resolve as dup of 20944
> ... include a note that the group disagrees about the purpose of the spec
> paulc: any comments?
> Bug 21081
> Requesting an analysis of open source DRMs that could be adopted
> paulc: this is a request for non-normative text
> ... does not look to block FPWD
> ... is this resolved as 20944?
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21081
> paulc: anyone interested in doing this?
> johnsim: lots of confusion here, does not seem relevant to the EME spec
> boblund: agree with John
> adrianba: think I replied that if someone wanted to do this investigation
> and report back to EME, that would be a good thing
> paulc: on the public or the media list?
> <adrianba>
> http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0104.html
> paulc: response is saying that this could be a simple exercise but would
> like to be better informed
> pal: is this group aware of specific features that would prevent the use
> of these for EME? or any specific DRMs?
> ddorwin: several issues
> ... having more information to make a decision, having an informative note
> ... the other is whether these open source ones can be used in combination
> with EME or as a replacement
> ... lot of layers to this bug
> joesteele: believe there are DRMs that could not be expressed through EME
> ... but probably not these
> paulc: this look like possible examples of CDMs, resolve as dup of 20944?
> ... add an entry to 20944 pointing to this research
> johnsim: the premise of the bug is mistaken, hard to begin resolving it
> ... the assumption seems to be there is an open source DRM that is IP free
> ... that is not true
> ... also was the intent to have a CDM that is baked in - that was ClearKey
> right?
> adrianba: agree that the topic is broad, but this bug is more speciifc
> about what can be learned from these open source efforts
> paulc: think this is a straight forward question
> ... reporter is asking for more information
> markw: if anyone has the time to look at it, we could resolve this as an
> action for someone
> paulc: proposal is to resolve this as a dup of 20944 and point to these
> two as possible CDMs
> pal: read this as a narrow bug
> paulc: do we have an answer to the narrow question?
> pal: not sure who is using this, certainly on this call
> adrianba: could also resolve as NEEDS INFO pending further information on
> these DRMs
> <BobLund> +1 to Adrian's proposal
> <ddorwin> +1
> paulc: let's move to next topic -- lots more bugs
> ... need to go back and consider doing another CFC
> <ddorwin> One more bug:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21104
> paulc: need to talk to my co-chairs and look for guidance on how to
> proceed
> ... come back via email to the group
> Bug 21104
> pal: can we determine programmatically whether the decrypted video is
> available in plaintext?
> markw: the video element can have images captured on the Canvas
> ... if this is possible, that would be evidence for the Javascript
> ... I would expect if someone integrates this into a UA I would expect
> this to be disabled
> pal: no doubt it will be disabled, but how does application determine?
> ... do I get an error? black?
> markw: no discussion on this point
> ... not familiar with all the cases it supports
> pal: reading naively, if a way was provided for JS to determine might
> satisfy the bug
> ddorwin: goes to "real DRM" versus "fake DRM"
> markw: this is about driving a wedge between hard DRM and other DRM
> ... don't think this is a useful distinction
> ... DRM is still useful in this case
> pal: if there were a technical means of answering his question, I think
> that would resolve it
> paulc: any options for resolving?
> ... may not want to go here
> markw: reasonable to say that this is not technically useful
> ... close as WONT FIX
> ddorwin: talks about privacy implications, but we can leave that for
> discussion of other bugs
> paulc: Henri objection is pointing to the IEFT spec
> ... anything else to discuss?
> ... Ball is now in my court to go back to co-chairs and discuss
> <adrianba> The privacy issue can be discussed as part of bug 20965, etc.
> paulc: have dealt with technical matters in 1st pass, bugs may not stay
> resolved, but want to know if sufficient for CFC again
> markw: would it be appropriate to ask Rob Calahan if the resolutions are
> sufficient for his bug?
> paulc: that is for the chairs to decide, don't have to be bug-free
> markw: so chairs can say this is sufficient?
> paulc: yes. I want to ask if they are ready to say that
> ... thanks for everyones patience. In Geneva next week, try to get
> something to chairs tomorrow
> <ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
> ddorwin: one last thing -- the title change for the last bug
> ... individualization was added
> ... should hack off as a separate bug?
> paulc: yes - encourage to file a separate bug
> ... meeting next week is MSE, EME in two weeks
> ... hopefully can come up with a list of technical items you would like to
> address
> ... meeting adjourned
> Summary of Action Items[End of minutes]
> ------------------------------
> Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
> 1.137 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
> $Date: 2013-02-26 17:42:30 $
>