TV Control API CG call

Review of draft WG charter

<inserted> Draft Charter

Francois: We're ready to send the charter to the AC for review
... There should be some comments from the accessibility team soon
... I'll let the group know when it's been sent to the AC
... The review has to last at least 4 weeks
... So won't end before beginning of March

Reviewing the phase 2 use cases

Phase 2 Use Cases

Bin: Thanks for the contributions to the second-phase work, from Opera, BBC

<kaz> UC-2 Security, and privacy requirements

Chris: First of all, with the security and privacy requirements. The concerns I have here is that the API allows Web application to gain access to the list of channels, list of programs and the list of scheduled recordings that the user may have made.
... This could be used for fingerprinting the user. There's an impact on privacy that we should think about.
... Another aspect on the list of recorded programs. We really want this to be under the control of the user but not under the control of any application that could go through the list and perhaps delete recordings.
... That's sensitive.
... There was also a comment from Sangwhan from Opera on similar topic, with a suggestion to integrate some form of permission model.
... Also, if multiple applications are fighting for access to the tuner, there is some potential to end un in a race condition to access the tuner.
... I don't have a particular solution in my mind for this yet, but something the group should discuss.
... The next topic I suggested is to add support for broadcast radio. There are some devices, especially mobile devices, that have built-in radio tuners, and it seems interesting to integrate radio in the API, given that there is a good similarity between TV and radio in terms of modelling.
... I included a link to the Mozilla FMRadio API.

<kaz> UC-3 Broadcast radio

Chris: I think Francois added this to the draft WG charter, which is good. It may require a more abstract set of interfaces, in particular as all of our interfaces start with "TV".
... The final thing that I suggested is interactive application signalling. This is something that we use in HbbTV to signal the presence of broadast-related interactive content.
... In this scenario, the broadcaster sends some XML along with the broadcast signal and the TV device relates that content with the presence of an application that it can then start.
... We have not tried to define any kind of application lifecycle in the TV Control API. We focused on the programs and on connecting to the audio/video sources, but if we think about the capabilities that HbbTV had, we may want to consider applications as well.
... One thing that I don't know is whether this should be addressed by this group.
... Open for discussions.
... The final topic comes from Sangwhan. It is about handling of non-TV "channels". For example, most TV sets will have external inputs such as HDMI or DVI inputs.
... The API would not be restricted to tuner anymore, but would also include any sort of input source.

<kaz> UC-1 Handling of non-TV "Channels"

Chris: That's a sort of summary for the phase 2 work.

Ryan: Guest from the Media Tuner from the Automotive BG.
... You were talking about the security aspects of the user.
... Some unique user ID with some agglomeration would be the most straightforward solution for us. Have you thought about that?

Chris: Do you have something like a draft spec that we could have a look at?

Ryan: Let me try to get to the root of that.

Chris: It would be very useful if you could share a link.
... This is much more at the application level.

Ryan: Usually, you want to know who the user is. In the case of automotive, there may be multiple persons in the car with some notion of sub-user associated with an account.
... We may be able to share our API and maybe add to it.
... Also, you were talking about TV/radio tuner comparison. We had started a similar work, but still looking for volunteers.
... Happy to help from the radio perspective.

Chris: Again, that's something we can take a look at.

Ryan: The use cases are pretty different, but it's true that there are a lot of similarities in terms of content.
... One of the big differences that I'm seeing is the fact that the vehicle will have multiple sources in it. In the front, in the back, etc. That was the area of use cases that is different. I don't know how that compares to TV.

Bin: Thanks for the comments. We're looking forward to working with your group by taking into account all these use cases that you have started to contribute.
... Any comment?

kaz: Thanks a lot for joining the TV API call, Ryan! We should talk about the automative use cases on the automotive group call as well, but maybe we could think the zones within a car as if those were separate rooms of a smart home

Bin: If there are no further comments, we can take a quick look at the automotive use cases
... and see how we can better align our cases

<RyanDavis> https://www.w3.org/community/autowebplatform/wiki/Main_Page/MediaTunerTaskForce

Ryan: The original uses cases are at the top, then there's a use case comparison
... It's still work in progress
... We want to pick this up, get some more people to help

