RE: [Long] Open Screen Protocol - next steps

Hi all,

 

I’m interested in the call as well.

My preference would be similar with Shih-Chiang Chien and Tomoyuki Shimizu.

 

Thanks,

Hyojin

 

From: Shih-Chiang Chien [mailto:schien@mozilla.com] 
Sent: Monday, January 15, 2018 3:06 PM
To: Tomoyuki SHIMIZU
Cc: Kostiainen, Anssi; Francois Daoust; mark a. foltz; public-secondscreen@w3.org; public-webscreens@w3.org
Subject: Re: [Long] Open Screen Protocol - next steps

 

Sorry for the late response.

 

I'm interested in join the call.

 

Blackout dates: 1/26

My preference will be 09:00 - 12:00 in UTC+8 on workday, or 22:00 ~ 24:00 in UTC+8 on Friday (for US/EU friendly time).

 

My timezone is UTC+8




Best Regards,
Shih-Chiang Chien

Mozilla Taiwan

 

On Fri, Jan 12, 2018 at 10:29 AM, Tomoyuki SHIMIZU <tomoyuki.labs@gmail.com <mailto:tomoyuki.labs@gmail.com> > wrote:

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 <mailto: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 <mailto: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 <https://docs.google.com/presentation/d/e/2PACX-1vSk0NcS8COhQ3vX3KdzEdufy72gaWONQeybRsFF843RheCusbUzj0l5XRmxiePiqTRKlE4SQbUpK_o8/pub?start=false&loop=false&delayms=3000&slide=id.g2a6f3cad35_19_30> &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
>
>
>
>