HTML Media Task Force Teleconference -- 01 Apr 2014

<trackbot> Date: 01 April 2014

<scribe> scribe: joesteele

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 01 April 2014

Role Call

Intro comments

Discussin F2F next week

Two groups to handle in the agenda

Promises, extensibility, ...

scribe: want to get a clear understanding

<paulc> s/accessibility/extensibility/

paulc: start the agenda with item #5
... first section is 25199
... David filed and made 5 other bugs dependent on it

Bug#25199

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

<paulc> Blocks: 17750 21798 24081 24216 24771

paulc: this bug blocks 5 other bugs -- David thinks this is a solution to those other bugs
... like to hear what others think on this

ddorwin: Promises is a way of returning async results -- WebCrypto going to LC with them
... we have async operations, previously used the Error event but kinda inconsistent
... but if you add methods have no idea where errors are coming from
... think Promises solve some of this issue

paulc: willing to spend time discussing as this group of bugs covers over 25%
... need to discuss or at least come up with a plan

ddorwin: it's four pages long -- happy to discuss

joesteele: I think it is a good idea -- but have to review fully

glenn: agree with the proposal

paulc: anyone else?

<pal> @paulc: very choppy

paulc: what is our plan for processing the 6 bugs?
... should I add this an an agenda at the F2F?

joesteele: I think we should discuss at the F2F
... only because I need time to review

paulc: would like to know this will let us clear those bugs

very choppy

reconnecting

<paulc> zakim is not answering

<ddorwin> i had that problem the first time i tried

<ddorwin> …this morning

Zakim?

not answering me either :-)

joesteele: has everyone had a chance to read David's proposal -- this would be a good time

paulc: will I have a concrete proposal at the F2F to handle these bugs?

ddorwin: the Promises API reshapes all these APIs
... we have committed to some of the changes, others change completely, it will be a drastic change

johnsim: is it the decision that we will change to Promises?

paulc: only two folks in agreement so far

joesteele: 3 including David

paulc: would like to get some sense from the group today what the impact would be on the other bugs
... would be a staged solution, if we decide to go that way in first 5 minutes, won't know how to process the other 5 bugs
... could review the impact of this change today

<ddorwin> 17750 - implemented but there are some remaining details being discussed; these are resolved by Promises.

<ddorwin> 21798 - errors will change drastically. still need to evaluate

paulc: proposals may look different for the other bugs if we go in this direction

<ddorwin> 24081 - resolved (mostly?) by Promises

<ddorwin> 24216 - agreed to do. Promises affect the API

paulc: 24771 Microsoft agreed to review, David marked it as dependent, Microsoft has made no comment as yet

<ddorwin> 24771 - jdsmith agreed. Potentially simplified by promises.

paulc: if we make the decision to move to this, not sure what we will do with the other bugs at the F2F

ddorwin: updated IRC with the status of the bugs you mentioned
... for the most part we have agreed on a solution

johnsim: has Mark made a comment yet? he is active there

ddorwin: not yet

paulc: will put this cluster on the F2F agenda
... we will try to make a decision on 25199 -- if you are not going to make a decision, make your position known before the F2F so folks can review and respond

<adrianba> i think moving in the direction of promises for async is good - i haven't reviewed the details of the proposal - my initial reaction is that promises might not map very well to the unordered events that can fire in EME

<adrianba> but i can see it making some of the error handling better

paulc: folks who own the other bugs should review Davids synopsis and determine if feasible/reasonable and how the bugs would change

<adrianba> is this an all or nothing proposal?

<pal> i have a question about promises

paulc: looks like Microsofts comment on 25771 is positive so we won't review further

ddorwin: Promises is not replacing all events, errors cannot be replaced by Promises

pal: looks like client support for desktop browsers, but not a core feature of ECMAscript, what about support outside of desktop browsers?

ddorwin: defined by ECMAScript now -- it is the future of async APIs

brad: is there a compelling reason to make the move now instead of resolving the bugs first and then moving later?

ddorwin: now is the time because it is a major change before LC

<glenn> +1 to what ddorwin said; the time is now, ... or never

<pal> ECMAScript 7?

paulc: this would be called out in LC review - so obvious thing to address now
... was this published as sidebar to ECMAScript 6?

<adrianba> it will be in ES6

ddorwin: thought it was in 6

pal: want to make sure we have a normative reference

ddorwin: WebCrypto is in LC (so would have this problem)

pal: we are not that group

paulc: understood

Bug#25092

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

paulc: filed by Mark -- not here
... David do you want to summarize?

<paulc> See David's response in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092#c1

ddorwin: it appears some implementations will downscale content based on the license, he wants a way for app to know that
... this is specific to that use case, perhaps what apps really need to know is what KIDs are usable at the moment
... previously the way to know what is usable was to play it
... this way app could query the available keys

joesteele: in this situation, the key may be the same for both resolutions. this is a specific example of the CDM needing to communicate to the application

ddorwin: did think about that - could issue licenses to fake KIDs and use those as a proxy for this
... what can you communicate in the same key case? need to figure that out in a consistent common and interoperable way
... think fake KIDs solves this in a generic way