<kaz> Use Case comparison table

Ryan: Looking at the use case comparison, we broke this down into system functions
... Streaming services API, tuner service API
... There's the unique user ID I mentioned earlier
... Which is important from a security point of view, to know which user account it is
... There are categories such as identity, system interface, system functions, the use case itself
... We wanted to understand from whose perspective each feature is important
... Would be good for us all to look through the use cases
... We have some Genivi API specifications for the radio tuner we were matching to
... I'd like to look at the Mozilla API to see how useful that would be
... Some aspects, eg, the content types might get confused when going from radio to TV
... but we'd need to spend some more time on that
... Items in the radio tuner column relate to APIs that already exist
... We listed what aspects are similar, and what could be used to solve the particular use case

Bin: Thank you for sharing your great work here, Ryan
... Is there a comparison against the TV Control API specification, or something else?

Ryan: It's against the Genivi API
... If the use cases are granular, we can do a comparison

Bin: Is your plan to spend some more time and do this comparison, and maybe identify some gaps?
... And contribute these to our phase 2 work?

Ryan: Yes

Bin: Any other comments?

Igarashi: I completely agree with Ryan that we should include these use cases
... We're also considering mobile TV and there are no differences between the use cases

Francois: Thanks for sharing the spreadsheet. Looking at the list, it seems to me to be more requirements than use cases
... For use cases, I'd expect to see user stories
... Does everything have to be covered by the API itself, eg, the user ID - this could be done by the application itself, doesn't have to be in the API
... How do you translate the use cases into requirements and how does this influence the API?

Ryan: I understand, and I agree. We do have a list of more general use cases, in the story format
... There was another tab in the spreadsheet. I'll upload them. These are more system functions or requirements

Francois: Does the Function Owner column indicate what is in scope for the API?

Ryan: Yes, we put that in to try to categorise the feature or use case. Most of the Infotainment System ones are the owners of the items there - eg, the parental lock
... The Infotainment System would own these and share them with an application accessing them
... The vehicle doesn't care about the application configuration, but it's a necessary part of life, so that's why it's there, to understand the whole realm of the environment

Bin: So we have some more work to do on alignment of these use cases. To help us understand the requirements, it would be good to have the user stories in addition.

Ryan: I can make those available

Bin: From the Function Owner column perspective, in addition could we clarify what should be in the API, what should be in the Infotainment System logic, and what should be in the application
... Once we have the user stories, and the categorisation, we can focus on the API specific system functions, and any gaps
... What do you think?

Ryan: Sounds good

Bin: Thanks, so please feel free to share with us and we can discuss on the mailing list, or on our next call
... Should we assign action items to track these?

Ryan: OK

<scribe> ACTION: Ryan to add user stories to the automotive use case comparison spreadsheet [recorded in http://www.w3.org/2016/02/09-tvapi-minutes.html#action01]

-> Created ACTION-44

<scribe> ACTION: Ryan to add categorisation to the Function Owner column in the automotive use case comparison spreadsheet [recorded in http://www.w3.org/2016/02/09-tvapi-minutes.html#action02]

-> Created ACTION-45

<kaz> radio use cases

Kaz: I wanted to add some clarification.
... Firstly, thank you Ryan for your contribution
... Regarding the use case comparison and gap analysis in the automotive group, there is some discussion in the Genivi wiki
... So we can use these

Bin: Any other business?
... No. On the next call I'd like to focus on the phase 2 use cases, with Ryan's input, and start a comparison with the TV Control API
... Chris, how would you want to proceed with your phase 2 use cases, maybe come up with user stories?

Chris: For security and privacy, I'd like to review other W3C specs that may have similar needs. Also, W3C published a few guidelines.
... Inside a device-specific runtime, maybe there is no need for access control mechanisms. In app runtime, we should consider options and do some analysis.
... Any similar work to look at?

Kaz: The Automotive BG and WG are running a security Task Force. More collaboration with them might be useful.

<scribe> ACTION: Chris to look into security models (esp. Automotive WG) to give inputs on the security model [recorded in http://www.w3.org/2016/02/09-tvapi-minutes.html#action03]

-> Created ACTION-43

Bin: Thank you all for your contributions

[ adjourned ]