W3C home > Mailing lists > Public > public-html-media@w3.org > June 2012

RE: {minutes} HTML WG media telecon 2012-06-12 - roll call, admin, baseline documents, encrypted media issues

From: Adrian Bateman <adrianba@microsoft.com>
Date: Tue, 12 Jun 2012 16:10:28 +0000
To: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-wg-announce@w3.org" <public-html-wg-announce@w3.org>
CC: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <8D8FE6C1B27E6645848ABEC8355A39BD0629F49C@CH1PRD0310MB391.namprd03.prod.outlook.com>
Minutes -> http://www.w3.org/2012/06/12-html-media-minutes.html


HTML Media Teleconference

12 Jun 2012


See also: IRC log


  +1.818.560.aaaa, +1.303.503.aabb, +1.760.533.aacc, paulc, adrianba, +1.408.393.aadd, ddorwin, Yang, Mike, +1.858.485.aaff, Plh
  Paul Cotton
  Adrian Bateman

1.Roll call, introductions and selection of scribe
2.Administrative items
3.Baseline documents and Bugzilla information
4.Candidate Encrypted Media Extensions bugs for discussion

Summary of Action Items


Roll call, introductions and selection of scribe

paulc: i'm one of the co-chairs of the WG and you should treat me as the faciliator and chair of this meeting
 ... don't want to spend a lot of time on introductions
 ... we chose this meeting slot through a poll
 ... at the f2f meeting in may there was a suggestion that we alternate topics for this slot
 ... i arbitrarily chose the oldest proposal for this week
 ... i propose media source next week and then alternate
 ... we did this because some people were interested in one proposal and not the other
 ... any comments?

<Petr> alternating is fine

paulc: the agenda will make it clear which topic is which

petr: as long as the agenda is clear that sounds fine

paulc: if we need to give one document more attention than the other we can consider that
 ... if anyone thinks we're not making enough progress please contact me or the w3c team

Administrative itemsn

paulc: because this is a sub-team of the HTML WG, when we set-up the tracker to track actions it can't map to the whole WG
 ... so people who need to be in the tracker need to let MikeSmith know they need to be added
 ... i sent a mail about this today

<paulc> See  http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0062.html

paulc: Mike responded with information about who was already subscribed including the editors
 ... anyone else who plans to be active and wants to accept action items should let Mike know

mark_vickers: perhaps you could describe the action items? editing or non-editing items?

paulc: not expecting to take actions about specific edits
 ... i expect actions about starting a discussion or updating bugzilla for example
 ... i want to keep editing lightweight
 ... if editors want to self-determine some way of dividing work we can have another tracker if needed

acolwell: what is the difference between tracker and bugzilla?

