Chris_Needham: tx for joining
... this is the 2nd call of the group
... focus on topics every month
... contribution to possible new development
... 2nd screen groups, etc.
... would like to give update

introduction

Chris_Needham: myself BBC in London
... one of the co-Chairs of the IG
... also participate in the 2nd screen group

Mark_Vickers: also one of the co-Chairs
... working in US based in LA

Tatsuya_Igarashi: Tatsuya Igarashi from Sony
... also one of the co-Chairs

Chris_Needham: next Anssi?

Anssi_Kostiainen: working on DAS group

Chris_Needham: alex?

Alex_Deacon: Alex Deacon
... primary focus is internet technology and policy

Paul_Jessop: from RIAA

kaz: W3C Team
... would like to help you all

Mark_Foltz: mark from Google

Chris_O'Brien: cloud browser

Giri_Mandyam: qualcomm
... also representative from ATSC

John_Luther: JW player

John_Pallett: John Pallett from Google

Peter_Pogrezeba: Peter Pogrezeba from DT

Chris_Needham: any topics other than second screen for today?

(none)

second screen work

Anssi_Kostiainen: introduction
... framework started from an XG
... and then CG
... 2014 API work started by the WG
... I'm the Chair of the WG and the CG
... WG defines Web APIs
... presentation API and remote playback API
... CG incubating
... kind of a big picture
... Mark has been working on presentation API
... and remote playback by Mounir from Google as well
... spec work and implementation in parallel
... Google, Mozilla and Apple participating in the group
... have 60 participants
... great to have this joint discussion here
... proposal to have joint meeting during TPAC on Monday in the afternoon
... protocol work CG might be interested

https://www.w3.org/TR/presentation-api/

Mark_Foltz: first most mature is presentation api
... web page to discover and request presentation device
... presentaation device pretty broadly
... chrome also suppoer t2 kinds of vertual screens
... api has 3 parts
... 1. provide a list of URIs
... 2. get current availability of the screen
... search for the URL
... presentation available object
... whether the screen is available or not
... 3. when the user clicks the button the presentation starts
... the user selects the device
... the browser starts to present the page
... message representing the page
... the most common uc is playing back our cast devices
... providing nicer APIs like pause/resume
... richer UX like queuing media to play on devices
... apis can be implemented in 2 ways
... UA mode
... render the presentation off screen
... send URI to the device
... this API is relatively mature
... going to propose REC soon
... implementation from Google and Mozilla
... challenges on authentication for the presentation

https://www.w3.org/TR/remote-playback/

Mark_Foltz: move on to remote playback API
... I contributed though not the Editor
... play it remotely
... select device for remote playback
... CR recently
... discussing how to align the capability of the media element with the remote devices
... github issues there
... Chrome is shipping the implementation
... would have second implementer
... that's work by the WG on the spec
... next work by the CG
... issue by TAG
... not a good story for interop
... something web standards see when having multiple vendors
... the end of last year, we rechartered the CG
... browsers and devices from different vendors
... decided the scope on the same wifi/network area
... doesn't require realtime setting
... a set of tasks to define different aspects
... how to find what screens are available

<cpn> https://www.w3.org/community/webscreens/

Mark_Foltz: transport to create connection
... how to provide strong guarantee to talk with other devices

<cpn> https://github.com/webscreens/openscreenprotocol

Mark_Foltz: app level protocol
... since last Oct
... working on template to evaluate
... compare to other solutions
... made good progress for the 2 proposals
... QUIC
... RTC data channel
... haven't made as much progress with presentation api, though
... authentication piece
... Mozilla and Google kind of agreed
... trusting something makes sense
... Open Screen Protoco
... hoping we could wrap up that

Chris_Needham: tx!
... great overview
... a few comments

Giri_Mandyam: comparing to what ATSC is doing
... opinions?

Chris_Needham: can give some opinion from HbbTV viewpoint

Mark_Foltz: can't say about ATSC
... but regarding HbbTV 2.0
... good alignment
... how to build robust authentication
... would be worth while to evaluate them
... once we could have authentication story
... something we should visit

