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

RE: [Long] Open Screen Protocol - next steps

From: Francois Daoust <fd@w3.org>
Date: Fri, 12 Jan 2018 15:31:03 +0100
To: "'Kostiainen, Anssi'" <anssi.kostiainen@intel.com>, <public-secondscreen@w3.org>, <public-webscreens@w3.org>
Cc: "'mark a. foltz'" <mfoltz@google.com>
Message-ID: <076b01d38bb1$fccdbbd0$f6693370$@w3.org>
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Thursday, January 11, 2018 2:55 PM
> 
> 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

Yes

> 2/ timing preference, and any known blackout dates in January

Blackout dates: 17-18 January
Depending on the day, I may join evening calls.

> 3/ your timezone [3]

CET timezone (Information on that page is correct)

Thanks,
Francois.


> 3/ any additional proposals/input you want to discuss on the call
> 
> Thanks,
> 
> -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-
> 1vSk0NcS8COhQ3vX3KdzEdufy72gaWONQeybRsFF843RheCusbUzj0l5XRmxie
> PiqTRKlE4SQbUpK_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 Friday, 12 January 2018 14:31:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 14:31:24 UTC