HTML Media Task Force Teleconference -- 19 Feb 2013

<trackbot> Date: 19 February 2013

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

Roll call, introductions and selection of scribe

paulc: done

Previous meeting minutes

paulc: no comments

Review of action items

paulc: none for this spec

Baseline documents

adrianba: it has been updated since jan 22 - i forgot to change the date
... we added a note to the abstract pointing to one of the bugs

paulc: might be more appropriate to put in the status of the document

adrianba: i added it where i thought most appropriate - happy to move it

<joesteele> +q

paulc: any more changes should be made in the ED and then maybe make a new FPWD

joesteele: how are we going to move forward?

paulc: that's next on the agenda

Progression to First Public Working Draft

paulc: included links in the agenda
... last time we said we were working with the Team on this
... result of this was a Team statement that the work is in scope for the HTML WG

<paulc> Team statement: http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0122.html

paulc: there have been some questions about this statement on the WG list

<paulc> Chairs decision on CfC: http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0123.html

paulc: subsequent to this statement, which the chairs helped edit for clarity, the chairs issued their decision on CfC
... divided into two topics: those about scope and those about technical issues
... the first set were ruled out of order based on the Team statement
... the second set requested specific bugs to be reported by Feb 15

<paulc> "specific bug reports to be filed against the Encrypted Media Extensions component in bugzilla[1] by February 15th."

paulc: what has happened is that we have a series of bugs filed
... list in the agenda is indicative, not definitive list - may be some others
... expect the TF to respond to this set of bugs
... when we reevaluate the publication of FPWD, we will consider only this set of bugs and assess how handled
... we need to review and decide how to respond

<Mark_Vickers> Where is the agenda with this list?

<ddorwin> got it

<joesteele> adrianba: 3 keys issues

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

<ddorwin> adrianba: There are 3 key issues we should try and address. The rest don't provide specific information or are out of scope.

<ddorwin> ...The three are 20944 to encourage interop, 20965 related to privacy (how to handle individualization such as individual keys for devices - and whether the spec should provide guidance on that), and 21016 - a proposal to separate Clear Key into a separate spec.

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965

<ddorwin> adrianba: The rest we have tried to address and were reopened without actionable information.

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016

<paulc> 20944: Editors have added a note to the Editors draft

<joesteele> +q

<joesteele> -q

paulc: those would be three that we'd discuss explicitly?

<ddorwin> adrianba: For the first two, I think we can just point to them as open issues as we did for MSE FPWD.

<joesteele> +q

<paulc> Adrian: proposes to add a note for 20965 as well as for 20944

<ddorwin> …For separating Clear Key into a separate spec, we probably need to look at that.

<glenn> +q

joesteele: i wanted to know about bug 20960 - EME is not limited to video
... whether there would be further comments on this

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20960

paulc: in some ways this is related to one of the other bugs

<paulc> See also the more recent bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21037

paulc: this bug suggests not using DRM and use IPSEC instead
... i think this is partially related to what content is sent over the wire
... they are concerned about encrypting general HTML content across the wire

glenn: on the ClearKey bug, it proposes two things
... make ClearKey a separate spec
... also not make it mandatory

<paulc> Discussing bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016

paulc: do you have an opinion?

glenn: i think it should be included in the spec - don't see why not
... open on the issue of mandatory or optional
... think we should recommend it
... could lower from MUST to SHOULD

Mark_Vickers: on 20960 - don't understand what specific thing they mean
... it is the case that some proposals include data alongside media - could include captions for example
... so yes could include data encrypted that could come out the other end
... not sure what would be needed to make that not happen
... this would be true of any codec

paulc: think comment says CDM could take data and transform into some other form of HTML
... think what we need to do is to get more context

Mark_Vickers: i agree

<joesteele> +q

paulc: if there is something in the spec that constrains this then that would handle it

joesteele: slightly different read: didn't say anything in the spec that says the CDM cannot put up UI of its own
... so i was reading that it said it could add some additional UI
... based on data coming in - we don't explicitly prevent UI

<glenn> +q

<paulc> Adrian: Not trying to exclude discussion on the other bugs.

adrianba: didn't mean to suggest that other bugs have no merit - just that they are too vague and don't include a proposal

glenn: since we don't define a way for CDM to receive UI events
... but in general we don't prevent a UA from doing something like this

paulc: on the other bugs - some of them we asked for more information and we have the example of one here with little information
... i'd like to be able to tell the co-chairs the status of each of these
... and what the proposed outcome is
... not sure how to do that without stepping through each one

<BobLund> +1 to that idea

paulc: any objections?

<joesteele> +1

<Mark_Vickers> +1

<johnsim_> +1

paulc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
... noted we propose to add text to the spec pointing out that this is a TBD
... any objections to this way to move forward?

<joesteele> no objection to this being a TBD

paulc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965
... proposed same disposition?
... add text to abstract or status saying this is outstanding question?

<joesteele> +q

paulc: in other business, noted PING call - markw has volunteered
... does this bug cover the scope?

