W3C home > Mailing lists > Public > public-html-media@w3.org > February 2013

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

From: Joe Steele <steele@adobe.com>
Date: Tue, 26 Feb 2013 09:55:04 -0800
To: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <9BE79060-CD4F-407A-AAEF-1C1D726AD9ED@adobe.com>


HTML Media Task Force Teleconference

26 Feb 2013


See also: IRC log


+1.425.269.aaaa, ddorwin, joesteele, pal, markw, paulc, johnsim, adrianba, +1.303.503.aabb, boblund
Paul Cotton

#5 progression to FPWD
Bugs discussed last time
Summary of Action Items
<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
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
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
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?
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 version 1.137 (CVS log)
$Date: 2013-02-26 17:42:30 $
Received on Tuesday, 26 February 2013 17:55:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:32 UTC