TV Control WG Call

Chris: I notice that Alex is not around today, so we cannot really talk about the radio use cases he's working on.

Call for Consensus for publication as FPWD

Chris: In previous calls, we said that the only thing blocking publication as FPWD was the lack of introduction.
... I wrote one.

<cpn> http://w3c.github.io/tvcontrol-api/

Chris: Essentially, I've added an abstract that describes the overall goal of the specification. Next change is in the Status of This Document section to note that privacy and security concerns have not been addressed and that such a mechanism might change the API surface.
... Then the main change is the Introduction that describes the various concepts.
... If you haven't reviewed these changes yet, I encourage you to do so.
... Any other issues with the spec that you feel we need to address before we move to FPWD?

[none heard]

Chris: My next step will thus to send a Call for Consensus to the mailing-list to publish the spec as First Public Working Draft.
... How long should the CfC be?

Kaz: one or two weeks.

Chris: OK, I'll leave two weeks.

F2F meeting at TPAC and access control discussion

<cpn> https://www.w3.org/wiki/TV_Control/Meetings/2016-09

Chris: I've constructed an agenda for our F2F on Tuesday 20th September in Lisbon.
... Any feedback or comment on the way the agenda is constructed?
... I tried to leave the radio discussion to the afternoon, so that if Ryan wants to join us remotely, then that's hopefully at a friendly time for you.

Ryan: That would work.

<igarashi> +q

Chris: We'll try our best to stick to the schedule, but it depends on how things proceed during the morning session.
... What I'd like to do is: give an introduction to the API for people in the room that may not be familiar with it. And then go through the list of open issues on GitHub. With some help from Francois, I tried to group these issues into categories, so that we can structure the discussion.
... The main topic for the morning is the overall architecture for the spec.
... This is really looking at the relationship between TVSource and TVTuner, as well as a few other issues listed in the agenda.
... Most of the morning should be on such discussions.
... Then, after lunch, things that are access control implications: channel scanning, parental lock, etc.
... And then the radio use cases and API following that.
... Some discussion on how we relate schema.org metadata with our spec, and whether we need to define any mapping to underlying broadcast protocols.
... Please do take a look at the issues and provide comments on GitHub so that we can hopefully agree on a conclusion at TPAC.

Igarashi-san: I'm interested in access control. Access control to retrieve the program and EPG information?

Chris: Yes.

Igarashi-san: Some may want to restrict access to this information.

Chris: Indeed. I discussed this internally with my colleagues and there would be a concern to allow arbitrary origins to access that information.
... What I've done is list these concerns in the requirements page.

Jean-Pierre: You have some information about the program and you want to protect it. But until then? At some point, you want to publish that info so that people can find the programs.

Igarashi-san: My question is whether this is on the agenda for the TPAC. I can provide some input to these discussions.

Jean-Pierre: I've been working on metadata for TV for years. Very often, broadcasters say that the information is very sensitive, but at the same time, it's usually available on the Web, so what's the point?
... I'll be in Lisbon to discuss.

Chris: As a content provider, we want some degree of control as to how the content is presented. In the current world where we build our own channel-bound applications, then we can do that.
... The question is on whether any arbitrary web site can present the tuner stream.
... What precisely content providers may want to keep control on, that's the question.
... In the TV world, you have the broadcast-related / broadcast-independent border.
... Whether that model should be applied to the Web is an open question.

Kaz: In that case, it might make sense to have a joint discussion with the GGIE Task Force and the Web and TV IG.
... The GGIE Task Force has been working on identification issues.

Chris: Do you think we should add this to the agenda?

Kaz: Maybe we can have that discussion on Monday during the Web and TV IG.

Igarashi-san: I would like to clarify the current consensus. Do you believe that this should be more open than in the HbbTV world? Does it mean that arbitrary web pages can access the program information and present the content?

Chris: Yes, when I say "open", that's what I am implying.

Igarashi-san: That's issue #13?

Chris: Exactly

<kaz> issue 13

Steve: In terms of EPG data, there's probably no problem exposing that. In terms of presentation, the rationale is around commercial issues where, if some Web page displays ads on its own, there may be licensing issues.
... [scribe missed 3rd issue]

Igarashi-san: Some broadcasters are sill concerned about exposing EPG data, I think.
... I worry about that. Of course, open APIs are good for other people, but some stakeholders may not be happy with that.

Jean-Pierre: At some point in time in the process and workflow, you have metadata available somewhere and you would like that to be sealed until you need to publish that metadata for people to use it.
... As soon as you do it, restriction becomes useless.

Igarashi-san: The current mechanism is very restricted. Access control should not be done by the web page, rather per action basis.
... Accessing the channels information is OK for instance.

Jean-Pierre: I think we need to work on the workflow. Two cases, you want to restrict access control, or you want to advertise it. In both cases, you'll need to publish the information in some way. I'm a bit lost.