paulc: there's also the email list
 ... when people want to identify a problem they have two choices: open an email dialogue on the public list and ask "is the following a problem"
 ... you might not be convinced you understand the spec and that it's wrong
 ... once you're convinced there is a bug, use bugzilla to file a bug against the bug - each spec has a separate bugzilla component
 ... the connection between bugzilla and the mail list is the same as the HTML5 spec
 ... bugzilla sends email only for new bugs (not for subsequent updates)
 ... we did that because specs that have a large number of bugs with lots of updates would flood the mailing list with updates
 ... once someone has created the bugzilla entry - you can have a dialogue in the bug or on the mail list - there isn't a fixed rule about the most appropriate place
 ... when you proposed detailed text or discussion about A or B then i think that's better in the mailing list
 ... some people like bugzilla and others like the mailing list
 ... when you see a new bug, you can click on the link and add yourself to the CC list so that you get all the mails with updates
 ... one of the reasons we chose this approach is that if you see a new bug (and there was one this morning - here's an example)

<paulc> new bug:  http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0061.html

yang: if someone comments in the bug will the reporter receive an email?

paulc: yes

<MikeSmith> Yang, if you type "q+" when you want to want to ask a question, the chair will see that and respond

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

<Yang> got it,mike,sorry for disturb...

paulc: when you create a bugzilla bug you automatically get added to the CC line
 ... third item is tracker
 ... we use this to track issues and action items
 ... tracker will look in the email archive for when the issue or action is mentioned
 ... i'm not anticipating that we'll need many issues early on
 ... i propose that we use the mailing list and bugzilla to drive the meetings and ask the editors to update the specs to reflect consensus
 ... i believe in giving the editors leeway to express that consensus
 ... and then we can see if we need to open new bugs
 ... or if we need some form of escalation
 ... for now i'm not too worried about that
 ... i want us to work with a sense of consensus

yang: can you give me a URL to the tracker?

<MikeSmith> Yang, paulc, https://www.w3.org/html/wg/media/track/

acolwell: the tracker is mostly around the issues and actions related to the call and bugs/mailing list for the specific detail?

paulc: i'm a firm believer in using actions to drive results when people take actions

Baseline documents and Bugzilla information

paulc: in the agenda i identified the starting editor's drafts and outstanding bugs
 ... i wanted to get to agenda #4 and david created a list of important bugs to consider

suzie: wondering if i can create a new bug through the mailing list?

paulc: there is no way to do this from the mailing list - if you can't use Bugzilla for some reason then one of the editors or me or the team will help

suzie: my previous understanding is that whenever i want to bring up a new topic i need to start from the email and it would be captured in bugzilla?

paulc: you could discuss first on the mailing list but that's not mandatory - you could just use bugzilla and create a bug right away (which will generate a message to the list)
 ... people could respond on the list but will probably respond in the bug

yang: who decides which bugs will be on the agenda?

paulc: i made the decision in cooperation with the editors for this call
 ... you could do that either by replying to the agenda but you could also send mail to me privately asking about priority
 ... i will encourage you to do that on the public list but if you feel uncomforable with that please reach out to me

Candidate Encrypted Media Extensions bugs for discussion

paulc: i think you identified the most important bugs including one that has lots of dependencies

<ddorwin> bug 16613

ddorwin: correct

bug 16613?

<paulc> Bug 16613:  http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0054.html

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

paulc: i think david and the editors would like feedback on this bug

ddorwin: the general idea (media source also investigating this) - we have a bunch of methods and events on the media element
 ... it's suggested that we could hang them on a new object - or represent them as new session

<ddorwin> example:  http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-oo-api-design

ddorwin: there is an example in the proposal of what this might look like
 ... we're looking to get some feedback on this
 ... i've listed some advantages and disadvantages
 ... are there general questions or comments?
 ... i was unclear of what glenn was suggesting - session id seems to handle this
 ... we're open to other options - this is the one we came up with

yang: i reviewed the example interface description for the mediakeymessageevent

<Yang> why we specify uint8array for message type

yang: there is Uint8Array key
 ... why did we specifiy that type for the message

ddorwin: the example is using the same approach as the rest of the proposal - we should discuss this separately but briefly this is a binary message
 ... this is relatively new but is used in some other specs

<Yang> eventinit

yang: why do we have the mediakeyeventinit for every event?

ddorwin: this is also orthogonal

adrianba: if you look at the dom4 spec in webapps, you see events being described in this new way

paulc: yang, i suggest you send these general questions to the list

markw: an opinion on making this more object oriented

<ddorwin> correcting myself, I think the EventInit was based on the <track> spec, not Media Source

markw: although this would make some of the simpler examples more complex
 ... it would make the overall situation more understandable
 ... and i think this is better if the code is easier even if they have to write a bit more
 ... so i think they key issue is whether this is significantly harder for implementations
 ... if people prototyping say it is okay for implementations then we should consider it

<paulc> What is your opinion on the example here:  http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-oo-api-design

paulc: i want to make sure people realise the example david provided earlier could be the start of a good discussion
 ... people could respond to this question on the list, either saying they prefer the current definition or moving to the new example

mc: if we move to the session object if we have async events that fire on the object how do you relate this back to the original element to which it pertains

ddorwin: i guess the event would need to have a property for the element
 ... that's good feedback
 ... could you make this comment on this list?

acolwell: i have a process question - media source has a similar bug - should we add the proposal to the spec or add it into the bug

adrianba: my proposal is to make suggestions in the bug and when there is consensus update the spec

acolwell: there is a similar bug for media-source that is asking the same question
 ... we need to decide that before addressing other bugs because it directly effects them all

<ddorwin> Answering acolwell's question, the proposal is only in the draft proposal because we listed known open issues when we published it. I would not do this moving forward.

paulc: i expect what happens after this meeting is that we have active participation by people on this call and on the list
 ... i suggest we pick another topic and use that to seed some more discussion

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

ddorwin: let's go to heartbeat

<paulc>  http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0058.html

ddorwin: the general goal of the proposal that it supports multiple drms and one requirement is heartbeat
 ... there are a couple of ways to deal with this described in the mail

paulc: so far people are choosing option #1 - could you say why someone might prefer option #2

ddorwin: basically from a consistency point of view - a heartbeat response is similar to a license and so the pattern would be the same as the other parts
 ... but there is a significant overhead especially if we go with the object oriented approach
 ... so the key question is does anyone object to option #1

yang: i support option #1
 ... when the UA sends a key message to the server and the server responds you can use this for keepalive

<paulc> second comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16738#c2

yang: why would addKey be called - wouldn't this be the server doing the work

<markw> yes, who provides the ack ?

<Yang> who provide ack, ua or server?

<markw> the server provides the ack and the script receives this and provides it to the UA using the addKey() method

ddorwin: the server replies to the application with the ack which then calls addKey() to pass this to the UA

<Yang> got it

ddorwin: i will respond to the questions in the bug - it was updated overnight

<Yang> I prefer option1

paulc: we're hearing support for option #1 - the operative question is whether anyone strongly supports option #2 and couldn't live with option #1
 ... we should deal with this in email - i'll let the discussion go on and then before the next meeting ask if anyone objects to option #1

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

<ddorwin>  http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0059.html

ddorwin: not lightweight - i'd like people to discuss this but we won't have time today - it's key release
 ... somewhat orthogonal to the rest of the spec because it's not attached to the media element
 ... would be good to have feedback from content providers
 ... i know markw has some thoughts
 ... would be good to get some feedback on this topic

paulc: this is good for a first meeting - please reach out to me privately if you have any difficulty working out how to enage in this group
 ... i want to encourage discussion on the mailing list
 ... second item we discussed is a candidate for closing down quickly
 ... i think we want to focus the next meeting on the object oriented question
 ... i proposed at the beginning of the meeting that next week we discuss media sources - we'll do the same as for this week but there's no reason we can't get this going sooner on the list
 ... people are free to pick any of the bugs and start a mailing list thread
 ... i plan to chair again next week
 ... does anyone want to volunteer to scribe next week?
 ... don't hear anyone - we'll find someone
 ... any closing comments from anyone?
 ... i suggest you send minutes to html announce and html-media
 ... we are adjourned

Summary of Action Items
[End of minutes]

From: Paul Cotton [mailto:Paul.Cotton@microsoft.com] 
Sent: Friday, June 8, 2012 7:13 AM
To: public-html-wg-announce@w3.org
Cc: public-html@w3.org; public-html-media@w3.org; public-html-a11y@w3.org
Subject: {agenda} HTML WG media telecon 2012-06-12 - roll call, admin, baseline documents, encrypted media issues

The HTML WG media teleconference meeting will occur on 2012-06-12 for up to 60 minutes from 15:00Z to 16:00Z.


Tokyo midnight, Amsterdam/Oslo 17:00, London/Dublin 16:00, New Jersey/York 11:00, Kansas City 10:00, Seattle/San Francisco 08:00.

Chair of the meeting: Paul Cotton
Scribe: TBD

(See the end of this email for dial-in and IRC info.)

== Agenda ==

1. Roll call, introductions and selection of scribe

2. Administrative items

3. Baseline documents and Bugzilla information

a) Encrypted Media Extensions editor's draft: 

b) Media Source Extensions editor's draft: 

c) Encrypted Media bugs: 

d) Media Source Extension bugs: 

4. Candidate Encrypted Media Extensions bugs for discussion 

We will discuss some of the P1 and P2 bugs on the Encrypted Median Extension proposal.

5. Other Business

6. Chair and Scribe for next meeting

7. Adjournment

== Dial-in and IRC Details ==

Zakim teleconference bridge:
   +1.617.761.6200, conference 63342 ("media")

Supplementary IRC chat (logged):
   #html-media on irc.w3.org port 6665 or port 80

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329
Received on Tuesday, 12 June 2012 16:12:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:22 UTC