14:01:22 RRSAgent has joined #tvapi 14:01:22 logging to http://www.w3.org/2016/02/09-tvapi-irc 14:01:24 Zakim has joined #tvapi 14:02:22 RRSAgent, make logs public 14:02:37 Meeting: TV Control API CG call 14:02:45 Chair: Bin_Hu 14:03:38 Present+ Bin_Hu, Francois_Daoust, Chris_Needham, Colin_Meerveld, Kaz_Ashimura, Tatsuya_Igarashi, Ryan_Davis 14:04:37 RyanDavis has joined #tvapi 14:04:52 Scribe: cpn 14:05:40 Topic: Review of draft WG charter 14:05:54 colin has joined #tvapi 14:05:55 Francois: We're ready to send the charter to the AC for review 14:06:06 ... There should be some comments from the accessibility team soon 14:06:08 Agenda: https://www.w3.org/community/tvapi/wiki/Main_Page/Agenda_Telco_Feb_09_2016 14:06:39 i|Francois|-> http://w3c.github.io/charter-drafts/tvcontrol-2015.html Draft Charter| 14:06:47 rrsagent, draft minutes 14:06:47 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 14:06:48 Francois: I'll let the group know when it's been sent to the AC 14:07:05 ... The review has to last at least 4 weeks 14:07:22 ... So won't end before beginning of review 14:08:06 Bin: Thanks for the contributions to the second-phase work, from Opera, BBC 14:08:14 s/beginning of review/beginning of March/ 14:08:25 i|Thanks|topic: Phase 2 Work| 14:08:35 i|Thanks|-> http://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases Phase 2 Use Cases| 14:08:40 rrsagent, draft minutes 14:08:40 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 14:08:58 Present+ Jo, Paul 14:09:10 -> https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases#Security.2C_and_privacy_requirements UC-2 14:09:18 Topic: Reviewing the phase 2 use cases 14:09:28 scribenick: tidoust 14:10:18 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. 14:10:37 ... This could be used for fingerprinting the user. There's an impact on privacy that we should think about. 14:11:19 ... 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. 14:11:24 ... That's sensitive. 14:11:54 ... There was also a comment from Sangwhan from Opera on similar topic, with a suggestion to integrate some form of permission model. 14:12:33 ... 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. 14:12:54 ... I don't have a particular solution in my mind for this yet, but something the group should discuss. 14:13:53 ... 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. 14:14:06 ... I included a link to the Mozilla FMRadio API. 14:14:47 -> https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases#Broadcast_radio UC-3 Broadcast radio 14:14:48 ... 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". 14:15:19 ... 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. 14:16:10 ... 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. 14:17:20 ... 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. 14:17:32 ... One thing that I don't know is whether this should be addressed by this group. 14:17:40 ... Open for discussions. 14:18:35 ... 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. 14:19:05 ... The API would not be restricted to tuner anymore, but would also include any sort of input source. 14:19:11 -> https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases#Handling_of_non-TV_.22channels.22 UC-1 Handling of non-TV "Channels" 14:19:15 ... That's a sort of summary for the phase 2 work. 14:19:22 q? 14:19:42 q+ RyanDavis 14:19:47 ack r 14:19:54 Ryan: Guest from the Media Tuner from the Automotive BG. 14:20:11 ... You were talking about the security aspects of the user. 14:21:00 ... Some unique user ID with some agglomeration would be the most straightforward solution for us. Have you thought about that? 14:21:17 Chris: Do you have something like a draft spec that we could have a look at? 14:21:28 Ryan: Let me try to get to the root of that. 14:21:40 Chris: It would be very useful if you could share a link. 14:21:47 ... This is much more at the application level. 14:22:22 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. 14:22:36 ... We may be able to share our API and maybe add to it. 14:23:10 ... Also, you were talking about TV/radio tuner comparison. We had started a similar work, but still looking for volunteers. 14:23:16 ... Happy to help from the radio perspective. 14:23:30 Chris: Again, that's something we can take a look at. 14:23:49 Ryan: The use cases are pretty different, but it's true that there are a lot of similarities in terms of content. 14:24:43 ... 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. 14:25:29 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. 14:25:42 q+ 14:25:48 ... Any comment? 14:26:03 Scribe: cpn 14:26:36 kaz: We should talk about the automative use cases on the automotive group call 14:27:10 s/call/call as well/ 14:27:25 Bin: If there are no further comments, we can take a quick look at the automotive use cases 14:27:46 ... and see how we can better align our cases 14:27:47 s/call as well/call as well, but maybe we could think the zones within a car as if those were separate rooms of a smart home/ 14:28:24 s/We should talk about/Thanks a lot for joining the TV API call, Ryan! We should talk about/ 14:28:44 https://www.w3.org/community/autowebplatform/wiki/Main_Page/MediaTunerTaskForce 14:28:46 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 14:29:16 Ryan: The original uses cases are at the top, then there's a use case comparison 14:29:22 ... It's still work in progress 14:29:38 ... We want to pick this up, get some more people to help 14:30:31 -> https://docs.google.com/spreadsheets/d/1yEZVIqgtxp-HgW3dZx9qnUzwOLgGmzmkGO-pF7m8noc/edit#gid=0 Use Case comparison table 14:30:39 ... Looking at the use case comparison, we broke this down into system functions 14:30:57 ... Streaming services API, tuner service API 14:31:13 ... There's the unique user ID I mentioned earlier 14:31:30 ... Which is important from a security point of view, to know which user account it is 14:31:53 ... There are categories such as identity, system interface, system functions, the use case itself 14:32:14 ... We wanted to understand from whose perspective each feature is important 14:32:33 ... Would be good for us all to look through the use cases 14:32:54 ... We have some Genivi API specifications for the radio tuner we were matching to 14:33:13 ... I'd like to look at the Mozilla API to see how useful that would be 14:33:44 ... Some aspects, eg, the content types might get confused when going from radio to TV 14:33:53 ... but we'd need to spend some more time on that 14:34:08 ... Items in the radio tuner column relate to APIs that already exist 14:34:29 ... We listed what aspects are similar, and what could be used to solve the particular use case 14:34:43 Bin: Thank you for sharing your great work here, Ryan 14:35:05 ... Is there a comparison against the TV Control API specification, or something else? 14:35:15 Ryan: It's against the Genivi API 14:35:32 ... If the use cases are granular, we can do a comparison 14:35:57 Bin: Is your plan to spend some more time and do this comparison, and maybe identify some gaps? 14:36:10 ... And contribute these to our phase 2 work? 14:36:12 Ryan: Yes 14:36:19 q+ 14:36:24 Bin: Any other comments? 14:36:46 Igarashi: I completely agree with Ryan that we should include these use cases 14:36:58 q- 14:37:31 ... We're also considering mobile TV and there are no differences between the use cases 14:37:35 q? 14:37:36 q+ 14:38:07 Francois: Thanks for sharing the spreadsheet. Looking at the list, it seems to me to be more requirements than use cases 14:38:22 ... For use cases, I'd expect to see user stories 14:38:56 ... 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 14:39:11 q? 14:39:13 ... How do you translate the use cases into requirements and how does this influence the API? 14:39:25 ack t 14:39:45 Ryan: I understand, and I agree. We do have a list of more general use cases, in the story format 14:40:33 ... There was another tab in the spreadsheet. I'll upload them. These are more system functions or requirements 14:41:06 Francois: Does the Function Owner column indicate what is in scope for the API? 14:41:48 q? 14:41:49 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 14:42:10 ... The Infotainment System would own these and share them with an application accessing them 14:42:51 ... 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 14:42:54 q? 14:43:55 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. 14:44:04 Ryan: I can make those available 14:44:54 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 14:45:13 q? 14:46:00 Bin: Once we have the user stories, and the categorisation, we can focus on the API specific system functions, and any gaps 14:46:10 ... What do you think? 14:46:14 Ryan: Sounds good 14:46:49 Bin: Thanks, so please feel free to share with us and we can discuss on the mailing list, or on our next call 14:47:02 q? 14:47:39 Bin: Should we assign action items to track these? 14:47:42 Ryan: OK 14:48:47 Action: Ryan to add user stories to the automotive use case comparison spreadsheet 14:48:48 Error finding 'Ryan'. You can review and register nicknames at . 14:50:38 Action: Ryan to add categorisation to the Function Owner column in the automotive use case comparison spreadsheet 14:50:38 Error finding 'Ryan'. You can review and register nicknames at . 14:50:54 q? 14:51:11 -> http://wiki.projects.genivi.org/index.php/IVI_Radio_Use_cases radio use cases 14:51:13 Kaz: I wanted to add some clarification. 14:51:21 ... Firstly, thank you Ryan for your contribution 14:51:44 BillRose has joined #tvapi 14:51:51 ... Regarding the use case comparison and gap analysis in the automotive group, there is some discussion in the Genivi wiki 14:51:52 ack k 14:52:08 ... So we can use these 14:52:23 Bin: Any other business? 14:53:10 ... 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 14:53:36 rrsagent, draft minutes 14:53:36 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 14:53:46 Bin: Chris, how would you want to proceed with your phase 2 use cases, maybe come up with user stories? 14:53:56 presetn+ Bill_Rose 14:53:58 rrsagent, draft minutes 14:53:58 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 14:54:16 q+ 14:55:05 Chris: For security and privacy, I'd like to review other W3C specs that may have similar needs. Also, W3C published a few guidelines. 14:55:56 ... 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. 14:56:16 ... Any similar work to look at? 14:56:39 Kaz: The Automotive BG and WG are running a security Task Force. More collaboration with them might be useful. 14:56:55 i/Chris: For security and privacy,/scribe: tidoust/ 14:58:01 Action: Chris to look into security models (esp. Automotive WG) to give inputs on the security model 14:58:01 Error creating an ACTION: data field(s) missing from result. Please mail with details about what happened. 14:58:12 ack k 14:58:51 rrsagent, draft minutes 14:58:51 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 14:59:39 Bin: Thank you all for your contributions 14:59:41 [ adjourned ] 15:00:12 rrsagent, draft minutes 15:00:12 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html cpn 15:03:01 s|Phase 2 Work|Reviewing the phase 2 use cases| 15:03:16 s|topic: Reviewing the phase 2 use cases|| 15:03:19 rrsagent, draft minutes 15:03:19 I have made the request to generate http://www.w3.org/2016/02/09-tvapi-minutes.html kaz 15:27:23 cpn has joined #tvapi 17:08:01 Zakim has left #tvapi