HTML Media Task Force Teleconference -- 05 May 2015

<trackbot> Date: 05 May 2015

<scribe> scribe: Joe Steele

<scribe> scribenick: joesteele

<geguchi> aabb is me

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015May/0004.html

F2F action items

ACTION-82

ACTION-82?

<trackbot> ACTION-82 -- Paul Cotton to Figure out what's going to happen to media controller -- due 2015-04-22 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/82

paulc: contacted the w3c - but AC mtg is occuring in Paris, so still waiting for response

<paulc> ACTION-82 is due next week

<paulc> ACTION-82 due next week

<trackbot> Set ACTION-82 Figure out what's going to happen to media controller due date to 2015-05-11.

ACTION-83

ACTION-83?

<trackbot> ACTION-83 -- Daniel Davis to Point web and tv ig members to the use case wiki page. -- due 2015-04-22 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/83

paulc: don't know what the status is - anyone?
... best bet is to send Daniel Davis an email for update
... status unknown for now

ACTION-84

ACTION-84?

<trackbot> ACTION-84 -- Paul Cotton to (really rustamk) to update uses cases and arrange for further discussion -- due 2015-04-22 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/84

paulc: for Rus to update use case
... any status on this?

here is his address -- Rustam_Khashimkhodjaev@cable.comcast.com

ACTION-85

ACTION-85?

<trackbot> ACTION-85 -- Mark Watson to Provide additional technical recommendations for persistent-release-message based on implementation experience -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/85

paulc: discussion about this on the email

markw: I did a few things in response, updated the wiki page
... no agreement as yet
... also created a pull request to implement in the spec the changes I implemented last week
... the way that the mechanism works is not to require user agent to do any special work at shutdown

<markw> https://github.com/w3c/encrypted-media/pull/54

paulc: can you give the use case link
... ?
... does this complete the action?

markw: think this completes it

<markw> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Release

https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Renewal

<markw> yes, that is the link we are looking for

paulc: I am closing the action
... any further discussion needed today?

markw: no comments on the pull request as yet
... what I would like to know is whether the changes are acceptable and if we can bring into the spec

paulc: editor comments

ddorwin: thanks for updating the wiki
... replied to some questions on the renewal
... I was considering extracting Mark's info to another wiki path (not removing it)
... did look at the pull request, but what somewhat hard to review as the enum values were re-ordered - not sure why

markw: It seemed like there was a natural order
... when you make a pull request on github, it compares against the whole, unfortunately we don't have a nice HTML diff

<markw> Spec as revised by PR is here: https://mwatson2.github.io/encrypted-media/

paulc: think that answers the question about the ordering .. maybe should carry forward via email
... put on the agenda for next week

<markw> I can revert the ordering changes if you would like ?

paulc: let people know if you end up doing additional wiki work David

ddorwin: ok

markw: think it would be good to know whether the approach described makes senses

ddorwin: still parsing and have some concerns, but will respond on the thread

ACTION-86?

<trackbot> ACTION-86 -- David Dorwin to Send an update on bug 27269 -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/86

ACTION-86

ddorwin: this was not high priority so have not done anything yet

paulc: let's adjust the due date then

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

<paulc> ACTION-86 due in one month

<trackbot> Set ACTION-86 Send an update on bug 27269 due date to 2015-04-23.

paulc: I updated it to May 30th

ACTION-87

ACTION-87?

<trackbot> ACTION-87 -- Joe Steele to Carry out steps 1 thru 6 on the proposed solution to issue-41 -- due 2015-04-30 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/87

joesteele: think this is done

paulc: I believe it is done

<paulc> See http://lists.w3.org/Archives/Public/public-html-media/2015Apr/0064.html

paulc: closing with reference to that email

ACTION-88

ACTION-88?

<trackbot> ACTION-88 -- Paul Cotton to Check on whether the proposed generic license request/response protocol is in scope of the current html wg charter -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/88

paulc: I did that

<paulc> See http://lists.w3.org/Archives/Public/public-html-media/2015May/0003.html

