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

Point of order: I believe the decisions of the working group on these matters demonstrate that the many of the participants and in particular Chairs are either not competent to work on this specification and/or acting in bad faith.   The W3C requires members to be technically competent and to act in good faith.  I believe the W3C has been mislead by the working group and should reevaluate its position on the EME specification on this basis and investigate the competence and actions of the participants of this working group and take appropriate action to ensure the individuals and their organizations are no longer able to command positions of any consequence in the standards setting process.

cheers
Fred 

From: steele@adobe.com
To: public-html-media@w3.org
Date: Tue, 26 Feb 2013 09:55:04 -0800
Subject: {minutes} HTML WG media telecon 2013-02-26 - EME bugs discussion

http://www.w3.org/2013/02/26-html-media-minutes.html



- DRAFT -HTML Media Task Force Teleconference26 Feb 2013AgendaSee also: IRC logAttendeesPresent+1.425.269.aaaa, ddorwin, joesteele, pal, markw, paulc, johnsim, adrianba, +1.303.503.aabb, boblundRegretsChairPaul CottonScribejoesteeleContentsTopics#5 progression to FPWDBugs discussed last timeSummary of Action Items<trackbot> Date: 26 February 2013<scribe> scribe: joesteele<scribe> chair: paulctrackbot-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.htmlpaulc: Topic is bugs discussed during previous meetingBugs discussed last time<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944Bug #20944<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944paulc: Is this done?
... adrian called this out? any more to do?adrian: that was itpaulc; Bug 20960<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20960paulc: EME not limited to video
... lots of discussionmarkw: not sure I have made progress+qmarkw: 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 specjoesteele: 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 forpaulc: 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=20961paulc: 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 casespaulc: Mark says this is clearly not required in comment #4markw: reporters keeps coming back to claim only full DRM is supportedpaulc: I think we should resolve as "Won't Fix" and repeat Marks statement. His comment #4 is the definitive answeradrianba: 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 thatpaulc: 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 EMEpaulc: suggesting we should use the same style resolution for 61?adrianba: yes<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20962paulc: moving onBug 20962adrianba: resolving as we goBug 20963paulc: made dependent on 20961 and 20944
... no discussion neededBug 20965<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965Bug 20966paulc: please split ClearKey out<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016adrianba: asked Glen to respond and he didddorwin: would be ok with "should" but it is already includedpaulc: how should we resolve?
... could mark and resolved to force the comment
... or we could change the MUST to a SHOULDadrianba: don't think that makes a substantial difference
... happy with the spec as it is written today
... could change SHOULD to MAYddorwin: this should be discussed as a normal bug (for normative text)paulc: do we have an advocate for MAY?adrianba: not me, no change advocatedpal: would this resolve the issue?paulc: probably not
... would meet most of his requirement by making it a MAYpal: we can ask Henri in the thread if this will resolve itpaulc: 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 itjoesteele: I think optional is goodpaulc: does anyone object to the change?no objections voiced<paulc> adrianpaulc: resolve as WONT FIX and the group agreesadrianba: we should resolve later once we have implementation experiencepaulc: trying to encourage action on this
... any objection to RESOLVE LATER?
... add the comment about implementation experience
... no objectionsBug 20964<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20964EME Supports content that depends on server with finite lifepaulc: was marked as dup but unmarked by reporteradrianba: look at the endmarkw: should just close this. Was agreed that the bugs title is a true statementpaulc: resolve WONT FIX as this is not a bug
... any discussion?Bug 20966<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20966paulc: looks like a dup of 20965
... he agrees that is 20965 is resolved this bug is no longer relevantI think we could do something about 20965<adrianba> 20965 has a comment added to the SOTDpal: no discussion about this bug yetpaulc: 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 sayingmarkw: it seems to be saying that for EME to work you have to lose privacy and spec should explain that instead of glossing overpaulc: let's treat this as 20965 for now, other folks can add comments for more clarityadrianba: comment that I added said this is an open issue
... is the proposal to add this bug to that list?paulc: yesddorwin: 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 contextjohnsim: need to get that clarificationpaulc: can you draw that out of the reporter John?johnsim: yesBug 20967EME does not allow independent implementationhttps://www.w3.org/Bugs/Public/show_bug.cgi?id=20967paulc: this was re-opened
... he wants an independent implementation of the CDMpal: 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 thatpaulc: 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 UAboblund: premise of the bug is wrong then, the UA could provide thispal: 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 platformjohnsim: 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 wrongadrianba: I think we can state that we propose the prior resolution that the CDM implementation is out of scopepaulc: in the past we have use WONT FIX or NEEDS INFOadrianba: WONT FIX or NEEDS INFO worksBug 20968https://www.w3.org/Bugs/Public/show_bug.cgi?id=20968paulc: this has been re-openedpal: 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 indepedentpaulc: open another bug?pal: could get there based on the email threads we have seen - not another bugpaulc: 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 bugpal: can resolve INVALIDpaulc: 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 casepaulc: we should use what is rightadrianba: debatable if we mark INVALID, but current spec works for mepaulc: we are stretching over time periodBug 20978<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20978paulc: related to 20963
... that one was reopened
... can we treat this as 20963?
... could mark this as a dupddorwin: this is one where the CDM is not specifiedadrianba: 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#c8markw: yes, there can be proprietary CDMs not expected to be object level plugins, could be generic pluginsadrianba: comment #8 is the resolution we had previously used. we will use the same resolutionBug 20982EME should define a VM for CDMs to run in<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20992johnsim: this is specifying how CDMs work not how EME worksddorwin: this is also about the interopboblund: 1st sentence is incorrect on the face of itadrianba: 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 specpaulc: any comments?Bug 21081Requesting an analysis of open source DRMs that could be adoptedpaulc: 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=21081paulc: anyone interested in doing this?johnsim: lots of confusion here, does not seem relevant to the EME specboblund: agree with Johnadrianba: think I replied that if someone wanted to do this investigation and report back to EME, that would be a good thingpaulc: on the public or the media list?<adrianba> http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0104.htmlpaulc: response is saying that this could be a simple exercise but would like to be better informedpal: 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 bugjoesteele: believe there are DRMs that could not be expressed through EME
... but probably not thesepaulc: this look like possible examples of CDMs, resolve as dup of 20944?
... add an entry to 20944 pointing to this researchjohnsim: 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 effortspaulc: think this is a straight forward question
... reporter is asking for more informationmarkw: if anyone has the time to look at it, we could resolve this as an action for someonepaulc: proposal is to resolve this as a dup of 20944 and point to these two as possible CDMspal: read this as a narrow bugpaulc: do we have an answer to the narrow question?pal: not sure who is using this, certainly on this calladrianba: could also resolve as NEEDS INFO pending further information on these DRMs<BobLund> +1 to Adrian's proposal<ddorwin> +1paulc: 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=21104paulc: need to talk to my co-chairs and look for guidance on how to proceed
... come back via email to the groupBug 21104pal: 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 disabledpal: 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 supportspal: reading naively, if a way was provided for JS to determine might satisfy the bugddorwin: 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 casepal: if there were a technical means of answering his question, I think that would resolve itpaulc: any options for resolving?
... may not want to go heremarkw: reasonable to say that this is not technically useful
... close as WONT FIXddorwin: talks about privacy implications, but we can leave that for discussion of other bugspaulc: 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 againmarkw: 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-freemarkw: 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=20944ddorwin: 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 adjournedSummary of Action Items[End of minutes]Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-02-26 17:42:30 $