[Minutes] Open Screen Protocol call - 2018-02-09

Hi all,

The minutes of the Second Screen CG call focused on the Open Screen Protocol workplan that we held today are available at:
https://www.w3.org/2018/02/09-webscreens-minutes.html
... and copied as raw text below.

Thanks,
Francois.

--
Second Screen CG Call
09 February 2018

   [2]Agenda [3]IRC log

      [2] https://lists.w3.org/Archives/Public/public-webscreens/2018Jan/0009.html
      [3] https://www.w3.org/2018/02/09-webscreens-irc

Attendees

   Present
          AnssiKostiainen, BrandonTolsch, ChrisNeedham,
          FrancoisDaoust, Geun-HyungKim, HyojinSong, JohnPallet,
          LouayBassbouss, MarkFoltz, TomoyukiShimizu

   Regrets

   Chair
          Anssi

   Scribe
          tidoust

Contents

     * [4]Meeting Minutes
         1. [5]Agenda bashing
         2. [6]Open Screen Protocol workplan
         3. [7]F2F meeting
         4. [8]AOB

Meeting Minutes

Agenda bashing

   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 [9]New charter of the Second Screen Working Group

      [9] https://www.w3.org/2014/secondscreen/charter-2018.html

Open Screen Protocol workplan

   See [10]Proposed Open Screen Protocol workplan

     [10] https://docs.google.com/document/d/1_qUKEsF0v-8ZibKZzsLcjxr3JRwZ5T062OrgYpgmHLQ/edit

   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> [11]https://tools.ietf.org/html/rfc7049

     [11] 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.

F2F meeting

   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 [12]https://
   www.fokus.fraunhofer.de/go/mws

     [12] 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.

AOB

   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.

Received on Friday, 9 February 2018 07:12:25 UTC