See also: IRC log
<joesteele> paulc: the agenda is now on the EME section. David believes the issues in item #2 he has commented on all of them and we can discuss as a group and put feedback before David comes online at 10:30am our time. Some folks may have already responded. The work assignment until then is to review these issues. Take 5-10 minutes to go over them. We will start at 9:15 or so
<paulc> Chair: paulc
<joesteele> https://github.com/w3c/encrypted-media/issues/68
<joesteele> paulc: Mark you responded 3 days ago
<joesteele> markw: there are many issues about key ids but this is standalone
<joesteele> ... if folks agree we can note it and move on
<joesteele> jdsmith: do we want feedback now?
<joesteele> paulc: I can poll the room
<joesteele> ... we can walk through again once David is online
<joesteele> paulc: we just want to close on these as much as possible before David gets here
<joesteele> ... Mark has a suggestion in this issue
<joesteele> markw: I responded that the key id is a sequence of octets — that should be uncontroversial
<joesteele> ... that has an order — it is a propertty of that thing
<joesteele> ... you have to be careful about how you represent the order
<joesteele> ... if you represent as a GUID there are multiple ways of doing it
<joesteele> ... but as a BufferSource there is no ambiguity
<joesteele> rus: treat as bytes then?
<joesteele> markw: yes — if someone wants to represent as a GUID that is their repsonbitilty to reolve then
<joesteele> paulc: so concensus seems to be that we could just add that it is a sequence of octets
<joesteele> markw: if clarifying that is useful , is that sufficient to address David concern?
<joesteele> ... do people agree with me?
<joesteele> joesteele: I agree
<joesteele> paulc: so when we have consensus I will mark on my list to come back to
<joesteele> https://github.com/w3c/encrypted-media/issues/85
<joesteele> paulc: this is the TAG issue that we will skip for now
<joesteele> jdsmith: are we going to get an update from Travis on this?
<joesteele> paulc: no
<joesteele> https://github.com/w3c/encrypted-media/issues/98
<joesteele> paulc: David had a proposal here to always fire the event and ensure consistency
<timeless> scribe: timeless
joesteele: not an implementer,
don't know what the impact of this would be
... seems like it'd be something that would vary between
CDMs
paulc: he has explicit questions here, and then a proposal
jdsmith: he has two
proposals
... one is waiting for key-event multiple times
... i'm not sure about
... attempting to do playback multiple times
... if it fails, UA can try again
... he's proposing to remove it
paulc: he's referring to ISSUE-83
joesteele: if the CDM is
downloadable, I don't know if the UA would know that resuming
would fail
... I agree w/ jdsmith, I don't see a reason not to allow it to
fire multiple times
... leave it alone, no incompatibility
jdsmith: i'm having trouble w/ a
reason to keep the other language
... "where the UA has knowledge that resuming will fail"
... I doubt that's practical, unless an implementer is here
joesteele: ISSUE-83 on a
Track
... markw does a key record need to be updated ...
... it's unrelated, but he's pointing to it
markw: he's pointing to it,
... there's a potential for an update to happen w/o keys
delivered
... an update could come, and not provide keys
... the app should watch status event to see what happens
... not sure we need the subsequent
waiting-for-key-events
... but it's a continuing state, you're waiting until you see
it
rus: I agree w/ markw
... app shouldn't assume something it doesn't know about
... get specific events + notifications, should be zero
assumptions from app
paulc: ok to fire more than once?
markw: only file when you transition from waiting-for-key to not-waiting-for-key
paulc: jdsmith, seems contrary to what you said originally?
jdsmith: i guess you could argue
it's a spurious event, not very useful, doesn't tell you
anything
... waiting-for-key-fires, key arrives, you try to resume
playback, i think that's the desired flow
... on allowing the events, i don't know there's a strong
negative if you trigger waiting-for-key-event
markw: only fire event when state
changes
... i agree w/ ddorwin's suggestion that it should at least be
consistent
... either we should only send event when state changes
... or we fire after every update that doesn't deliver the
correct key
... question from author's PoV
... if you fire event after every event, you know there's an
event waiting-for-key or key-status-change
... that might be useful
... otherwise, what happens
... you still know you'll get something
... either media-key-status-change, or another-message
joesteele: that's the issue
... you've put an update, you should get something indicating
processing-is-done
... got-a-key, waiting-for-key, error
markw: if you're waiting for a key, you get a message
jdsmith: you're agreeing
joesteele: we're agreeing
markw: you will get a message if you're waiting
joesteele: you're waiting for a key, you'll get a message indicating what to do to go forward
[ paulc reads proposed comment for issue from github comment box ]
joesteele: which is the least amount of work?
paulc: this issue is marked for
AUTHOR input
... ddorwin's suggestion is we need input from people writing
authors
... we can suppose we're authors
jdsmith: but we aren't
markw: i can ask our implementers
paulc: that's a possible answer to the first question
<trackbot> Error finding 'for'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.
paulc: there's a second question, do we have a position on removing this text?
<joesteele> action markw to ask his developers about issue-98
<trackbot> Created ACTION-103 - Ask his developers about issue-98 [on Mark Watson - due 2015-11-06].
markw: i agree w/ the suggestion to make it consistent, we can work it out
paulc: not confident that's the right solution, but you agree in general?
jdsmith: implication is, you're
waiting for a key, you receive one, you're supposed to attempt
to resume playback
... but UA knows in advance it won't work
rus: app should attempt and worst case it gets a failure
jdsmith: that's what i'd assume
paulc: so i hear a preference for removing the (short circuit) text?
jdsmith: +1
joesteele: +1
rus: +1
paulc: markw, you said you'd get that feedback?
markw: yep
[ paulc reads the proposed pending comment again ]
jdsmith: we're trying to button
up the spec
... worried we're twiddling knobs
... value consistency over tweaking too much
... i think it's consistent to fire the event
markw: right now, as spec is
written, they can't rely on the event
... so right now they don't rely on this event
... if you make it happen always, then it might encourage
people to rely on it
jdsmith: instinct is that i doubt
anyone is exercising the right to suppress now
... but that the option is in there for reasons no one
remembers
markw: your way is editorially simpler
joesteele: Joe Steele,
Adobe
... if we handle the second part of this, and remove that
text
... would it then make more of a difference?
... would firing the event be more relevant to authors?
... it would be redundant, you'll get a message in every case
where you're still waiting for a key, presumably
markw: if you have this separate
event
... it's clearer, "waiting-for-key" if you're still waiting for
key
... attaching semantics "can't-start-playback" would be
wrong
joesteele: we have consensus: always send message
jdsmith: which is what ddorwin proposed
[ paulc reads the github proposed comment ]
markw: if we can resume playback,
is there some other message that fires?
... you might be getting a different key than the one you
need
paulc: is this orthogonal?
markw: related
joesteele: i think you're saying "not receiving waiting-for-key doesn't mean you have a key?"
markw: you always receive
waiting-for-key if you're waiting for a key
... but do you get something explicit saying that playback will
go?
joesteele: you'll get a key-status-change saying that something might happen
markw: when playback-resumes does an event fire?
Josh_Soref: i'm sure there is
paulc: ok, so we're done w/ that one
<joesteele> https://github.com/w3c/encrypted-media/issues/100
paulc: markw you responded w/in
2/3 days
... ddorwin said this was related to ISSUE-98
... (a) + (b)
... others should look at markw's response
markw: resource-fetch in
html-media is hard to hook into
... it doesn't have extension points
... one thing i was surprised by, when looking at the text we
have
... if you run into an encrypted block and we don't have the
key, you're supposed to block downloading media data
... until you get the key
... i doubt that implementations would do that
paulc: they'll buffer and attempt to resolve key problem in parallel
markw: you don't need to decrypt
to resolve time points
... encryption isn't a big problem
... this isn't how our spec describes things
... but that's a separate issue
... we're monkey-patching
... "writing requirements that get inserted into another
specification"
... recommended good design pattern is to provide extension
points
... those hooks warn people that "dragons might happen
here"
paulc: anyone disagree w/ markw's proposal?
[ Silence ]
markw: the italicized text is
from the resource-fetch algorithm
... we'd suppress the state changes listed here in our
suspended state
... in an ideal world we'd have someone working on adding those
extension points
paulc: there was a pointer to a
bug in the whatwg spec to supply functionality in preload
yesterday
... not 100% useful since our normative reference is to w3c's
version
jdsmith: no one here disagrees
that this is a problem
... some change is necessary
<joesteele> action joesteele to ask Adobe developers about issue-98
<trackbot> Created ACTION-104 - Ask adobe developers about issue-98 [on Joe Steele - due 2015-11-06].
jdsmith: weird to stop in the middle of an algorithm
paulc: who's creating the pull request?
markw: need to see if ddorwin
agrees
... ideally we'd change things more substantially
... so encrypted block handling isn't in fetch, but somewhere
further down the line
<paulc> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27067
paulc: there's a proposal
... joesteele agrees
jdsmith: i agree as well
rus: proposal is by cpearce
[ paulc reads cpearce's proposal ]
jdsmith: ddorwin restated the
changes in his subsequent post
... more of a proposed implementation
rus: what i see that's missing
from ddorwin's proposal
... in FF they state they fire an error message at the
end
... i don't see that from ddorwin 's proposal
... no very specific way of saying "there was an error", "how
do you propagate the error?"
joesteele: i think there should
be an error
... oh, he says methods, not promises
... good point
Josh_Soref: this is for debugability?
rus: debugability and also troubleshooting
<joesteele> I believe an example of the text ddorwin is referring to is https://w3c.github.io/encrypted-media/#createMediaKeys section 2.10
joesteele: i think ddorwin misunderstood what i was saying
<inserted> https://github.com/w3c/encrypted-media/issues/112
joesteele: ddorwin says it's not
generally possible to determine if you have the wrong key
... not what i'm talking about
... does it make sense, when we had decrypted some content, and
now we're failing
... that's different from never decrypted content, and we're
failing
... in my CDM those are two different error conditions
... my response to ddorwin
... he seems to imply that have-nothing means that you have no
data
... you could have no encrypted data
... he's mapping the unencrypted data algorithm down
paulc: he's trying to refer to MSE's alg
joesteele: he's ...
... i'm giving a reason for handling one of the cases extra
specially
... i agree w/ his point that we should handle one case
paulc: could we make it a separate issue?
joesteele: make it such that it
won't be done
... but i don't feel strongly on it
... i think we could make the other thing a separate
issue
... "as an enhancement, we can split this error case out"
... to improve debugging
<inserted> https://github.com/w3c/encrypted-media/issues/118
MarkVickers: i replied to
this
... I agree w/ your comment about source, it's a detail of
content protection DRM
... but if you have a web browser on the other end, a TV
receiving the content
... and you have a app running there
... need to do two things, (1) as EME do...
... and (2) do you support media type and details
... alternative is horrible
... make up mime type and media type and other link content
protection
... DTCPIP+ etc.
... although yes, a lot of machinery you're not using, passing
keys, etc
... the machinery you're using is the only way to do it, via
EME
... as a practical issue, one could say "that's a separate
API"
... but as a practical matter, there will be 0 or 1 content
protection APIs
markw: how does a browser on the
other end identify DTCPIP content?
... file extension? what?
MarkVickers: i'd have to look
[ Break until 10:30 am ]
<paulc> ddorwin: Are you joining the teleconference?
paulc: i'd like to move on
<ddorwin> working on it
paulc: do we need to do
more?
... there was a sessions you, markw, ran yesterday?
... slides?
markw: the slides will be public when i put them up
MarkVickers: i sent boblund
... a link
paulc: when we deprecated support of EME on insecure contexts
<markw> Mark will respond to https://lists.w3.org/Archives/Public/public-html-media/2015Oct/0070.html with results of the TP session https://www.w3.org/wiki/TPAC2015/SessionIdeas#Secure_communication_with_local_network_devices
paulc: there was no support for
pages to connect to insecure devices
... we discussed second screen UCs at a meeting
... before we didn't know of a way for apps to do stuff w/o a
fix
... but since it was raised that there's at least one option
that could work today, we have something we can experiment
with
MarkVickers: and we've raised this to #webappsec (mkwst)
ddorwin: i'm on irc, and catching up on notes in github
<paulc> https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME
paulc: yesterday, Matt got the
best results from being on mute when not speaking
... we've disconnected the cisco system from the room
bridge
... Josh_Soref will be here until 11am (15mins)
... i've asked plh to give us an update on Charter
... before we turn into a pumpkin tomorrow
plh: on that, nothing
... update...
... we could at least extend the HTML WG
... but, we'd have an HTML WG that doesn't work on HTML
... nice aspect is that you guys keep doing what you're
doing
... and no question about patent commitments, they carry
over
... obviously i'd have to talk to Directors as well
... maybe we can change the name of the group w/o a full AC
Review
... one proposal, strongest so far, is to extend HTMLWG for the
purpose of the Media TF until June 30
... I think that's the bottom line proposal
paulc: ddorwin, if you look at
the agenda, we spent the first 90 mins on topic 1
... let's do topic 3
... we have one formal objection against EME
paulc: we don't have to do
anything about EME-1 yet
... we have to do it before LC-CR
... under Process 2014
<inserted> EME-1
paulc: "This formal objection
will be handled no later than when EME progresses to
LC/CR."
... ddorwin, don't bother moving it to github
ddorwin: +1
paulc: our issue-85 / tag issue-73
paulc: i don't think there are
any updates, and i've been pushing Travis regularly
... I don't think anything else until TAG does something
paulc: I think jdsmith said he'd look
paulc: I remembered the discussion
<paulc> https://lists.w3.org/Archives/Public/public-html-media/2015Oct/0020.html
paulc: jdsmith you asked during
the meeting whether the second message
... in the last agenda, and i said, "well yeah", "it's a direct
reply"
jdsmith: it's in my todo queue
<joesteele> action jdsmith to process the EME initData correlation issue
<trackbot> Created ACTION-105 - Process the eme initdata correlation issue [on Jerry Smith - due 2015-11-06].
paulc: i characterized this
... a set of issues, you sent me a private email saying it'd be
good to have feedback on a query
... i took out the issues 80..84 as you suggested
... our results are in github and irc
... how would you like to process these?
... i think i met your request to get F2F processing
ddorwin: those were the ones w/o
clear direction
... you've got feedback
... i've marked some as needs-implementation
... that's good
paulc: thanks ddorwin on the
background work, and coaching me on maximum to declare victory
and progress
... markw and MarkVickers, on ISSUE-118, is the ball in your
court, MarkVickers ?
MarkVickers: yes
ddorwin: on ISSUE-118
markw: i'll send you the spec
<joesteele> http://www.dtcp.com/specifications.aspx
ddorwin: is it link-layer, or does communication come through the app?
MarkVickers: it's
link-layer
... the notion is, could this link-layer be supported w/o
change
... by only using EME that identifies part that determine
encryption-system, and media-support
... w/o this, you have to use some combination of
link-protection scheme + media type format
<ddorwin> Previous discussions on OOB: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615
MarkVickers: and come up w/ some
mime type that supports both
... that's the only part of EME that would be used
... there's never a Key, since it's link protection between two
endpoints
<ddorwin> What was described is *not* EME. That's no more EME than HTML-CE is HTML.
ddorwin: not really EME
... there's no interop story
... i brought up a link to previous discussions
... i don't think it makes sense to fork EME
... maybe it's a use of requestMediaKeySystemAccess
<joesteele> scribe: joesteele
paulc: where is the information?
MarkVickers: its in IRC
... I am not interested in forking EME, but I think we can
agree that when we get done with the process we will either
have 0 or 1 Content Protection APIs in W3C.
... its a question of using the identification system in EME —
don’t think this is cinompatible
markw: this depends how you
identify the DTCP-IP content
... the only reaone you would need this is that the ability of
the devic eto protect content will vayr based on whether it can
handle this type
... seems to me it would be an entirely different typ of
content
... I maight be wrong though — need to know more about how it
fits into the stack
MarkVickers: to flesh out a bit
more — an operator proivdes two options for getting content —
from the locao device using DTCP-IP, the other is from the
cloud using DRM protection s we have discussed
... the application is also written by the service provider, so
they know what options they have, but they don’t know what the
device looks like
... e.g. can this device support DTCP-IP? and can it decode
this format?
... in which case it would come from the cloud
markw: the right way to do that might be to have a mime-type — there is no unprotedcted DTCP-IP content
MarkVickers: binding to a
mime-type means that there are multiple variants on multiples
axis which grows quickly
... we have 2 APIs that give a clean answer today
markw: there arent 2 sep
questions for DTCP-IP — it is a problem with the canPlayType
API — you have to call it multiple times
... requestMediaKeySystem is much better in that respect but if
that is the only aspect of it that you want it's not clear it's
appropriate
paulc: we know what next steps are —
MarkVickers: I took an action
jdsmith: I would like a very specific answer here eventually
paulc: 3 of these issues have had
progress since last meeting, excepting 112
... lets look at that and try to get an answer there
ddorwin: I already changed that
to “needs implementation”
... so all are in the same state now
paulc: Mark and I discussed this
morning — pull requests for 80-84
... we probably need more discussion on 87 to get traction on
the others (minus 84 which is orthogonal)
... let discuss issue 80 and its pull request
ddorwin: I answrred Marks questions — plan to handle the rest tomorrow — nothing really pending there now.
paulc: so Mark and David will
close on pull request 87 and once that is done Mark Watson can
make the cascading changes required out of that
... markw it would help if you sent a summary email once you
are done with step #1
markw: needs a rebae now and then will be easier to see
https://github.com/w3c/encrypted-media/issues/84
paulc: does not have a pull
request — still waiting for feedback from people — might be
able to just resolve this issue
... I think if no complaints before next week we may just close
this issue
jdsmith: I was thinking we should be more proactive — we can always re-open
paulc: any objection to closing now?
ddorwin: had some discussion today and thinking that is more relevant — we can close it for now though
paulc: not convinced this we have
concensus that this is a feature request
... we have been going around on this awhile
... should Joe talk about this?
joesteele: I will pass the mike to Mark on this first
https://github.com/w3c/encrypted-media/issues/41#issuecomment-152360391
markw: we have this idea at the
beginning that CDMs control the timing of messages. When this
message requirement of one was introduced not sure anyone
noticed.
... thinkg we all agree that we must have interoperability,
<ddorwin> There was no introduction of requiring a message. It has been there since the very first version!
markw: we are really talking here
about optimizations to cut down on the message exchanges —
optiomizations that are already deployed
... the way CDMs determine what mesages to send have not been
gone over in detail in this group
... that is one interpretation of the TAG review
... we can talk about whether that is a good thing — not sure
that is a good thing to discuss yet
... there are many things that a CDM could do — but we are not
yet at the place where we need to document this
<ddorwin> joesteele: Look at v0.1b
markw: for me it is not important
when it changes - it is the higher level principle that CDM
control the messages they sent
... maybe it did not occur to us at the beginning — but it was
not an agreed principle that there must be a message
exhange
<ddorwin> https://rawgit.com/w3c/encrypted-media/8f06759/encrypted-media.html#dom-generatekeyrequest
ddorwin: the claim that this was not in the spec is not true — this was in the first version
<ddorwin> ^ Very first version of the spec
ddorwin: this opens up things we
need to consider, maybe there are specific use cases we can
talk about
... figuring this out is going to take time
... and staying within the TAG requirements
... think we need to focus on all the other issues we should
focus on for v1
markw: its about the level of
scrutiny being applied here, always saying we need
interoperability, this feels like it is getting a higher level
of scrutiny
... I would be fine applying this level of scrutiny in v2 -
when it is not for others
paulc: and those other features alo impact key flow
ddorwin: we would have to
consider the impact because this impacts video format
... just because it is common encryption does not mean that it
is interoperable
... the content encryption being different would cause a
problem for other systems
... how you do renewal does not necessairly impact this
... it just happens that renewal is already within the
spec
... applying more scrutiny is fine — and might be the fastest
way to resolve htis
joesteele: the content encryption is exactly the same
ddorwin: we are not sure what you
are doing here, would like to here more
... especailly with regards to the key chaining
... don’t want to cause us problems now
... you can hide things but that is not necesarily good
markw: David you are saying you
want to have interoperability, Joe is saying this content would
be interoperable
... if we can produce text that crequires this — could we move
forward?
paulc: is ths issue that the text says a single message is mandatory?
joesteele: yes
ddorwin: but that does not let
you actually use the keys provided
... to Marks question yes — but think this changes core
assumptions and would be far reaching
... just like with secure release this would take a long
time
... would be fine to do this if we can guarantee
interoperability — but will delay a lot
markw: dont think this has to
delay us a lot — because I dont think we need the level of
detail you are implying
... you are making assumptions we do not know what they
are
... if the CDM wants to do lots of key related operations as
long as the app behavior is clear and according to the spec,
should be fine and does not change things significantly
... would be tractable to come up with something that requires
interop
ddorwin: the spec is very clear on what the CDM can do with the initData — we would run afoul of the TAG discussion otherwise
paulc: we have an active thread —
lots of discussion going on
... as the chair I may have to ask who believes that the
initial messgae is mandatory, but who can live with the spec
like that
... we disagree on how long it will take to change
... we will have to trade-off getting features in and finish
v1
markw: I want to clarify one point of difference — you can implement the CDM to do anythngin it wants with the initData as long as it conforms to the specification
paulc: that is pretty standard spec behavior
— as long as you are not breaking the spec conformance
paulc: how many of these optimizations impact the visible perfomance?
ddorwin: think this break interoperability — citing HTML example
paulc: disgree with this — look at the conformance clause there.
markw: think we are in agreement
on interoperability
... any CDM should be able to process any compliant media —
that does not breka interoperability
joesteele: I believe that nothing in my proposal implies that the content would be non-interoperable and the process I mentioned for determining when a key is available is actually more interoperable across browsers than waiting for a message
https://github.com/w3c/encrypted-media/issues/19
jdsmith: I am not assigned to
this, but I have an action to comment
... about sequencing of events and promise resolutions
... I am concerned that simply delaying events is not good API
design
... comment from Joey
<paulc> https://github.com/w3c/encrypted-media/issues/19#issuecomment-126759849
jdsmith: I was suggesting we
consider reviewing — he is stating renewal message are sent by
events — I added a comment that speciyfing events are not fired
until promises are resolved is good
... this gives clarity — want event to return only after the
promise is resolved
<paulc> https://github.com/w3c/encrypted-media/issues/19#issue-54946877
ddorwin: guaranteeing the order
is quite complex ... need to parse my notes on this
... need to spend time on this
action ddorwin to propose soluiton for issue-19
<trackbot> Created ACTION-106 - Propose soluiton for issue-19 [on David Dorwin - due 2015-11-06].
paulc: David will get to issue-19
as soon as he can
... he believes this fix is mandatory for v1
rus: one thing we can do in bubbling up the errors is having systemCodes — so we know what is really going on
paulc: we had that 19 blocks 14 and 31
ddorwin: still believe that is
true
... believe this will change the algorithms
... don’t want both changes to happen at the same time
<paulc> https://github.com/w3c/encrypted-media/issues/31#issuecomment-152273712
https://github.com/w3c/encrypted-media/issues/59
ddorwin: was assigned to me and
progress has been made on the HTML spec which will let me make
progress on this. New WebIDL spec will define time
... the primary Web IDL spec will remove date
... I expect there to be progress there and I will ping it —
this is blocked on Web IDL — we know what the intended
behavior
... just monitoring
paulc: isn’t this a breaking interop problem?
ddorwin: we removed the use of
Date but they had not removed Date. Boris said — yes we are
really removing Date. He was supposed to send a patch.
... I will definie a new bug that says you should define Time
as a concept
<paulc> https://github.com/w3c/encrypted-media/issues/59#issuecomment-151220498
paulc: in this comment, you point to a hash IDL Date in another github — that is the current one?
ddorwin: it is in both version and the TR — might get removed from the TR dont know
<Travis_> Note that DOM's Event interface defines its timestamp as: https://heycam.github.io/webidl/#common-domtimestamp
paulc: so you know what needs to happen here
ddorwin: yes
<Travis_> Yet, that domtimestamp is not actually defined :-(
plh: are you aware of the hires stamp?
<plh> http://w3c.github.io/hr-time/
travis_: this sounded familiar —
went to the DOM spec and the type for the timestamp links to
Web IDL and there is no definition in Web IDL
... you would probably be safe using that same link
... to answer PLH comment about highres timestamp — think they
may need something different here. that would not be comparable
because you need to compare the times and the hr-time time
origin wouldn't work
ddorwin: would be great if Travis could update issue-59 with what he said
<ddorwin> https://github.com/w3c/encrypted-media/issues/59
https://github.com/w3c/encrypted-media/issues/75
paulc: where are we on this?
ddorwin: this is another
dependency on Web IDL
... there is an outstanding thread on script-coord — we need
them to figure out how iterable works. As defined it is buggy
and not useful
<ddorwin> ^... in certain uses
Travis_: looks like this issue is
being actively discussed and some movement on the Web IDL
github issue
... sounds like the behavior will match the Array ForEeach
syntax — if folks care
ddorwin: Cameron replied this morning but have not read yet
<paulc> see https://lists.w3.org/Archives/Public/public-script-coord/2015OctDec/0039.html
paulc: in active motion so lets go on
https://github.com/w3c/encrypted-media/issues/101
ddorwin: think this needs author input and followup a bit
<paulc> see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269
ddorwin: there are two of these
bugs now — some ambiguity now
... trying to figure out how to scribe the issues with
Distinctive Identifier — coming soon
... this will be in issue 117 — should be up next week
paulc: this is one that is currently “needs implementation”?
ddorwin: it needs followup
... its assigned to me — I need to fill in the description
<paulc> https://github.com/w3c/encrypted-media/issues/117 should be updated with better desc
https://github.com/w3c/encrypted-media/issues/105
paulc: this blocks 104 and 106
ddorwin: also a Buggzilla bug —
has been low priority
... it is now blcoking the MPEG-2 stuff as well as the registry
— need to take some time to restructure
... proposed structure is there — needs feedback from the
group
paulc: who will sign up to
provide feedback?
... plh can you express an opinion?
plh: I will provide personal comments on this
paulc: PLH resolved these this week and they need implementation now
plh: I did an analysis of the references in the spec and opened another bug
https://github.com/w3c/encrypted-media/issues/107, https://github.com/w3c/encrypted-media/issues/108
paulc: believe we have covered this
https://github.com/w3c/encrypted-media/issues/68
https://github.com/w3c/encrypted-media/issues/98
https://github.com/w3c/encrypted-media/issues/101
https://github.com/w3c/encrypted-media/issues/102
s/: https://github.com/w3c/encrypted-media/issues/101/: https://github.com/w3c/encrypted-media/issues/100/
paulc: these were processed earlier
https://github.com/w3c/encrypted-media/issues/99
paulc: marked as needs implementation now
jdsmith: the comment was the
action
... I commented on whether it was acceptable
... ready for implementation
https://github.com/w3c/encrypted-media/issues/110
paulc: David you pointed out this is related to 117
ddorwin: the description I am
creating will point out why this is difficult
... changing the definition will change this — so this may not
make sense in the end
paulc: so 110 is blocked by this work on 117
paulc: David converted the bulk
of these to github issues
... recommended leaving the formal objection bug in Bugzilla
for now
markw: I just moved the systemCode bug
paulc: some private discussion going on with Jerry to resolved before even moving right?
jdsmith: yes
paulc: would be useful to send a link to the group about the status
ddorwin: folks should be getting messages as these are moved — but not necessarily for each one
jdsmith: they should get a disposition message is they are closed
paulc: may end up with just one
bug left in Bugzilla (to preserve the old links)
... suggest the editors continue as they have been doing
https://github.com/w3c/encrypted-media/labels/needs%20implementation
paulc: 24 ready to be implemented
joesteele: if we do something that TAG did not approve of — what is the impact?
paulc: would suggest we go back to the TAG and discuss anything that we consider “not appropriate” for EME.
paulc: would it be useful to get back together on Nov 17th?
ddorwin: I think github has worked really well — if we have stuff we need to discuss we can, but bring up things there.
paulc: I will try to craft an
agenda even earlier than normal
... would like to point out the huge amount of work David has
done in getting things done and providing suggestions on how to
handle things
ddorwin: I will be out of time on the 17th
paulc: next week is 24th and
Thankgiving in the US — don’t want to skip a whole month
... would be useful if maybe we can work something out
ddorwin: yes Matt and I are both going to the same thing — we will try to do as much as possible offline
paulc: any other business?
<giuseppe> draft minutes
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s|topci: ISSUE-68|| Succeeded: s/concensus/consensus/ Succeeded: s/… /... /G Succeeded: s/present +/present+ / Succeeded: s/Topic: ISSUE-68// Succeeded: s|https://github.com/w3c/encrypted-media/issues/68|http://github.com/w3c/encrypted-media/issues/68| Succeeded: s|https://github.com/w3c/encrypted-media/issues/68|| Succeeded: s|http://github.com/w3c/encrypted-media/issues/68|https://github.com/w3c/encrypted-media/issues/68| Succeeded: s/MarkVickers/markw/ Succeeded: s/paulc_/paulc/G Succeeded: s/action for markw to ask his developers about issue-98// Succeeded: s/text/pending comment/ Succeeded: s/l/l?/ Succeeded: i|generally|https://github.com/w3c/encrypted-media/issues/112 Succeeded: s/optimization/enhancement/ Succeeded: s/this/this error case/ Succeeded: s/topic: ISSUE/topic: ISSUE/ Succeeded: i|rep|https://github.com/w3c/encrypted-media/issues/118 Succeeded: s/paulc/markw/ Succeeded: i/www/Topic: Meeting Logistics Succeeded: s/that there's a workaround/that there's at least one option that could work today, we have something we can experiment with/ Succeeded: s|rrsagent, drat minutes|| Succeeded: i|formal|-> http://dev.w3.org/html5/status/formal-objection-status.html#EME-1 EME-1 Succeeded: s/on Wed/yesterday/ Succeeded: s/../.../ Succeeded: s/-layer/-system/ Succeeded: s/requestMediaKeySystem is much better in that respect/requestMediaKeySystem is much better in that respect but if that is the only aspect of it that you want it's not clear it's appropriate/ Succeeded: s/thinkg/thinking/ Succeeded: s/no convinced/not convinced/ Succeeded: s/makrw/markw/ Succeeded: s/thi gives/this gives/ Succeeded: s/remove data/remove date/ Succeeded: s/the are/are/ Succeeded: s/update issue-19/update issue-59/ Succeeded: s/comparable/comparable because you need to compare the times and the hr-time time origin wouldn't work/ Succeeded: s/folks cares/folks care/ Succeeded: s/rpelied/replied/ WARNING: Bad s/// command: s/: https://github.com/w3c/encrypted-media/issues/101/: https://github.com/w3c/encrypted-media/issues/100/ Succeeded: s/bulkd/bulk/ Succeeded: s/ISSUE-59 (David}/ISSUE-59 |expiration| should be Unix time like Date()/ Found Scribe: timeless Inferring ScribeNick: timeless Found Scribe: joesteele Inferring ScribeNick: joesteele Scribes: timeless, joesteele ScribeNicks: timeless, joesteele Present: Tatsuya_Igarashi paulc markw rus Josh_Soref joesteele MarkVickers toddg Yves Yosuke ddorwin plh Agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME Got date from IRC log name: 30 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/30-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]