paulc: the sad news it that it is deemed to be not in scope
... we were very careful to have a written dialog with the team and they decided this is not in scope
... the AC mtg going on includes the HTML WG charter going forward
... Accessibility efforts on under direct study as well
... lots of thinking going on about new work going forward
... when team comes back from Paris, we can start working on a new charter for the WG
... I will recommend that the technical dialogue does not continue on this list for now
... I will leave this open for now

<paulc> ACTION-88 due in two weeks

<trackbot> Set ACTION-88 Check on whether the proposed generic license request/response protocol is in scope of the current html wg charter due date to 2015-04-23.

markw: one of the suggestions on the list for this idea was to take the clearkey protocol and wrap it in security wrappers
... would it be in scope to work on the clearkey protocol and just add features to that?
... with the intention of folding this work back in later when/if scope is approved

paulc: would you make that proposal in the email thread I mentioned?
... it has ACTION-88 in the title
... I can take offline with the team and work on it

pac: I updated the end date for this action item

<ddorwin> I seem to have been dropped.

ACTION-88?

<trackbot> ACTION-88 -- Paul Cotton to Check on whether the proposed generic license request/response protocol is in scope of the current html wg charter -- due 2015-05-20 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/88

ACTION-89

ACTION-89?

<trackbot> ACTION-89 -- Paul Cotton to Do a html wg cfc to move eme to process 2014 and to move it to be published automatically to tr space for each editor's draft commit -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/89

paulc: this was done

<paulc> See http://lists.w3.org/Archives/Public/public-html-media/2015May/0009.html

paulc: CFC is ongoing

ACTION-90

ACTION-90?

<trackbot> ACTION-90 -- Paul Cotton to Update bug 20944 if the tf goes ahead with work on generic license request/response protocol -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/90

paulc: this action is dependent on action 88
... changing the date also

ACTION-90?

<trackbot> ACTION-90 -- Paul Cotton to Update bug 20944 if the tf goes ahead with work on generic license request/response protocol -- due 2015-05-20 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/90

ACTION-91

ACTION-91?

<trackbot> ACTION-91 -- Paul Cotton to (really rustamk) to ask cable labs about their current eme testing and whether they can expose it to the tf -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/91

paulc: ask CableLabs about testing -- seems like in progress and have seen emails from Rus
... will push the date out a bit on this for further research

BobLund: I will update the action item, think it is really on me

paulc: you can put right on the list for more notice
... put the ACTION-90 in the subject

ACTION-92

ACTION-92?

<trackbot> ACTION-92 -- Paul Cotton to Build a generic wiki agenda for future tf meetings -- due 2015-04-23 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/92

paulc: this is still pending
... that takes us to MSE bugs

New MSE bugs

paulc: both filed by Matt -- don't have any discussion yet
... do you want to discuss today

Bug 28557

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28557

MattWolenz: related to putting in more details around the track buffers
... updating the frame processing algorithm
... determine whether it is possible to <garbled>

<paulc> May be related to https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242

a/MattWolenetz:/MattWolenetz:/

paulc: sounds like this is related to bug 27472 related to track buffer ranges

MattWolenetz: related but not blocking
... probably just put forward a pull request with my recommendation

Bug 28573

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

MattWolenetz: this was not filed by me

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28573

MattWolenetz: don't think the networks state is what the writer thinks it is

paulc: so you will propose a response?

MattWolenetz: yes

MSE test suite status

paulc: At the F2F Matt you said you would take a look

<paulc> See F2F discussion: http://www.w3.org/2015/04/16-html-media-minutes.html#item01

MattWolenetz: I have been prodded, have it on my plate
... Cyril's message does not tell me how to run -- <garbled>

paulc: think we talked about a mtg, saw an email from you, will leave in your hands

NEW EME issues

paulc: 5 new issues

ISSUE-50 - Remove recommendation for distinct keys for distinct policies

https://github.com/w3c/encrypted-media/issues/50

ddorwin: Pull requests use up numbers BTW

markw: I saw this recommendation, I don't recall ever agreeing to this recommendation
... it is certainly one approach but some constraints make this impractical
... some devices in the field do not support multiple keys
... we need to be able to reuse existing streams
... so I think we should remove this recommendation

ddorwin: updating the bug now
... this is related to issue 22 -- it is a non-normative note

<paulc> https://github.com/w3c/encrypted-media/issues/22

