W3C home > Mailing lists > Public > public-secondscreen@w3.org > January 2018

Re: [Long] Open Screen Protocol - next steps

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Thu, 11 Jan 2018 13:55:22 +0000
To: "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>
CC: "mark a. foltz" <mfoltz@google.com>, Francois Daoust <fd@w3.org>
Message-ID: <7D2742DF-E92C-4AA4-A978-6B991F3FE7A1@intel.com>
Hi All,

I'm very excited to see the increased emphasis this community has put on the Open Screen Protocol [1] development recently. Thanks Mark for outlining the plan.

All - I propose we have an Open Screen Protocol 2018 kick off call with an agenda to discuss and solicit feedback on the plan outlined by Mark below.

To help us organize the call, please let us know:

1/ whether you'd like to join such a call
2/ timing preference, and any known blackout dates in January
3/ your timezone [3]
3/ any additional proposals/input you want to discuss on the call


-Anssi (Second Screen WG & CG Chair)

[1] https://github.com/webscreens/openscreenprotocol

[1] https://www.w3.org/wiki/Second_Screen/Meetings#Group_Participants.27_Timezones

> On 9 Jan 2018, at 20.43, mark a. foltz <mfoltz@google.com> wrote:
> Hello Webscreens,
> I hope everyone had a good holiday break. I wanted to kick off work in 2018 for the Open Screen Protocol.
> In my view, here are the next steps for the Open Screen Protocol coming out of discussions at TPAC, and a general direction for work in the first half of 2018.
> This outline is mostly focused on delivering a complete set of specs by the end of March, but I will cover future testing and implementation items at the end.  My plan is to update the GitHub repository to align with this work plan; that means archiving existing documents and closing out issues that don't support it.
> My understanding is there is general interest and consensus on two different possible implementations for Open Screen.
> One assumes flexibility in implementation for both the controller and receiver, all the way to the network and security stack - we'll call this the "QUARTC Stack".
> The other is focused on interoperability with deployed standards like ATSC 3.0 and HbbTV 2.0. We'll call this the "WebSockets stack."
> Personally, I plan to make contributions focusing on the former before the latter, but ideally work will proceed in parallel with contributions by others.  Note that I also plan to take the action items from the F2F [1] and update GitHub as well, and start to work on the ones assigned to me.
> QUARTC Stack
> - mDNS and/or SSDP for discovery
> - QUIC+RTCDataChannel (QUARTC) [2] for transport and message framing
> Work items for the QUARTC stack:
> 	• Share data on reliability of mDNS vs. SSDP and decide on which protocol(s) to require.
> 	• Evaluate QUARTC and propose how to map application protocol(s) onto it.
> WebSocket Stack
> - DIAL for discovery (e.g., as used by ATSC 3.0/HbbTV 2.0)
> - WebSockets for transport and message framing
> Work items for the WebSocket stack:
> 	• Write up DIAL as an Open Screen discovery protocol (mostly referring to the existing spec, and based on the existing SSDP evaluation)
> 	• Map application protocol onto WebSockets
> Application Protocol
> For the Application Protocol, at TPAC two alternatives were proposed to the binary format that is currently in GitHub.
> - CBOR [3]
> - Protocol Buffers (in conversation) [4]
> Work items:
> 	• Evaluate pros and cons of these alternatives, get consensus
> 	• Revise application protocol to use chosen alternative
> Key Exchange and Authentication
> There is consensus that J-PAKE is sufficient to bootstrap authentication between the controller and receiver.  I feel that an additional identity assertion should be available in the protocol as well (e.g. the provision of a long lived certificate associated with each device).
> Work items:
> - Extend application protocol to include J-PAKE for authentication
> - Extend application protocol to support identity assertion (key exchange and challenge-response)
> Benchmarking and Implementation 
> After the protocol stacks have been updated, the benchmarking plan [5] should be updated to reflect the new proposals.
> Google plans to start an open source repository with a prototype implementation of the consensus stack later this quarter.  Details to come.
> Let me know if you have any questions, concerns, or feedback; otherwise I will start aligning GitHub with this work plan.
> Cheers,
> m.
> [1] https://www.w3.org/2017/11/07-webscreens-minutes.html#ActionSummary

> [2] https://docs.google.com/presentation/d/e/2PACX-1vSk0NcS8COhQ3vX3KdzEdufy72gaWONQeybRsFF843RheCusbUzj0l5XRmxiePiqTRKlE4SQbUpK_o8/pub?start=false&loop=false&delayms=3000&slide=id.g2a6f3cad35_19_30

> [3] https://github.com/webscreens/openscreenprotocol/issues/77

> [4] https://developers.google.com/protocol-buffers/

> [5] https://github.com/webscreens/openscreenprotocol/blob/gh-pages/benchmarks/README.md


Received on Thursday, 11 January 2018 13:55:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:19:04 UTC