Second Screen CG Call
09 February 2018
Anssi: Goal is to have a briefing on the plan. People can then react on list.
Mark: Yes, I was hoping to get feedback from CG participants on the workplan and some division of work.
… Then discuss milestones
Anssi: OK, just as context, the Second Screen WG was re-chartered recently. The charter was updated to tie the work on the Presentation API more to the Open Screen Protocol to address Mozilla's comments.
See Proposed Open Screen Protocol workplan
Mark: John Pallett, who works with me as a project manager, and Brandon Tosch, developer, will be working on implementation, have joined to get a sense of what is going on in the group.
… We've had a lot of discussions on alternatives, idea is to turn them into more concrete proposal.
… My takeaway from TPAC is that there seems to be interest for two diferent directions. One, the "modern stack", is the QUARTC stack.
… QUIC combined with WebRTC. More customization of discovery, authentication. That's one main workstream
Anssi: Dual-mode discovery work?
Mark: That's one open question. Trying to collect some metric to see how much of an impact it has on reliability
… to see if it justifies the added complexity.
… That is one open item on the modern stack: mDNS/SSDP, either of both?
… The second main item for this stack is to take the work we did on how QUIC could be used and update that with what is being discussed in the WebRTC Working Group about QUARTC
… goal is to revise current proposal to take that into account.
Anssi: About the WebRTC WG, there are in process of rechartering. Do they expose features to the API?
Mark: To the user of the Presentation API, this should be an implementation detail, to the point where we want to go between networks. As long as it's a local network connection, I don't believe we'll have troubles.
… Then, we'll just need to map the Application protocol onto QUARTC. If you want to send a message to a specific presentation message, how does that work with QUARTC?
Mark: I'm hoping to leverage expertise from QUARTC developers, [mentions Google and Microsoft]
Anssi: Yes, it would be good to get involvement from implementers. We will have a discussion with Mozilla following the departure of Shih-Chiang.
Mark: Yes. The kind of next layer is the application protocol. Allows to send messages between controller and receiver.
… Not much guidance, so I started drafting a binary format. Which was a pain, many variable-length strings.
… Sangwhan proposed CBOR, ProtocolBuffer are alternatives.
… It would be good to take a decision on that soon.
… Then it's just a matter of mapping the message types into the chosen format.
… CBOR is more based on JSON. ProtocolBuffer came from Google. It has good properties for this work.
… If anyone has additional suggestions
Francois: Is the binary format you proposed off the table, or still an option?
Mark: The more I look into it, I can see issues in terms of adding new features and having to write code by hand to parse the structure.
… Unless there is a strong reason to keep it, I'm leaning against it.
… Keeping message size to a bare minimum could be a good reason to want a custom format.
Anssi: Would ProtocolBuffer be an issue from an implementation perspective?
Mark: There are a few different flavours. You have options to turn on/off certain features to control the size of the code that gets generated.
… Variable-length integers are used, and compression techniques are used, so it tends not to have much overhead.
… It would be useful to look at the generated code size. If you want to do the parsing in JavaScript, the code can be a bit bigger, because the language requires more operations to deal with binary data.
… CBOR, inherited from JSON, might be better from a JavaScript perspective. Depends on whether that's important for us.
Chris: Does ProtocolBuffer have an IETF spec?
Mark: That's a good question. It's been open source for some time, but don't know if an RFC was written.
<anssik> https://tools.ietf.org/html/rfc7049
Mark: Don't know the standardization status of CBOR either
Anssi: CBOR has an RFC, which is flagged as "stable"
Mark: Access to the application control from JavaScript is one consideration. And that leads to another phase of work which I would call the WebSockets stack.
… From discussion with media and entertainment folks, and Chris, it sounds that there is desire to support smart TVs that already expose similar second screen functionality based on WebSockets.
… The goal here would be, if an ATSC/HbbTV receiver wants to act as a receiver, how can it leverage technologies it supports?
… Probably a way to reuse DIAL almost as it is today, and to leverage WebSockets.
… In that scenario, we might want the control protocol to be parsed by JavaScript
… That's a consideration to choose the format for the control protocol. JSON-based might be preferrable. Would require a more thorough diagram to understand how this can work.
… I'd like to ask people like Chris and others whether they think that's a reasonable direction to pursue and whether they can help.
Chris: It's hard to say whether it's a reasonable direction. We don't have real feedback from HbbTV implementers. They don't really want to have to write custom code. If they can integrate out-of-the-shelf solutions, then it's good.
… We'd like to see the ability to pass additional parameters in the presentation request, that is one piece of work that we'd like to do, possibly with a new URI scheme.
… I have the feeling that, if there were implementations of the QUARTC protocols, then vendors could integrate that, and that may be an argument in favour of moving towards just one stack of protocols.
… Another argument is the security aspect. We would need WebSockets over TLS. Would a PAKE type solution be applicable here?
Mark: That's a question I don't have a complete answer to, whether the PAKE approach can be ported back to a device that does not support it. You can use WebSockets and add a key-exchange protocol on top of it.
… But you'll need some help from the device, some kind of trusted UI.
… Are device makers willing to make smaller changes to their devices to allow them to work as open screen?
… Are there secure solutions that we can find to secure the WebSockets connection? Requires some changes too.
Chris: That's right. Obviously, the thing that is attractive from a CE manufacturer point of view, is the compatibility with the main browser engines.
… Maybe what I'll do is write down some considerations.
… So that we can follow up on that. Both options may be open from an HbbTV point of view, I would say
Louay: HbbTV application lifecycle is important to look at. It's different from what we have in the Presentation API. We cannot terminate an application in the HbbTV application.
… One option that we can consider is to make some part of the Open Screen Protocol optional. At least the discovery could be done by the open screen protocol, and from there, if the device manufacturer supports the entire Open Screen Protocol, that's fine. Otherwise, devices still have the option to route messages through a proxy server.
… That's already written in the HbbTV specification.
… I think that's an idea Francois raised initially, to make the communication channel optional.
Mark: Yes, you have to be a little careful about bootstrapping the rendez-vous point over an unsecure connection. There might be a way around that. I need to talk with a few folks to see if that's possible.
… In summary, I think I would like to keep open these possibilities, either doing WebSockets, or WebSockets + Web proxy, and see how far we can go, before we decide on whether to include them in the final product.
Mark: Two more topics to cover from my side. One area that needs more definition is the details of the key exchange and authentication.
… PAKE may be sufficient to bootstrap. I'd like to see something a little bit stronger, to associate with a device certificate, to tie things with some sort of device identifier.
… I think that, from a technical side, there's work item to extend the application protocol, to figure out which keys are exchanged, with J-PAKE.
… Initially targeted at QUARTC, using DTLS.
… Second work item would be to identify long-lived certificates that identify these devices.
… Internally, we'll all need to get clearance from our security teams. There may be a couple of rounds of certification on that particular aspect.
… Finally, the last item I touched on briefly is looking at the work we did for benchmarking.
… Looking at some of the data we can collect and using that to evaluate the performance of what we propose.
… Easier to do with an implementation to test, obviously.
… We do want to create an open source repository with a prototype or reference implementation of what comes out of these discussion.
… Milestone is end of March for that. No details to share yet.
… That's basically the line of work I'm proposing to the group.
… Happy to update GitHub issues accordingly
Anssi: Yes, I think GitHub issues are the best venue to continue these discussions.
Mark: OK, will do. I'll probably close some of the old issues on previous proposals.
Anssi: One thing that I'd like to focus on is getting more implementers engaged. Sadly, Shih-Chiang had to leave Mozilla, and we don't have a Mozilla representative for now. Focusing on WebRTC can be a way to get WebRTC folks on board.
… Do you think we could organize a joint meeting to engage them?
… Getting in touch with Google folks working on WebRTC seems a good start.
Mark: Yes, WebRTC would be a great place to leverage for that. Most browser vendors are implementing WebRTC. Let's make a little bit more progress on some of our issues so that we can have a discussion with them.
… I'd say in a month or two.
Anssi: Right, when you can have a proof of concept. Sounds good.
Mark: I'll be talking informally with folks at Google before that point, but the snapshot milestone would be good.
Anssi: Brings us to the possibility to hold a F2F meeting
Louay: There is an AC meeting mid-May in Berlin.
Anssi: Some people may be traveling to Berlin at that time.
… That would be one opportunity, to colocate with the AC meeting.
… I believe we need to make a decision pretty soon.
… What is your feeling?
<anssik> AC Berlin 2018 13-15 May 2018
Mark: For me, personally, yes as long as it's the right week of May.
Louay: One more information, we are organizing the Media Web Symposium (MWS) 15-16 May, overlapping one day with the AC meeting.
<anssik> MWS 15-16 May 2018 https://www.fokus.fraunhofer.de/go/mws
<anssik> (in Berlin)
Louay: If after the AC, we can get some people joining the MWS. DASH-IF meeting at the same time. Also people from Microsoft, device manufacturers, etc.
[looking at calendar]
Anssi: 17-18 May could be an option
Louay: We can host both options, with one day overlap or without overlap.
Mark: In general, that week should be ok. Maybe we can do a scheduling survey.
Anssi: Yes, I can take an action to do that. We need to figure out whether we have a critical mass for the meeting.
… It's not very far away, so I will put the poll out very soon.
Mark: Sounds good.
Anssi: Any other topic? We heard Chris and Louay willing to investigate the HbbTV stack.
… Once issues are created, we can identify people.
Mark: In terms of priorities, I'm going to be focusing on QUARTC specifics.
… If folks want to spend some time on the WebSockets stack or on translating the application protocol to the chosen format, that would be good work items to take.
… I'll update the repo
Anssi: Louay, any people with WebRTC background at MWS?
Louay: I will check. DASH-IF people, maybe. I will check.
Anssi: OK, will contact you offline about logistics.
… Berlin seems like a good option. But we can certainly consider other options, just let me know.
… Thanks Mark for the overview. This work is moving faster than I expected. Other browser vendors should start to pay more attention to it.
… We may hold topic-specific calls when needed.
… Thank you everyone for participating.