Igarashi-san: You're not ;) I think that's an important topic to have on the agenda to discuss at TPAC.

Jean-Pierre: That's relevant, yes.

Chris: It is on the agenda for TPAC. It's more the afternoon session, but we may touch on it in the morning. Most of the issues are inter-related.
... I think Steve gave a good summary. From a BBC perspective, we would certainly be worried about presentation of ads along our content.
... I think channels access is more a user privacy concern. Enumerating the list of channels is problematic from that perspective.

Igarashi-san: How about the EPG and Program information?
... Is it ok for everyone to see that?
... I think it depends on the business model.
... I don't have strong requirements on metadata from a TV manufacturer perspective. However, if that's an issue for broadcasters, we need to take it into account.

Jean-Pierre: I think we need a general discussion on metadata on the agenda. There's a bit of history there. There are many branding issues (e.g. ensuring that the user is aware of the provenance of the content at all times).

Igarashi-san: Access control to the EPG metadata. Aren't these architecture issues?

Chris: I think it will affect the architecture.
... I don't think we can resolve this here and now.
... I need to put some more thoughts from our perspective. I'd like to here from other content providers as well to get more consensus on this particular topic.
... The action that I take away today is to adjust the TPAC F2F agenda to create some space in the morning to discuss metadata.
... More comments on this now?

Igarashi-san: Is there any Web and TV IG meeting at TPAC?

Kaz: Yes, there will be one on Monday, where we could discuss with the GGIE TF.

Igarashi-san: Who is active in GGIE?

Kaz: NBC Universal (Glenn Deen, Bill Rose)

Jean-Pierre: When I registered for TPAC, that sort of particular joint meetings, where will they be announced?

Kaz: We're still gathering information.

Jean-Pierre: How would you publicize the results? Through the reflector?

Kaz: Yes, I can send a message to the TV IG list and updated the TV IG wiki. And Chris can update the TV Control WG wiki as well.

Igarashi-san: In terms of requirements, we could discuss with Web and TV IG, e.g. access control for program and EPG. But we should be careful on discussion of the architectural solution.
... That should be done by the WG.
... For patent policy reasons, among other things.
... We should only discuss about requirements with the Web and TV IG.

Chris: Thank you, yes, it is a good idea. If we could get some feedback from the IG on these requirements, then that could get us a better understanding of the needs, and the WG could then work on a solution.

Igarashi-san: We could have a requirements session on the agenda.

Chris: OK, Kaz and I will take that offline.

Kaz: Given that this is related to security and privacy, maybe it would make sense to have another joint session with Web of Things IG and Automotive BG/WG.

Chris: For the Automotive, Ryan shared the details of the security work that has been done there.
... I'd like to read through that to get a better understanding as to what has been done.
... My main concern is around scheduling these joint meetings.

Igarashi-san: Same comment as before, that should stick to use cases and requirements.

Kaz: We can restrict the discussion to use cases and requirements for security management.

Igarashi-san: Before discussing the solution or use cases, the WG needs to agree first on which requirements it needs to support. This means hearing from other broadcasters.
... This is not a generic security issue. More a business-related security issue. Are broadcasters fine with exposing the data and content?
... My interest is gathering requirements from broadcasters.

Chris: I realize that we're running out of time.

API and spec changes to support radio

<inserted> Kaz: in that case, I can ask the Web&TV guys about their opinions as well.

Chris: It may be that supporting radio is just as simple as renaming the interfaces to drop the "TV" prefix.
... But then Alex is also talking about bringing some radio-specific parts
... e.g. slideshows that may be broadcasted along with the radio stream.

<kaz> editor's draft

Chris: Which could lead to more adjustments needed to the API.
... I hope Alex will be able to come back and present some analysis there.
... The other thing that Alex said he would do was review the Genivi work.
... Again something I hope we can get back to at TPAC.

Ryan: I'm still working on an analysis between Genivi IVI and TV. I'm still in the middle of that. Hopefully by the end of this week, I'll be able to share something.
... I haven't talked to Alex. Maybe we can just share the results and compare our notes.

The TVSource and TVTuner objects

Chris: The final topic that I wanted to touch upon today is issue #4.
... Some good discussion on GitHub.
... But we're running out of time here.

<kaz> issue 4

Chris: What I think we may be missing here is descriptions of usage of these interfaces.
... There may be a need to redesign the API to expose the functionalities better.
... The original spec was designed by Mozilla but there are not in the group anymore, so we don't always know why some design decisions were made.
... I know that Francois has been looking at possible similarities with WebRTC, getUserMedia, isolated MediaStream.
... That should trigger good discussions at TPAC.

Steve: I agree with that. I cannot attend TPAC unfortunately, but can attend the meeting remotely.

Chris: Excellent!
... Any other business?
... There's a lot of food for thoughts in what we've discussed today. I'll investigate internally to get a broadcaster's perspective.
... I look forward to meeting those who can join us at the meeting.

[Call adjourned]