See also: IRC log
<trackbot> Date: 28 January 2014
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0059.html
<scribe> ScribeNick: joesteele
ACTION-48?
<trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-27 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/48
adrianba: We agree with David on using the content type string
<paulc> See Ade's update at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c38
adrianba: need some more discussion in the task force
close ACTION-48
<trackbot> Closed ACTION-48.
paulc: let's close then
ACTION-61?
<trackbot> ACTION-61 -- Paul Cotton to Work with wendy to make sure we get a security review of eme -- due 2013-12-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/61
<paulc> lates is at htp://lists.w3.org/Archives/Public/public-html-media/2014Jan/0056.html
paulc: followed up with Wendy
<paulc> latest is http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0056.html
paulc: still pending
Action-62?
<trackbot> Action-62 -- Paul Cotton to Report back about the plan for 20944 due 2013-12-15 -- due 2013-12-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/62
paulc: still pending
action-63?
<trackbot> action-63 -- John Simmons to Provide a proposal for bug 24207 to define the shape of cleankey pssh boxes -- due 2014-01-28 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/63
<wseltzer> [We have a potential reviewer in the WebSec IG; I'll follow up by email.]
paulc: on John Simmons
<adrianba> i think this is 24027
johnsim: not on computer yet -- in a few minutes
Agenda #5
paulc: David original email
proposed we look at this list before heartbeat discussion
... what should we do about a heartbeat?
... doesn't sounds like either of these will be easily
closed
<adrianba> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0062.html
adrianba: sent an email this
morning with bugs needing action from oldest to newest
... agree we won't close them all quickly, but we have made
substantial progress since last heartbeat
... fall into the trap of trying to close those that are most
desirable, but should not block publication
<paulc> +100
paulc: agree completely
<paulc> David's priority items email: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0015.html
ddorwin: that's fine -- these are just the most important, but we have published more incomplete drafts
paulc: then this is the current draft
<paulc> Current editor's draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
paulc: is that draft ready to go? candidate heartbeat?
ddorwin: yes, just one typo
paulc: how should we proceed then? since you did not know this was coming don't want to force
<adrianba> +1
paulc: is the group ready to
forward this as a publication?
... any objections?
<ddorwin> +1
joesteele: none from me -- +1 to publishing
paulc: ok David, please make the
editorial changes and move to location that won't change
further
... suggest you publish by Feb 6th if you can get it done
today
... do we need to look at the status section?
... 20944 is mentioned - probably still not finalized
ddorwin: correct, some cleanup but nothing that affects this section
paulc: is there a changelog in this doc?
<adrianba> changelog is in mercurial
paulc: nothing to tell a reader
what has changed since Sept 2013 -- that's a long time
... suggest we just publish as is with editorial changes
<markw> ok with me
s/.. sugest/... suggest/
paulc: back to agenda
<paulc> Next ACTION: TF to discuss David's proposal that Microsoft supports to change the string associated with needkey/createSession
paulc: Adrian your email with recommendations came late so did not print -- can I use in the notes?
adrianba: two related issues - may need to separate
<paulc> Ade's update is at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c38
adrianba: 1. when you fire a
needKey you provide a string which tells you the format of the
initData, used when you call createSession
... so we have been discussing making simpler by indicating
that "this is common encryption" which defines the format as a
series of PSSH boxes
... this simplifies the specification, because otherwise we
would require implementations to do something more complex
because MP4 allows for more options
... 2. even if we move forward with TPAC plan, problem with
applications using isTypeSupported since you can't guarantee
until you have tried it
... possible to support the keySystem and the container and
still not be able to play without more information
... think they are related but not sure whether we need to
separate them
... good to get feedback from player implementers
ddorwin: in parallel I have been thinking that isTypeSupported is insufficient, will file a bug when I get around to it, otherwise I agree
paulc: can we resolve by carving off that item?
ddorwin: adrian is looking for feedback
adrianba: would be good to get David Singers review
paulc: so you did not work with him yet?
adrianba: if you look at what we
did with MSE think we should move the definitions outside of
this spec, an informal registry, this string would map to one
of those definitions
... one for WebM, one for CENC, etc
... so what would you do if you want a SINF would be
relevant
... if you did try to playback something requiring SINF when
only CENC is supported, get back the same error as
isTypeSupported
... not sure how specific we want the error result to be
markw: if we want to provide full
capabilities, not just container and decryption, its also codec
and keySystem
... do we actually need more MIME type parameters?
... more granualar
adrianba: agree with what Mark
said about the features matching to the capabilities, I
mentioned these in the bug as well
... using an enhanced content type string with other parameters
might be a way to go, but the potential downside is that we
have to generate from the needKey event
... so we have to think through what we want to do
... i.e. create the string which is video/mp4 and then the
string which is added for the codec and for the type of
encryption, maybe something else
... starts to become an awkward string to create
... might not be the best approach
pal: what about taking the
registry approach where we register the format combination of
video, codec e.g. like CFF Ultraviolet
... the value used signals compliance with the specification
includes codec, encryption, etc. is that an option
s/singnals/signals/
<pal> video/vnd.dece.mp4
s/singals/signals
<markw> @adrian: I think creating such a string would be merely tedious rather than awkward: video/mp4;codec=avc1.xx.xx;keysystems=<uuid>,<uuid>,<uuid>;protection=cenc
pal: just exploring avoiding parameterize all combinations
paulc: have heard two actions --
more on agenda
... one is for David to split off the issue Adrian
described
... second is for folks to look at Adrians proposal and also
engage David Singer
<adrianba> markw, but then the consumer has to parse the data back out again and so we end up with lots of people writing encoders and parsers for this string
<adrianba> markw, perhaps that is defined as tedious - i wonder if there is a better way is all
<paulc> Item for David to split off is about whether isTypeSupported is insufficient
<paulc> Item for Adrian is to ask David Singer to review https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c38
<ddorwin> MIME type, including codec= and profile= is defined by an RFC. We shouldn't mess with that string
paulc: this has action-63
pending
... Adrian you said there is a proposal made by Pavel
<ddorwin> initData format should be a different parameter/attribute
<paulc> ACTION-63?
<trackbot> ACTION-63 -- John Simmons to Provide a proposal for bug 24207 to define the shape of cleankey pssh boxes -- due 2014-01-28 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/63
<paulc> Next ACTION: ACTION-63 on John to make proposal - there has been a proposal made by Pavel with comments from David
<ddorwin> I'm not sure we need the MIME type in all places we need protection
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027#c2
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027
<paulc> Pavel's proposal: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027#c2
paulc: do you believe this makes Johns action item moot?
adrianba: assume John will want to review
johnsim: this is inline with what I was thinking
paulc: free to mark as closed and leave a link to what you did
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619
paulc: since we are going ahead with the heartbeat this is no longer blocking
ddorwin: implemented this
yesterday
... deleted all the error codes and replaced with names
... but was wondering do we really need this
<paulc> See David's question in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c8
ddorwin: MediaError is inherited from DomError -- do we really need the system code or just use DomError since it is just a message
<ddorwin> https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#error-codes
ddorwin: if it is mainly for debugging
<ddorwin> ^updated yesterday
adrianba: read the comments,
haven't had time to ponder deeply yet, need to discuss
... initial thinking is that message is intended to be
something you can display
... you could construct a message and include additional error
code
... this might be ok
... you capture the whole string and then you would need to
parse it somewhere
... did not know whether there are cases where people look at
the system code to determine whether to try again
... having it in a message might make it harder to access
... understand the proposal but just wonder whether this is the
right thing for practical implementations, since some apps will
have dependencies
ddorwin: if it is used for
switching, makes sense to have a code, but said it would make
more sense for logging
... easy to switch to DomError which would make that easier
paulc: could look at new bugs or
try to scan bugs with proposal and discuss ones that make
sense
... ok to skip new bugs?
... hearing no objections
<paulc> Latest from DEc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c8
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027
paulc: its 24025
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025#c6
ddorwin: no progress, tied to the general extensibilty issue
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24216
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24216
ddorwin: there is tl;dr at the top -- no replies yet
jdsmith: I was not certain about the scenarios, would like comments from John Simmons on this
<paulc> Ade's reply: Next ACTION: TF needs to review and discuss - I know Jerry is looking at this for Microsoft and waiting for feedback internally
jdsmith: attaching and removing keys is important to this bug
<ddorwin> Suggest next topic be: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c19
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081
paulc: proposal from Jan 18th
<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081#c4
paulc: Adrian got a reply, Marks
got a reply
... anyone else
... any more comments or review needed?
joesteele: looks good to me
paulc: shall we ask David to
implement?
... have 4 supporters -- please add to your list David
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24323
<paulc> No responses yet.
ddorwin: we were trying to decide whether needKey should be fired - renamed the algorithm -- but not sure the name is appropriate anymore
<paulc> Ade's status: Next ACTION: Feedback needed from TF
ddorwin: other issue is that the
spec currently allows you to detect that a stream is encrypted
whether or not initData is available
... not true for WebM or BMFF or CENC
... want to change alg to say initData indicates potentially
encrypted stream and to fire needkey with that initData
paulc: move on
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
paulc: where does this
stand?
... reply from Jerry to at least one of Davis responses
<paulc> See proposla in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c19
paulc: latest is a fairly detailed proposal
ddorwin: fine with this, we should implement and review from there
paulc: so add this to the list if no objections
ddorwin: assign to Adrian? Jerry can pick an editor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24368
paulc: related to 18515
... is this an actual proposal?
... comment #1
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24368#c1
ddorwin: think I answered my own
question but would like feedback
... appears to be covered by MSE and HTML5 but not very
explicit - might be a bug
... could add a line to Jerrys proposal in the bug
paulc: this is assigned to
Adrian
... best plan is to have 18515 editor to look at this as
well
adrianba: not assigned to anyone yet
ddorwin: if Jerry wants to include this that would be fine
jdsmith: I will review
<paulc> Bug 24368 - Define playback behavior when the key for an encrypted block is not available for a subset of streams
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24368
paulc: on the agenda twice -- let me look
let's skip
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24381
joesteele: looks like an editorial change?
<paulc> Already covered. See above.
<paulc> [Bug 24381] New: HTMLMediaElement.setMediaKeys() appears superfluous
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24381
paulc: filed by Phillip
adrianba: believe we have
discussed this but have not had time to find it
... discussed a long time ago
paulc: any more evidence offered?
adrianba: don't agree with the proposal but need to find the old bug
paulc: think we have covered the agenda
paulc: I believe we have a couple
of MSE bugs
... don't want to convene specifically to cover these bugs, but
wanted editors to know there are some CR bugs
... filed by Phillip
adrianba: might be implementation experience from Aaron
paulc: will wait until we have more than 1 or 2, continue with EME for now
<paulc> MSE bug re WebIDL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24370
paulc: in two weeks (Feb 11th) I am on vacation -- what does the group want to do?
<ddorwin> One more EME new bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24419
paulc: could make up the agenda before I go and pick another chair
johnsim: sure
paulc: that is what I will do
then
... we can pick some items to go over, appreciate advice from
the editors
<adrianba> thanks paul
s/s\/.. sugest\/... suggest\///
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ITems/Items/ Succeeded: s/Topic: bug#17673/Topic: Heartbeat/ FAILED: s/.. sugest/... suggest/ Succeeded: s/type parameters/MIME type parameters/ FAILED: s/singnals/signals/ Succeeded: s/singals/signals./ FAILED: s/singals/signals/ Succeeded: s/trying to/exploring avoiding/ Succeeded: s/bug#24027/bug#24025/ Succeeded: s/not true for WebM/not true for WebM or BMFF or CENC/ Succeeded: s/say when potentially encrypted content is found then fire the initData/say initData indicates potentially encrypted stream and to fire needkey with that initData/ Succeeded: s/John Simmons: /johnsim: / Succeeded: s/none from me/joesteele: none from me/ WARNING: Bad s/// command: s/s\/.. sugest\/... suggest\/// Succeeded: s/aciton-63/action-63/ Succeeded: s/undertsand/understand/ Succeeded: s/imeplementations/implementations/ Succeeded: s/objecitos/objections/ Succeeded: s/rssagent, generate minutes// Succeeded: s/you list/your list/ Succeeded: s/and editor/an editor/ Succeeded: s/apprecaite advice form/appreciate advice from/ Succeeded: s/capabilitys/capabilities/ Succeeded: s/ehanced/enhanced/ Succeeded: s/the signal used signals. compliance/the value used signals compliance/ Found ScribeNick: joesteele Inferring Scribes: joesteele Default Present: paulc, markw, +1.425.269.aaaa, joesteele, adrianba, ddorwin, davide, JamilEllis, pal, BobLund, johnsim Present: paulc markw +1.425.269.aaaa joesteele adrianba ddorwin davide JamilEllis pal BobLund johnsim Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0059.html Found Date: 28 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/28-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]