- From: Francois Daoust <fd@w3.org>
- Date: Tue, 9 Feb 2016 16:44:30 +0100
- To: <public-tvapi@w3.org>
Hi,
The minutes of today's meeting are available at:
https://www.w3.org/2016/02/09-tvapi-minutes.html
... and copied as raw text below.
Thanks,
Francois.
-----
TV Control API CG call
09 Feb 2016
[2]Agenda
[2] https://www.w3.org/community/tvapi/wiki/Main_Page/Agenda_Telco_Feb_09_2016
See also: [3]IRC log
[3] http://www.w3.org/2016/02/09-tvapi-irc
Attendees
Present
Bin_Hu, Francois_Daoust, Chris_Needham, Colin_Meerveld,
Kaz_Ashimura, Tatsuya_Igarashi, Ryan_Davis, Jo, Paul,
Bill_Rose
Chair
Bin_Hu
Scribe
Chris, Francois
Contents
* [4]Topics
1. [5]Review of draft WG charter
2. [6]Reviewing the phase 2 use cases
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
Review of draft WG charter
<inserted> [9]Draft Charter
[9] http://w3c.github.io/charter-drafts/tvcontrol-2015.html
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
[10]Phase 2 Use Cases
[10] http://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases
Bin: Thanks for the contributions to the second-phase work,
from Opera, BBC
<kaz> [11]UC-2 Security, and privacy requirements
[11] https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases#Security.2C_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> [12]UC-3 Broadcast radio
[12] https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases#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> [13]UC-1 Handling of non-TV "Channels"
[13] https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases#Handling_of_non-TV_.22channels.22
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>
[14]https://www.w3.org/community/autowebplatform/wiki/Main_Page
/MediaTunerTaskForce
[14] 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> [15]Use Case comparison table
[15] https://docs.google.com/spreadsheets/d/1yEZVIqgtxp-HgW3dZx9qnUzwOLgGmzmkGO-pF7m8noc/edit#gid=0
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
[16]http://www.w3.org/2016/02/09-tvapi-minutes.html#action01]
[16] http://www.w3.org/2016/02/09-tvapi-minutes.html#action01]
-> Created [17]ACTION-44
[17] https://www.w3.org/community/tvapi/track/actions/44
<scribe> ACTION: Ryan to add categorisation to the Function
Owner column in the automotive use case comparison spreadsheet
[recorded in
[18]http://www.w3.org/2016/02/09-tvapi-minutes.html#action02]
[18] http://www.w3.org/2016/02/09-tvapi-minutes.html#action02]
-> Created [19]ACTION-45
[19] https://www.w3.org/community/tvapi/track/actions/45
<kaz> [20]radio use cases
[20] http://wiki.projects.genivi.org/index.php/IVI_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
[21]http://www.w3.org/2016/02/09-tvapi-minutes.html#action03]
[21] http://www.w3.org/2016/02/09-tvapi-minutes.html#action03]
-> Created [22]ACTION-43
[22] https://www.w3.org/community/tvapi/track/actions/43
Bin: Thank you all for your contributions
[ adjourned ]
Summary of Action Items
[NEW] ACTION: Chris to look into security models (esp.
Automotive WG) to give inputs on the security model [recorded
in
[23]http://www.w3.org/2016/02/09-tvapi-minutes.html#action03]
[NEW] ACTION: Ryan to add categorisation to the Function Owner
column in the automotive use case comparison spreadsheet
[recorded in
[24]http://www.w3.org/2016/02/09-tvapi-minutes.html#action02]
[NEW] ACTION: Ryan to add user stories to the automotive use
case comparison spreadsheet [recorded in
[25]http://www.w3.org/2016/02/09-tvapi-minutes.html#action01]
[23] http://www.w3.org/2016/02/09-tvapi-minutes.html#action03
[24] http://www.w3.org/2016/02/09-tvapi-minutes.html#action02
[25] http://www.w3.org/2016/02/09-tvapi-minutes.html#action01
Summary of Resolutions
[End of minutes]
Received on Tuesday, 9 February 2016 15:44:49 UTC