See also: IRC log
<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
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 ]