paulc: let's move on - Joe please respond in the bug with your explanation. David can respond in kind
... more can be done at the F2F

Bug#25200

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

paulc: persistent license thread
... David you filed this bug

<paulc> Email thread: http://lists.w3.org/Archives/Public/public-html-media/2014Mar/0020.html

<glenn> re: promises in ES6, see sections 25.4 and 7.5 in http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_01-20-14-nomarkup.pdf

paulc: of course original requester is not an active participant

<ddorwin> This bug actually came out of https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025

paulc: Joe responded to the request

<paulc> Joe's response: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200#c1

paulc: handle here or at F2F

dorwin: this was actually my bug -- pasted above
... really talking about offline licenses
... Joe and Shinya have other models in mind
... might not match with EME
... this is mostly about offline storage and the license request

paulc: so it looks like there is a response from Shinya from this morning

<paulc> Shinya response: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200#c2

johnsim: in some cases whether the license can be persisted in dependent on the DRM not within the applications control
... lot of the discussion is around the application not being able to override what the DRM is saying
... I think that the question is whether EME should handle this at all or just handled by the DRM?
... also asking David -- what do you mean by offline licenses?

ddorwin: agree that DRM is ultimately responsible for the licenses
... talking about Netflix model .. if Netflix allowed you to get on a plane and still playback your content -- that is what I am talking about

johnsim: so you mean a licenses that can be used when offline
... that is what we mean as well -- no need to request a license when playing back
... in our model the decision is made by the service sending down the license
... at the DRM level not the application level

dorwin: I am thinking about watching online versus offline

<paulc> It looks like there is a cluster of 24025 (RESOLVED), 25200 and 25201 and possibly a bug filed by Joe.

johnsim: in the scenario where the app wants to do something - this is independent of what is negotiated with the service
... the application wants to prevent caching when it could be cahced

ddorwin: this flag would tell the CDM what the app wants to do
... can't override the DRM policy
... with the store() method would directly control whether stored or not

johnsim: what would the difference. be?

ddorwin: depends on the DRM

johnsim: would have to store it somewhere though.
... if I wanted to build a solution where I built the app and own the key server
... I can let the app/user decide whether to store the license
... then the DRM would issue the right kind of license (that could be persisted)
... as opposed to having it be a fixed policy at the server

ddorwin: the main proposal is that a flag is passed to allow the CDM to say I want a persistent license
... a flag to NOT store it is not what I meant

joesteele: this would not be used by anyone in my opinion

ddorwin: getting the persistent license and not storing it was not what I was proposing

paulc: this sounds like 24025 -- Joe says he would file a bug (25217)

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

<paulc> It looks like there is a cluster of 24025 (RESOLVED), 25200 and 25201 and 25217.

paulc: so this is another cluster of bugs that are related
... should be close to each other in the F2F
... I will skip the next two bugs then as they are related

Bug#25218

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

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

<paulc> Note to Paul: consider adding 25218 to the cluster of 24025 (RESOLVED), 25200 and 25201 and 25217.

<paulc> 25218 deals with sessions not be granular enough and it allows for the application to manage licenses/keys

ddorwin: want a clarification on what is in a session versus

<ddorwin> "A Key Session, or simply Session, represents the lifetime of the license(s)/key(s) it contains and associates all messages related to them."

paulc: will have to deal with this in the F2F -- not all scribed

<ddorwin> Sessions can only be created with initData.

Bug#18515

<paulc> David's comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c23

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

<pal> @ddorwin: will you be at F2F on Wednesday?

paulc: looks like it has been reopened

adrianba: think I implemented this -- was not my proposal
... think is was Jerry

jernoble: yes this is my bug

paulc: Jerry will look at David's comment

Last Topic - Complex set of bugs (7)

UNKNOWN_SPEAKER: paulc: 24951, 24673, 24873, 17673, 17682, 24027, 24419
... all of these bugs are interconnected as explained in the agenda
... some bugs block each other, some have transitive relationships
... some are waiting for actions from David, some are waiting for implementation from David or Adrian
... all are effectively in this cluster -- not sure which to pull to the top to discuss
... want to point out that the cluster exists and processing would resolve 30% of our bugs

<adrianba> I've made lots of changes for 24951 this morning.

UNKNOWN_SPEAKER: paulc: would be really good if you could come to the F2F knowing how you would like to process these bugs

adrianba: think this somewhat unblocked the other bugs
... the content type strings checks will probably not be an issue now
... some open questions will -- but think it unblocks 17673 for ISOBMFF
... might need some help for the archeology -- some older text might be resurrected

paulc: ok -- we are out of time
... think there are 4 main clusters to eal with at the F2F
... Promises
... License persistence
... and this last cluster
... plus extensibility cluster (2-3 bugs)
... that is most of the significant technical discussion. That is how I will organize the F2F agenda
... please let me know if you think that is the wrong thing
... will send a draft agenda for the media session in advance of the F2F so we have a written list of the order to do them in
... send me any suggestions you have

<scribe> ... done for today.

UNKNOWN_SPEAKER: adjourned

s/diff./difference/

- DRAFT -

HTML Media Task Force Teleconference

01 Apr 2014

Attendees

Contents