actions

<kaz> action-22?

<trackbot> action-22 -- Daniel Davis to And kaz to add a column to the mapping table to measure the progress of our specification. -- due 2015-01-27 -- OPEN

<trackbot> http://www.w3.org/community/tvapi/track/actions/22

<kaz> close action-22

<trackbot> Closed action-22.

<cpn> Scribe: Chris

<kaz> scribenick: cpn

Progress measurement of the draft of technical specification

<ddavis> https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping -> Requirements Mapping table

<Paul_Higgs> cannot hear daniel

<ddavis> :-(

Daniel: The draft API is largely the same as the Mozilla TV API
... one difference regards the tuner notifications, which were supported in a previous version, but not in the current draft
... Under general program requirements, we have program data detail, there's a comment saying the requirement is unclear

<Paul_Higgs> "[program.data.detail] Other detailed information of the channel/program with TV stream. "

Bin: My understanding is this could be a general object allowing for other information, which could be extended by the implementation

Daniel: In terms of progress, we have some requirements supported and some not
... Some sections are blank, such as time shifting and recording
... Should we focus on completing the partially supported sections first?

Bin: Who has a plan to work on the partially supported/unsupported sections?

Paul: For the specific APIs just mentioned, should we pass our requirements to the Media Stream recording API?

<inserted> Media Capture and Streams

Bin: So we should do a gap analysis on the Media Stream Recording API to see how well it supports our requirements

Paul: The requirement for series recording implies there's a cron-type scheduler running

Alex: This is meant to allow recording of an entire series containing an episode. This could be done through the EPG

Paul: I think it could be done within the API or it could be at the application-level
... the requirement implies we can give an identifier to the system e.g., a TV-Anytime series id and have it automatically record

Alex: I would prefer to see this at the application level

Paul: In that case we could remove the recording.series requirement
... Could we modify the requirement, to split it between application and system level

<inserted> scribenick: ddavis

cpn: If one of our feature goals is feature parity with OIPF then that's where it's come from.
... If we can make it from the application layer that would be good.
... Complete but minimal would be good in my API - we don't need to bake all these features into the API itself.

<inserted> scribenick: cpn

Bin: I suggest asking this question on the mailing list, and take a decision on this requirement on the next call

<scribe> ACTION: Alex to email the mailing list regarding the recording.series requirement and proposed solutions [recorded in http://www.w3.org/2015/02/17-tvapi-minutes.html#action01]

<trackbot> Created ACTION-23 - Email the mailing list regarding the recording.series requirement and proposed solutions [on Alexander Futász - due 2015-02-24].

<scribe> ACTION: Paul to look at the Media Capture and Streams API and compare against our recording and timeshifting requirements [recorded in http://www.w3.org/2015/02/17-tvapi-minutes.html#action02]

<trackbot> Created ACTION-24 - Look at the media capture and streams api and compare against our recording and timeshifting requirements [on Paul Higgs - due 2015-02-24].

<kaz> action-24 due march 10

<trackbot> Set action-24 Look at the media capture and streams api and compare against our recording and timeshifting requirements due date to 2015-03-10.

Paul: It may be that the time shifting requirements could be handled by the HTML video element
... I'll just look at the recording aspect, and leave timeshifting for now

<kaz> action-24 due april 14

<trackbot> Set action-24 Look at the media capture and streams api and compare against our recording and timeshifting requirements due date to 2015-04-14.

<scribe> ACTION: Chris to look at the timeshifting requirements and the HTML video element [recorded in http://www.w3.org/2015/02/17-tvapi-minutes.html#action03]

<trackbot> Created ACTION-25 - Look at the timeshifting requirements and the html video element [on Chris Needham - due 2015-02-24].

<kaz> action-25 due march 17

<trackbot> Set action-25 Look at the timeshifting requirements and the html video element due date to 2015-03-17.

Bin: Regarding the emergency alert requirements, are these supported?

Daniel: There's an isEmergency flag on the Channel object

Alex: The API doesn't cover the notification requirement we have

Paul: The channel emergency flag likely means the user can't tune to the channel
... There are different ways of handling alerts in different countries

Bin: In the Mozilla case, the end user can't choose the emergency channel, but whenever content is available there it should be surfaced to the user

Paul: This requires a dedicated tuner, in case something appears

Bin: So the emergency alert is only partially supported

<kaz> emergency requirements

Kaz: The Web Signage group has created a requirements document on emergency use cases

Sung-Hei: This work isn't active at the moment. For major emergencies we would use the whole signage system

<Paul_Higgs> in the US: https://www.fema.gov/emergency-alert-system

Bin: We should revise the specification

<scribe> ACTION: Bin to contact Sean and add emergency alert requirements to the spec [recorded in http://www.w3.org/2015/02/17-tvapi-minutes.html#action04]

<trackbot> Created ACTION-26 - Contact sean and add emergency alert requirements to the spec [on Bin Hu - due 2015-02-24].

Kaz: We should also consider if we need a server push mechanism, because in that case we need to think about security as well

Bin: The Web Apps group has defined a server push API

<ddavis> http://www.w3.org/TR/push-api/ -> Push API

Paul: We'll need to see whether an IP based emergency notification is permitted

Bin: I think the focus for us is to surface the notifications from the platform. We're not defining the entire alerting platform here
... Each country has its own regulations for emergency systems

Paul: So we define how to surface the notifications to the application layer, but not specify how even should be handled at that level

Bin: Yes, i agree
... Next requirement to look at is the Conditional Access System

Daniel: This is unsupported at present. Should we leave these and come back to them later?

Bin: If we don't have anyone to work on these, they can be left, possibly for a future revision of the API

<kaz> ACTION: bin to work on triggered interactive overlay requirements [recorded in http://www.w3.org/2015/02/17-tvapi-minutes.html#action05]

<trackbot> Created ACTION-27 - Work on triggered interactive overlay requirements [on Bin Hu - due 2015-02-24].

Bin: We should aim to complete the API requirements by June. Then we can decide whether to defer anything remaining to a future revision

Kaz: Is there a face to face meeting of the TV API CG planned?

Bin: I would only be able to attend if its in the Bay Area
... we could have our next meeting colocated with the next Web and TV group meeting

Kaz: I'll let the group know when we have more details

<Paul_Higgs> sorry - have to drop off

<kaz> [ adjourned ]