markw: yes, volunteered - not sure if this bug is the issue

ddorwin: got cross-posted to that group

paulc: propose that if people think there are privacy issues they should file bugs

joesteele: proposing to add some text to say that this is an outstanding issue
... don't think we can make much progress until we can make a definitive statement

paulc: by progress do you mean to FPWD or after that

joesteele: i mean both
... getting to CR is going to require a statement that most people are happy with

paulc: we don't know yet

joesteele: when you say this is TBD before or after FPWD?

paulc: currently before

"Note: It is an open issue whether and how the spec should do more to encourage/ensure CDM-level interop. See Bug 20944."

paulc: would expect something similar for security/privacy
... not sure where to put it - to me this probably belongs in status section
... okay?

joesteele: okay

paulc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20960
... this is the one brought up before
... what i'm hearing is that we need more information

<joesteele> yes

paulc: should treat this with NEEDSINFO
... should start dialogue on this

joesteele: i can respond to the bug and see what Fred has to say

paulc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20961
... currently proposed in bug to close as non-issue for EME

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20961#c4

paulc: markw is proposing resolve as WONTFIX
... recent comment

<joesteele> no objection

paulc: assuming no objection to this
... https://www.w3.org/Bugs/Public/show_bug.cgi?id=20962
... depends on patented technology

<joesteele> +q

paulc: response is request to include CDM in spec so it falls under W3C terms
... believe related to general question of CDM interop?

<joesteele> -q

johnsim: i would interpret it that way

BobLund: i don't know that i would interpret that way - question is that since CDM is under HTML WG then this would be within HTML WG IPR
... it's up to the browser manufacturer what they include - same as a codec that isn't RF

adrianba: the bug says that not being in the WG is the problem since it doesn't require W3C IPR policy

paulc: this bug is asking for more specification so that the IPR policy applies

glenn: i think it goes beyond that - fully specify all CDMs
... not having the abstraction of a CDM

paulc: not hearing a definitive position

<BobLund> +1 to Adrian's position

<paulc> Adrian: The EME spec proposes to abstract away the CDM and therefore there is simply disagreement here.

adrianba: i disagree with CDMs being defined - the purpose of the spec is to abstract CDMs away
... don't think there is a compromise that works here

paulc: what you're proposing is WONTFIX?

<markw> +1

adrianba: i think the spec is covered by the patent policy and the parts deliberately out of scope are not
... i think someone could make a counter proposal if they like but that's not our goal with this spec

BobLund: i think the lack of a RF CDM implementation is a current thread of the discussion
... if someone wants to offer a CDM proposal that is RF then we could consider adding it to the spec

<glenn> +q

BobLund: like we did with ClearKey

<joesteele> +q

glenn: the open source issue is probably more important than the RF issue

<joesteele> -q

glenn: don't think we should open EME to try to solve the problem at this time - a follow-on spec would be fine

<MartinSoukup> +1 to making follow on spec if someone offers it

BobLund: not suggesting we take that on - just that if someone else does it we can consider

paulc: think we have a proposed resolution on this one

<Mark_Vickers> +1

<joesteele> +1

<glenn> +1

<MartinSoukup> +1 to meeting next week

paulc: would you be open to an EME call next week to make more progress on this instead of EME?

<johnsim_> +1

paulc: we have 45 bugs on EME and 5 on MSE
... would like permission of this group to have another EME call
... work with editors of MSE spec to process other MSE bugs by email
... not hearing any objections
... https://www.w3.org/Bugs/Public/show_bug.cgi?id=20963
... this bug says the spec is incomplete - this is one of the longer arguments

adrianba: i don't think having one bug saying "incomplete" is helpful

paulc: i would suggest making this bug dependent on the other three
... 20944, 20960, 20961
... if we make this dependent and say those are the best description we have

<joesteele> +1 to this approach

paulc: then when those bugs go away so does this one
... by default, agenda for next week will pick up on actions from today
... joe to follow-up and editors to action bugs discussed today
... will tell co-chairs to expect more progress next week
... ask people to come prepared or even propose resolutions in the bugs
... questions?
... out of time now
... don't think we got enough discussion about 21016
... we said this was two issues
... included in spec and mandatory or optional

<glenn> which bug did you ask about?

paulc: glenn perhaps you can respond

<ddorwin> @glenn: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016

<glenn> got it

Chair and Scribe for next meeting

paulc: we will meet next week on the 26th
... could i schedule for longer?

<joesteele> +1

<johnsim_> +1

scribe: i may try to schedule for 90 mins

<Mark_Vickers> +1

scribe: and get consensus at the beginning of the meeting
... and if not ask which items to deal with first

Adjournment

paulc: adjourned

- DRAFT -

HTML Media Task Force Teleconference

19 Feb 2013

Attendees

Contents

Roll call, introductions and selection of scribe

Previous meeting minutes

Review of action items

Baseline documents

Progression to First Public Working Draft

Chair and Scribe for next meeting

Adjournment

Summary of Action Items

Scribe.perl diagnostic output