Re: [Long] Open Screen Protocol - next steps

My answers are inline below:

> 1/ whether you'd like to join such a call

Yes.

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

The following dates and time should be OK:

09:00-01:00 in JST (UTC+0900) on Jan 15, 18 or 19
18:30-21:00 in CET on Jan 22-26 or 29 (During this period I’ll join the
other meeting in Geneva in 9:30-17:30)

Thanks,
Tomoyuki


On Thu, Jan 11, 2018 at 22:56 Kostiainen, Anssi <anssi.kostiainen@intel.com>
wrote:

> 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
>
> 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-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
> >
> >
> >
> >
>
>