ddorwin: you are not forced to follow, but it will provide the best interop
... I will post an update in the spec

joesteele: I would recommend we do not include author recommendations in the spec
... maybe move into a separate document
... non-normative text would clutter up the spec

markw: I was just noticing this text. There is a note in issue 22 about this being committed, during the discussion. This seems controversial.
... also agree with Joe that it might be better to have this advice elsewhere

paulc: David has given folks a ptr and patially answered Marks question, He said he will update the issue.

ddorwin: Just to be clear, this note does not disallow what Mark wants, it just points out that this will impact interop

markw: what you just said is different than the note, with evidence I would not object to providing that type of recommendation
... havign different keys definitely has a security advantage and explaining that would be good

ISSUE-51 - Remove steps associated with cross-origin or non-clearable identifiers, as these are not allowed

https://github.com/w3c/encrypted-media/issues/51

markw: another thing I noticed where some steps were included prior to us not allowing these things.
... now probably not needed since you would be clearly non-compliant

paulc: commnets?

ddorwin: as long as we specify that it is not allowed and that we know there will be bad behaviors, I agree this is wierd
... I think we could reformat the whole thing
... I think there will be EME implementors who violate the first condition

markw: but now the spec is contradictory, one piece says it is allowd but another piece might indicate it is allowed

ddorwin: I don't care strongly about this, just explaining why it is where it is

paulc: sounds like no disagreement that a change is needed
... we can leave this with the editors

ISSUE-52 - Remove reference to keys in Initialization Data definition

https://github.com/w3c/encrypted-media/issues/52

<paulc> Related to ACTION-87: Carry out steps 1 thru 6 on the proposed solution to issue-41 [on Joe Steele - due 2015-04-23].

<paulc> ACTION-87?

<trackbot> ACTION-87 -- Joe Steele to Carry out steps 1 thru 6 on the proposed solution to issue-41 -- due 2015-04-30 -- CLOSED

<trackbot> http://www.w3.org/html/wg/media/track/actions/87

joesteele: this text should be very clear, suggesting to remove one clause in the sentence

paulc: since we had concensus at the F2F we should not have much time on this

ddorwin: I think this is blocked on the next bug

joesteele: I thought the blocked was the other way

ddorwin: the reason the keys was there is that there is no support in the spec for process keys
... we are missing the text for how do we process keys

<paulc> https://github.com/w3c/encrypted-media/issues/41

joesteele: this is the older bug https://github.com/w3c/encrypted-media/issues/41
... I don't have rights to add labels to the issues

paulc: think the understanding is that issue 41 has evolved, and as David said 41 and 52 must be resolved together

markw: W3C sent invitations which should give you extra rights on github

paulc: think that was just editors
... but I will not let that stand in the way of progress

ISSUE-53 - Allow for long-lived key encryption keys (aka "master" keys) to increase performance

https://github.com/w3c/encrypted-media/issues/53

<paulc> spun out from https://github.com/w3c/encrypted-media/issues/41 and blocks https://github.com/w3c/encrypted-media/issues/52

joesteele: this is the use case I think is useful to include in the spec. It was spun out from Issue 41. It does not have fully specified text as yet -- just requirements

ddorwin: have not had a chance to look yet

jdsmith: it look like you are proposing master keys are persistent regardless of whether the session is persistent or not
... David has argued in terms of the clarity

joesteele: Ideally these keys would be invisible to the application. Making them fit the persistent session model would be good because it would allow the app to remove the keys, but would require some mechanism for exposing the keys to the app
... that does not seem necessary

ISSUE-55 - Clarify that "resources" in close() method refers to non-persisted data

<paulc> https://github.com/w3c/encrypted-media/issues/55

https://github.com/w3c/encrypted-media/issues/55

paulc: sounds like agreement from folks here
... do editors know what they need to do?

<markw_> yes

jdsmith: think that it is clear

Next Mtg?

paulc: next week? two weeks?

ddorwin: can't make next week

paulc: will meet in 2 weeks then

<markw_> I may not be a able to make it in two weeks time

paulc: Matt can you make next week for MSE?

MattWolenetz: yes

paulc: EME is 2 weeks then

rrsagent: draft minutes

markw: might not make next mtg then

paulc: thanks for scribing!
... bye all