Chris_Needham: from HbbTV viewpoint
... something we specify for HbbTV
... TV device to launch
... content synchronization work
... exchanging timeline info
... between devices
... synch of playinb back contents
... feature alignment is of interest
... that's one area
... and protocols
... HbbTV use SSDP
... transport is JSON message on Web Socket
... handshaking on the app level
... same channel as the app uses
... companion app and web app work on the TV device
... combination of JSON over WebSocket
... but also UDP things
... latency of the characteristics
... one attracting point
... coming up solution is feature compatible
... in the security layer
... we're talking about different mechanisms
... HTTP, Web Socket, UDP, etc.
... quite different
... are you familiar with ATSC work?

Giri_Mandyam: similar approach
... TV vendors use similar approach
... not 100% sure about the detail, though

Tatsuya_Igarashi: working on ATSC standards
... referring second screen use cases
... a bit different the second screen group's use case
... primary device is TV
... delivered by broadcast
... second device is assumed as a mobile device
... the use case is focused on applications for second screen
... done by mobile devices not TV
... the second screen app is operated by the user
... another use case is
... HTML5 app on the main device (=TV) working
... and mobile device communicate with the HTML5 apps

Chris_Needham: tx
... interested in terminologies
... remote screen and primary screen
... 2nd screen group
... vs ATSC/HbbTV
... companion app on the TV
... and mobile app as the 2nd screen
... but it's opposite

Mark_Foltz: pushing presentation to the mobile device
... changes the scenario
... also we could select screen (from more than 2 screens)
... aware of the content
... finally from the general web viewpoint
... how the content comes from broadcasting
... same origin policy

Chris_Needham: would like to have discussion within this IG

Mark_Foltz: restricting the presentation api to secure connection
... there is some trust model there

Tatsuya_Igarashi: besides security viewpoint
... would like to mention some uc
... presentation api assumes the case of...
... possible for second screen app to initiate the connection?
... having 2 UA
... and both of them already have launched apps

Mark_Foltz: presentations are labeled by URLs
... browsers know the value
... to reconnect
... what we haven't fully specified is...
... digital sign, etc., being distributed
... have not been handling IDs

Tatsuya_Igarashi: the assumption for UCs covered or not

Chris_O'Brien: delivering captioning by second screen?

Mark_Foltz: not explicitly
... don't have concrete UC for that purpose
... media on the text track
... could be transferred to the remote side
... how to handle remote captions

Chris_O'Brien: familiar with Active View
... seems to be optimal way to handle the information to me
... can send a resource to the group

<Chris_OBrien_AMI_> https://techcrunch.com/2017/06/13/actiview-aims-to-streamline-movie-accessibility-for-millions-of-hearing-and-vision-impaired/

<Chris_OBrien_AMI_> http://actiview.co/theaters/

<Chris_OBrien_AMI_> general overview of their technology

Mark_Foltz: happy to answer your questions on the list

Chris_Needham: need to organize follow-up discussion during TPAC
... in the afternoon
... after lunch

kaz: 1-2pm?

Chris_Needham: 2-3pm

Giri_Mandyam: suggestion
... 2nd screen evaluation done via ATSC's formal liaison

kaz: we could send a formal liaison letter to ATSC, HbbTV and IPTVF

Giri_Mandyam: good idea

Chris_Needham: we put links on the resources
... please review it and give comments
... remote playback and protocol level as well
... the next call would be basically Nov. 2
... right before TPAC
... any other comments before closing?

Tatsuya_Igarashi: during the joint session
... would like to give some presentation
... from high level viewpoint
... might be useful to think about that before diving into the detail

Chris_Needham: your presentation on ATSC
... and I'd like to give presentation on HbbTV
... btw, wanted to talk about key exchange for security
... would like to continue discussion on the ML and joint discussion at TPAC

<cpn> hbbtv specifications: https://www.hbbtv.org/resource-library/#specifications

[Igarashi-san's clarification]
Tatsuya_Igarashi: what I want to give at the f2f is short presentation on second screen from very high-level viewpoint
... could partly cover HbbTV and Hybridcast as well as ATSC

<cpn&Igarashi> https://www.atsc.org/atsc-30-standard/a3382017-companion-device/

[adjourned]