HTML Media Task Force Teleconference -- 26 Feb 2013

<trackbot> Date: 26 February 2013

<paulc> joining on the phone in a second

<paulc> agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0111.html

<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: 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 progres

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 elemtns 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 finitelife

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

<ddorwin> 2096

pal: no discussion about this bug yet

<ddorwin> oops. ignore.

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 t o 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

<pal> +

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

<scribe> Meeting: HTML EME Teleconference

- DRAFT -

HTML Media Task Force Teleconference

26 Feb 2013

Attendees

Contents

#5 progression to FPWD

Bugs discussed last time

Summary of Action Items

Scribe.perl diagnostic output