See also: IRC log
<trackbot> Date: 01 October 2013
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 01 October 2013
<paulc> Open bug summary: http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0001.html
no comments
paulc: everyone needs to rejoin
the working group
... have 45 days to decide
<paulc> Rejoin request: http://lists.w3.org/Archives/Public/public-html-admin/2013Oct/0000.html
<paulc> rejoin link: http://www.w3.org/2004/01/pp-impl/40318/join
paulc: go to the page, ping your AC Rep by following the link.
closes today. So far no substantive objections, closes midnight Boston time
<paulc> See: http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0001.html
Paulc: this is David's analysis
<paulc> http://tinyurl.com/7tfambo
<paulc> 21 bugs
paulc: the history here, is that
objection to CfC, to point to something broken in the heartbeat
document, technical comments don't block, and these three bugs
came from that type of response.
... are these duplicates?
markw: i do not believe they are duplicates
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23340
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23341
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23342
ddorwin: should we remove the goals section, introduction to "here is what this does" and not sure it fits in the spec anymore
paulc: let these rest for right now, but could you put that as comments on 23341 and 23342
<joesteele> +1 to removing the goals
<paulc> We'll leave this new bugs for now and return to these.
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854
adrianba: when i added the state
transitions, three issues left unresolved, wanted to see if any
more concrete feedback, and so this morning i replied...
... in David summary, three resolutions:
... key added, not clear under what circumstances it should
fire - proposal is to remove
<ddorwin> +1 to remove keyadded
adrianba: way of interrogating what state it is in, but no general interest in this so okay to remove for now
<ddorwin> +1 to deferring the state attribute unless/until we need it.
adrianba: previous discussed transition from ready state to error state, was not clear when doing the editing under what circumstances that would be needed
during playback, if you wanted to fire a key message, not clear if there is a reason to fire against the session or a playback error, so i am proposing to do nothing unless someone can propose text
markw: i think the state variable could be useful for debugging
adrianba: that was kind of why i proposed it, but when it came to updating the spec i had a consensus of people who agreed
joesteele: two questions - i was
one of the people arguing against the state variable, because
we thought we could calculate state from application
... how would you handle case of output protection failure
during playback? against media key session
<markw> @joesteele - I agree the app can calculate it, but having it explicit allows you to assert on whether the state is what you think it is - useful both for app debugging and UA testing
adrianba: only errors against
media key session are related to communication with the license
server to acquire keys
... original reason for session was to correlate messages - so
violation of output protections should be fired against the
media elements
joesteele: error codes on media element?
adrianba: i thought we added media error encrypted - should fire when error with playback related encryption
joesteele: should we not add this for the video tag?
adrianba: this is an extension spec, so defined as an extension
ddorwin: encrypted media and I
cannot play it. Media errors are fatal to playback.
... other than i don't know how to play this media, - as to
where to add them, everywhere you can fire an error - probably
say if there is some error fire a media key error
adrianba: first comment - if
there is an examp;le of an error that fires in this state which
is not terminal to playback, i would like to understand that a
little better
... in our implementation we determined that most of these
"during playback error conditions" occurs has no correlation to
a particular session
... so we actually - meant we couldn't continue playback, so we
use encrypted media error for this, only against sesssion when
it is specifically session related
<paulc> ac joe
adrianba: ready to error okay, but need text proposal
joesteele: output protection and
domain error are two examples - domain - in a blackout
situation, live stream i don't have rights for (part of)
... one way is key error to force a new license
acquisition
... key rotation and license rotation - key is standard CAS
model, minute or five minutes for - license rotation stream has
... different licensing group
... signalling a domain in the non-CENC case
ddorwin: we have some - this change depends on clarity on key errors - maybe we should add it to that
paulc: if we did that, adrian, could we close this bug
<joesteele> +1 to removing the key added and moving the other issue to the remaining error code bug
paulc: the answer to "remove key added" and "not adding a state variable" are okay, and ready to error added as a new bug
adrianba: propose adding to 21798
<paulc> Update 21798 with third item
<paulc> Therefore after updating the spec we can close out 21854 with the addition of the error code item to 21798.
paulc: next item for topics, 19809
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19809
<joesteele> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19809
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19809
ddorwin: part of the problem is
whether to fire "key added", perhaps move Adrian's action on
key added to this bug
... removed key added and that was the important thing
... remove all text when adding keys or events fired when
adding keys
<paulc> David will re-evaluate 19809 after Ade's changes 21854 are completed.
<paulc> Bug 17202
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202
joesteele: agree with intent of
David's comment but runs contrary to the ability - you want to
share keys to have a performant implementation
... not sure how to solve but i don't think we want to be
explicit about preventing it
adrianba: question how this bug relates to 21855
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855
joesteele: i was okay with what you proposed, my interpretation was it is allowed but not required to directly transition to the key ready state
adrianba: two parts to my proposal - yes, allowed but not required - but second part, only optimization we call out and if you have two sessions which are related to fundementally the same key once you got to the ready state
if further need to interact - no further optimization - so we don't have to deal with the complex questions david asked
ddorwin: my view of these two
bugs - 855 being this optimization, mainly related to the same
page, same init data multiple times,
... that is where we are avoiding network traffic, not the "i
saved this key" case
... there is a clear leakage of information if you use a domain
key the application is storing - so i would like to see Joe
propose a way to do domain keys that avoids leaking
information
paulc: but that is a response to 202?
joesteele: i will come up with some proposal there, my counter to that would be in all the situations - many - except some pathological situations
when you have a domain key susceptible to the kind of sharing you have mentioned - can be shared on client or server
<paulc> ACTION: joesteele to propose text for bug 17202 to propose how to share keys without leakage of information [recorded in http://www.w3.org/2013/10/01-html-media-minutes.html#action01]
<trackbot> Error finding 'joesteele'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.
paulc: would like an action - propose how to share keys without leakage of information
<adrianba> ACTION: joe to propose text for bug 17202 to propose how to share keys without leakage of information [recorded in http://www.w3.org/2013/10/01-html-media-minutes.html#action02]
<trackbot> Created ACTION-40 - Propose text for bug 17202 to propose how to share keys without leakage of information [on Joe Steele - due 2013-10-08].
<adrianba> ACTION-40 due 2013-10-15
<trackbot> Set ACTION-40 Propose text for bug 17202 to propose how to share keys without leakage of information due date to 2013-10-15.
<paulc> Bug 17682
paulc: next is https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682
<ddorwin> specific comments: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682#c11
paulc: walk through one at a time
ddorwin: 1 is JWK versus JWK
set
... mention key ID in the text - that they are base64 encoded,
padded, and then more confusing one is the encoding
... it seems ASCI compatible compatible encoding means multiple
things
adrianba: this is right out of the HTML5 spec, link to the definition of it in the HTML5 spec
<adrianba> http://www.w3.org/TR/html5/infrastructure.html#ascii-compatible-character-encoding
ddorwin: definition is where we got confused - seemed overly complex
paulc: difference of opinion -
define by reference or inclusion -
... david's question is more a technical one - don't agree with
the reference - can someone give a pointer to where this is in
the spec
paulc: so you are challenging the reference - so David is questioning whether this is the right reference
<ddorwin> there are 12 instances of "ASCII-compatible character encoding" in http://www.w3.org/TR/html5/single-page.html. All seem related to input or metadata.
adrianba: i guess my overall
thought on this bug is that some very specific proposal that
David has on implementation experience, make these changes and
point fix our way
... propose - i am happy with this and take another look at the
ASCII compatible encoding but not block on this
<ddorwin> http://tools.ietf.org/html/draft-jones-jose-json-private-and-symmetric-key
ddorwin: number six we didn't get to- linked IETF document is expired - Jason Private Key -
adrianba: documents have a lifetime of six months, goes away, look to see if we need to push it forward in the IETF
ddorwin: document as an issue?
paulc: would the task force worth
while sending Mike Jones a note asking status of this
draft?
... before we run out of time, go back to the question i asked
that adrian answered before I asked - any objection to David
implementing changes he proposed in 17682?
<joesteele> no objection
<paulc> Bug 17750 was next on the list
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
adrianba: highlight 17750 - that we didn't get to - i added comments - this is about the close method - proposed an amendment on state transition to deal with close and deals with mark's outstanding issue on key release
<paulc> Possibly related to Mark's work on 17199
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
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/subtopic:/topic:/ Succeeded: s/remiaining/remaining/ Succeeded: s/adrianba;/adrianba:/ Succeeded: s/p;ointer/pointer/ No ScribeNick specified. Guessing ScribeNick: johnsim Inferring Scribes: johnsim WARNING: No "Present: ... " found! Possibly Present: Adobe Mark_Watson Microsoft See aaaa aabb aacc adrianba davide ddorwin html-media https jdsmith joesteele johnsim joined markw pal paulc pladd trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Oct/0000.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 01 Oct 2013 Guessing minutes URL: http://www.w3.org/2013/10/01-html-media-minutes.html People with action items: joe joesteele[End of scribe.perl diagnostic output]