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>
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> 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-
>> 1vSk0NcS8COhQ3vX3KdzEdufy72gaWONQeybRsFF843RheCusbUzj0l5XRmx
>> iePiqTRKlE4SQbUpK_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
>> >
>> >
>> >
>> >
>>
>>