W3C home > Mailing lists > Public > public-secondscreen@w3.org > June 2016

[minutes] WG F2F - Mountain View - Day 2/2

From: Francois Daoust <fd@w3.org>
Date: Wed, 1 Jun 2016 09:58:23 +0200
To: <public-secondscreen@w3.org>
Message-ID: <04ed01d1bbdb$5f45fff0$1dd1ffd0$@w3.org>
Hi again,

Similarly, I cleaned up the minutes of day 2 of our F2F, which are available at:
https://www.w3.org/2016/05/25-webscreens-minutes.html

... and copied as raw text below.

Thanks,
Francois.


-----
Second Screen WG F2F - Day 2/2
25 May 2016

Attendees
   Present
          Anssi_Kostiainen, Mark_Foltz, Mounir_Lamouri, Rick_Smit,
          Hyojin_Song, Chris_Needham, Shih-Chiang_Chien,
          Yavor_Goulishev, Francois_Daoust, Jonas_Sicking,
          Ed_Connor, Eric_Carlson
   Chair
          Anssi
   Scribe
          Francois, Rick, Mounir, Yavor

Contents
     * [4]Topics
         1. [5]Presentation request URL issue
         2. [6]Possible scope for the open protocol CG work
         3. [7]Mozilla's FlyWeb presentation
         4. [8]Mozilla's input to open protocol discussion
         5. [9]CG rechartering
     * [10]Summary of Action Items

   See also the [11]minutes of day 1.

     [11] http://www.w3.org/24-webscreens-minutes.html

   NB: Minutes are rough, imprecise, and possibly wrong from time
   to time. Check issues on GitHub, linked from these minutes, for
   additional context.
     __________________________________________________________

Presentation request URL issue

   Anssi: We parked an issue that arose as a spin-off of [12]issue
   #153
   ... Problem is with the presentation URL that may contain
   additional proprietary parameters that get used instead of the
   URL itself.

     [12] https://github.com/w3c/presentation-api/issues/153

   Mark: A bit of history. There was strong pushback initially
   against supporting non HTTP/HTTPS schemes.
   ... We found a workaround to allow to pass additional
   parameters
   ... I looked at the code. There is very little probability that
   the extra parameters might collide with existing fragment
   identifiers.
   ... Another concern was around what would happen if developers
   use the URL with other implementations.
   ... Again, that's not going to do much.
   ... One use case is to enable capability detection to allow
   developers to assert that a specific URL will be supported.
   ... Instead of passing a list, a wrapping library could be used
   that tries the different URLs in turn.
   ... We can mix Cast parameters and DIAL parameters. The
   beginning of the HTTP URL itself will be used for the 1UA case.

   Anssi: This suggests no change to the spec.
   ... Based on implementation experience, we can probably revisit
   this later on.
   ... If we publish a CR and realize that we need to change this,
   we can republish another CR. That will add another delay.

   Jonas: I think that we have strong evidence that what we have
   now does not work.
   ... You're passing a URL but you're treating it as passing
   parameters.
   ... You want a Cast identifier, and since the API only takes a
   URL, you work around that.
   ... You're forced by the API to hack it.

   <anssik>
   [13]https://w3c.github.io/presentation-api/#user-interface-guid
   elines

     [13] https://w3c.github.io/presentation-api/#user-interface-guidelines

   Francois: The security guidelines recommend that the
   controlling user agent display the requested origin. In this
   case, the requested origin does not mean anything, so it could
   be used by an attacker to pretend that the app will present
   amazon.com content whereas it's not.

   Mounir: Yes, as soon as the spec suggests to use the URL, then
   it's not an opaque string anymore

   Jonas: The semantics of this URL parameter is "load this URL
   onto the second screen", and that's not what you're doing.

   Mark: It seems we're discussing implementation internals.
   What's the difference in practice?

   Jonas: It makes a lot of differences. [analogy with fetch]
   ... If you are interpreting the values differently from what
   the specification suggests, then you're not following the spec.

   Ed: Where's the interop if the URL is interpreted differently
   by different implementations.

   Jonas: I understand what you're trying to do, but you're
   working against the spec here. The goal is to take the HTTP URL
   and load that content. This could lead to a redirect of course,
   but that's not a concern.

   Mark: The meaning of the URL depends on the target device.

   Jonas: The spec says to fetch the URL.
   ... You're subverting the spec.
   ... With "Navigating to an HTTP URL", the expectation is that
   you'll follow the HTTP protocol to download the resource.
   ... If it redirects to other schemes, then so be it, but that's
   not what happens here.

   Mark: Do you have a concrete proposal, then?

   Jonas: You need an ability to say "please load this Cast app".
   ... It should be something other than HTTP.

   Mark: Your concrete proposal is that we require another scheme?
   Can the backend redirect to the cast scheme?

   Jonas: Yes.

   Francois: If the URL is google.com/blah, you may not even need
   to go to your backend, that's your domain, under your control.

   Jonas: If I request amazon.com/#__castid=abc123, you will
   interpret it as a Cast app. But Amazon.com is not going to do
   the redirect to the Cast app. So you should not interpret it as
   a Cast application.
   ... You can do that for URL spaces that you own, you cannot do
   it for other domains.
   ... Two proposals in the end: 1) you should add some kind of
   "cast" scheme. This can be done under the hood. 2) My
   understanding is that companies like Netflix have preferences
   for launching a DIAL app rather than launching an HTML app, I
   do see value in having a fallback mechanism.

   Mark: We can certainly construct these cast URLs behind the
   scenes. That will probably not impact the spec itself.

   Yavor: For Youtube, we'll use whatever answers first. If it's
   DIAL, then we'll use DIAL. If it's Cast, we'll use Cast.

   Jonas: The specific spec change for the first point is to make
   it clear that the URL that gets passed to the Presentation API
   should go through Fetch.

   Francois: The spec does say to "navigate to the presentation
   request URL", so not sure we need something on top of that.

   Jonas: My argument is that you can only control redirects for
   domains you control, not for others.

   SC: Question is how would this work with Firefox's
   implementation of the Presentation API.

   Mark: This is really a vendor extension that should not be
   added to other calls.

   Jonas: If you guys have that need, I think others will have
   that need too. I would not be surprised if Mozilla would want
   to support Cast applications as well.
   ... We can do that much more easily if it's a cast:// scheme.
   ... If it's part of the Google namespace, as in google.com/cast
   internally redirects to a cast:// URL, we can bake that in
   Gecko as well, but that's much less ideal.

   Mark: The last part of my conversation is that being able to
   pass a list of URLs will delay things by a couple of months at
   least.

   SC: For Firefox OS, we use app:// scheme to launch native apps.
   For generic content, it uses HTTP.

   Mark: So we have a use case for fallback.

   Jonas: Yes.
   ... If things converge in the future, I can imagine that things
   converge on HTTP, we'll just ignore the rest.

   Anssi: So you want an explicit extension mechanism.

   Jonas: Yes.

   Anssi: We don't yet have consensus it seems. I'd like not to
   block the spec today.

   Francois: Also wondering about the relationship between URLs in
   the array. They may not be related.

   Ed: Not a problem. That would match the API contract: the
   ability to pass multiple possibilities.

   Francois: OK, same thing as for <video> sources now that I come
   to think about it.

   [discussion on google.com/cast and cast:// scheme]

   Mark: Let's try to separate the discussion between separating
   namespaces which I agree with, and the fallback mechanism.

   Jonas: Adding a new protocol is a significant easier thing to
   do than changing the semantics of HTTP.
   ... In the end, my summary is that I think that you're doing
   right now is not per specification.

   Anssi: I'm hearing a proposal here which is to keep the API
   surface as is and restrict your interpretation of the URL in
   your implementation.

   SC: A specific scheme will help implementations detect early
   that the URL won't be supported.

   Mark: We need to have clarity on the fallback mechanism. We
   plan to support the 1UA case soon.

   Jonas: APIs that take either a string or a list of strings
   exist, no problem with that.

   Mounir: Do you guys support 1UA?

   SC: Yes, planned for September. 1UA is only for HTTP.
   ... If the controlling app passes a non HTTP URL, it will be
   discarded.

   Mounir: So you need the fallback mechanism too.

   Anssi: So concrete spec changes?

   Mark: In PresentationRequest, two constructors, one with a
   DOMString and the other with an Array of DOMString. Then on the
   PresentationConnection, we need to expose the URL that got
   presented in an "url" attribute.

   Anssi: What is the impact on the implementation?

   Mark: Will need to get back to you on that.

   Jonas: Some of what is need already happens anyway.

   Mark: Yes, it's more the plumbing in-between.
   ... And there's also a UX impact.

   PROPOSED RESOLUTION: Add a fallback mechanism by adding a new
   constructor on PresentationRequest that takes an Array of
   DOMString, and by exposing the presented URL in an "url"
   attribute on PresentationConnection, pending feedback from
   implementers that this doable.

   Anssi: Good, moving on.

Possible scope for the open protocol CG work

   ->[14] Presented slides on open protocol and CG rechartering

     [14] https://docs.google.com/presentation/d/1s_ZShYTKArSkXwjHRGpf8HBQaRweOi9H0fgd94I9mOw/edit?usp=sharing

   mark: prepared discussion for rechartering community group
   ... put togheter pull request
   ... interesting discussions about scope deliverables
   ... little bit of history, CG started 2013
   ... input from Netflix, Mozilla, Goolge
   ... ansi checked in boilerplate charter
   ... thinking about what scope we would like to tackle for this
   work, 1. network level behaviour, 2. common cases and get them
   right. 3. build on stable standers 4. bandwidth issues, 5. let
   it be future proof
   ... personally I think prototyping is helpful, if I have the
   resources I would like to build open source resources
   ... here's a summary for a reasonable scope. discover of
   presentation displays that share the same LAN, multiple
   connections per controller and per display, secure connections
   ... data that is passed between ua's should be secure
   ... one thing we may want to include is provide a way for
   vendor extension. Seems that there is some pushback for vendor
   extensions

   Francois: what woudl the CG define?

   Mark: extension points for vender extensions

   yavor: for dial there's nothing we can use, for that point we
   need a propietary extension that supports playback controls
   ... that can be cloud and only use dial to launch the app, if
   it's standarised it would improve latency and would be easier
   to support.

   mark: the existing messaging for api is designed to handle
   this, like volume control
   ... for now I like to keep it really generic and understanding
   the use cases more

   Jonas: so for talking to a html application there's messaging
   for remote playback, for dial that doesn't exist?

   javor: so you can have applications that have messaging both
   ways?

   mark: yes

   yavor: that's great

   mark: I think a lot of these things are not we don't want to
   do, but maybe not have a high priority
   ... webrtc is not great for doing local area screencast, we're
   working on it

   jonas: I share a lot of your concerns, 1 ua mode exist to
   support old hardware dont really see the point, I think EME
   would be really great if we could support presentation api with
   encrypted media
   ... how does chromecast handle that?

   mark: they send a url to the player and player handles it

   jonas: what I'm curious about would it make sense for the
   protocol support sending user credentials

   mark: I think that's sensible to do
   ... we want to make it easy for the url to be fetched

   jonas: what im thinkgin about is supporting a netflix dial
   application where you send user credentials to the app

   mark: you cant pass a license from one device to another,
   that's by design
   ... out of scope is also interactive presentations, interesting
   for gaming

   jonas: Im curious how important an unreliable channel is

   mark: I think gaming, they want a low latency
   ... couple of ms
   ... we have our chrome desktop team who is working on this and
   I could check with them how to handle this
   ... open question: accesibility, to have screenreader work
   across controller and receiver

   anssi: I would leave accessibility out of the scope

   mark: require display access control, like a password, now
   anyone can access the display

   in the past we also discussed the propagating origin
   information, so the TV nows what's the origin sending it

   mark: in the past we also discussed the propagating origin
   information, so the TV nows what's the origin sending it

   anssi: display capabilities was a controversial part of the api

   mark: so exposing those capabilites is out of scope for
   presentation api, maybe remote playback api, do we want support
   in the protocol for that.

   jonas: on capabilities, one use case im interested in is
   something like supporting chromecast audio
   ... I feel like you can kinda use ChromeCast, it would be bad
   UX if you go to pandorra and it says you have a remote device
   available and it would start playing on your tv

   mark: what we do now is give the user info over the device
   ... so if it's audio show a little speaker icon

   anssi: is it an implementation detail?

   jonas: I think if you're on netflix and watching arrested
   development and shows a fling button and if it would fling to
   your speakers it would be bad UX

   mark: you would have to tell the app that it's video content

   anssi: you still might want to override that

   jonas: maybe audio only vs video only could be a baselevel
   thing

   anssi: what is chromes way, is it like a prompt that tells you
   which devices you have?

   mark: the ux seems to have changed

   anssi: this is a point where people are struggeling with

   yavor: does the application knows what to expect on the other
   side?

   mark: we decided that the app could feature detect what the
   device could do

   francois: when the user enters an url the website will detect

   mark: the requirements fall out of scope that i discussed
   earlier
   ... i think its important from ux point of view to know if it's
   avialable or in use

   jonas: so when you show the device picker it shows "jonas tv
   currently playing netflix" or something?

   mark: yes exactly
   ... we had discussions about power saving, this should also go
   for tv's

   yavor: do you want to support wakeup lan?

   mark: we're discussing requirements so it would be a feature
   request
   ... connection is pretty similar to the scope discussions,
   displays should be able to deny connections

   anssi: reconnection is now part of application logic

   mark: an important part of the spec would be the connection
   lifecycle
   ... it's important to allow presentation from secure context,
   to have strong encryption, there are a number of approaches to
   handle this

   jonas: it's impossible to guarantee that you connect to the
   device that you're trying to connect to
   ... at no point you have a secure communication channel, you
   have to decide which parts you trust

   mark: the solution is in public key I think, and trust model
   ... what do we have to support on the protocol level?
   ... query command, give the url an id, multiplex like multiple
   browsing context, passing locale for rendering display

Mozilla's FlyWeb presentation

   jonas: this is a presentation that I wrote for people a little
   less familiair with this topic
   ... flyweb is a project we're working on at mozilla

   mounir: like b2g? ;)

   jonas: yes, like b2g ;)
   ... the problem that we try to fix, we all have these smart
   devices, we almost always try to connect them trough the cloud.
   a problem is latency
   ... the way we do collaborative document sharing, we grant
   access to another persons account, we have to send an url and
   then we can start collaborating
   ... if we imagine the future of the smart hotelroom, and you
   want to interact with all the smart devices, talking to these
   smart devices would suck if a.) it requires an application
   installation and account creation
   ... so what we want to do is use the fact that the web is
   really good at on demand application delivery
   ... using applications is a very nice thing to do, a room
   service application can offer a nice ui, and show you stuff you
   could order, and with a tv you could have a nice ui which shows
   which are playing
   ... apps are really nice to show ui's but the installation and
   authentication are less nice
   ... the web is fairly good at cross platform so it would be
   nice if we could enable the web to interact with these things.
   Currently that doesnt works so well because we have some
   builtin assumptions on the web, severs must be on the internet,
   must connect to them over tcp/ip
   ... if we forget these assumptions, servers can be on any
   device, can talk over other transports discoverable vial locale
   ... an example is a phone running a flyweb browser and a tv
   running a flyweb server. in this case it's scanning and finds
   the tv remote. the browser will establish a connection with the
   tv and acts a webserver and downloads a webui on the
   smartphone. at that point it's a web application that can do
   everything a normal application can do
   ... another thing we want to do is enabling p2p use cases, like
   phone to phone or desktop to desktop
   ... if i have browsed to a website, that website can turm my
   phone in a flyweb server, a discoverable server
   ... we have this working
   ... not production quality, it's not like we're working an
   actual implementation but so far it seems to be working well
   ... we use mdns to enable discover, and we can also the http
   request and websocket connections over the network
   ... we have some basic ui to scan for nearby devices and launch
   them
   ... our hope is to land within the next couple of weeks
   ... what we have right now is that is should all be encrypted
   ... the tricky part with this, is encyrpting it with a key that
   bad people don't have access to, so what we do right is during
   discover is include a TLS certificate fingerprint

   anssi: can i give my friend a flyweb url and he can click that
   and then gets this page?

   jonas: I dont know where' we're going to end up on that
   ... I have desktop builds where it should be working

   anssi: so you have a spec for flyweb? Do you have plans to move
   that spec for further incubation?

   jonas: there are still things we're figuring out

   anssi: so you said you're using mdns, so that's the protocol of
   choice?

   jonas: it's up to debate but we're trying to reuse as much as
   possible

   mark: are using bluetooth for messaging?

   jonas: the idea is that we can do messaging over different
   transports, we havent done bluetooth yet
   ... so this is http right now, but it should also work with
   https over tls
   ... so this is running the webserver, so we have a webserver
   api, which is super simple, it's logging all the request and
   returns all the requests like a webserver
   ... the client api is super simple, you can use xhr or a
   websocket and then you can do the normal stuff

   mounir: why not using service workers?

   jonas: service workers is for running stuff in the background,
   at the moment this is not supposed to work in the background
   ... all we do is fire a fetch event, you can either create a
   response object from scratch or fetch resources or do whatever
   ... for socket we fire socket event, you can either accept it
   in which case you get back a WS object and then it's just a
   normal WS api
   ... there are like 1 or 2 interfaces that are new
   ... we need to define how discover works, so it could work
   across browsers
   ... so the network protocols should be defined, like mdns and
   http

   yavor: how do you deploy private keys for the certifcates?

   jonas: for this scenario, in this stage during discovery when
   the browser sends out mdns request, the server will respond
   with a standard object and plain text entry which is a
   certificate key
   ... we remember the certificate and associate it with an url
   name

   francois: from a ux perspective, do you prompt the user?

   jonas: this isn't implemented yet
   ... the idea is that when a website wants to publish a server
   that we'll ask the user are you ok with this website

   mark: can do server website find out the url?

   jonas: there might be reasons why the server wants to know it's
   own url
   ... but we havent actually had the need for that, most cases
   just serve relative urls
   ... something we would like to support where a webpage could
   say do a discovery, i would like to connect to an iot and say:
   I want to be the server

   mark: it goes both ways, to the publication could publish a
   remote control app

   yavor: does it matter which side is the server for WS

   jonas: for a UI it matters
   ... the next thing we're going to look at to support is
   bluetooth, but also NFC is somethign we're looking at
   ... there are several areas where we can still expand this

   anssi: we could message this in the CG scope

   jonas: this is still in very early stage

   anssi: if there's a reasonable overlap it sounds like a good
   idea, if we dont get huge scope expansion

   jonas: I dont think it would make sense to have flyweb go
   through the second screen WG

   francois: right now it's not in scope, but the WG will have to
   recharter end of October, so it might be a window of
   oppertunity

   jonas: there need to be two interested parties, and dont know
   if Google is interested
   ... one thing that i think would be useful into presentation
   api is the idea that a webpage could be a webserver
   ... instead of giving an url say get back to me and tell the
   device to get back to the controller

   anssi: so jonas you had a timeline?

   jonas: we're landing the code end of this quarter
   ... and you would have to go into config and turn it on

   anssi: when would you be interested to push this to a Community
   Group?

   jonas: I cant give a good estimate because it would be other
   people doing it
   ... physical web is very related and very similair but is
   solves problems in a different way, and if Google wants to
   expand physical web to this, then it would be interesting
   ... we struggled a lot with the security on the web vs security
   on native because it's very different
   ... but the challenges are very similair
   ... and I think we can get it as good as native
   ... relatively easy we can incrementally make it more secure
   over time

   anssi: we can add new things to the CG charter, we have one
   month review, we could ammend CG with your things when you're
   ready to get on board

   jonas: the main overlap between what you presented and this si
   the protocol pieces, but for the usecases what we're focussing
   on right now, most immediately I think it's the discover part
   where we can share solutions

   mark: I know you also want to support BT and potentially WS
   ... and then if you want to add extension that would be
   perfectly acceptable to

   anssi: if you have resources to share, could you please add
   them to the minutes

   jonas: there's a github repo but it's very out of date

   mark: you do have IDL checked in right?

   jonas: yeah it has IDL baked in
   ... I'll past the url of our project page

   <sicking> flyweb project page. Often out-of-date:
   [15]https://wiki.mozilla.org/FlyWeb

     [15] https://wiki.mozilla.org/FlyWeb

   jonas: it's mainly for us internally and has stuff that's not
   really relevant

   anssi: so what is your timeline for the CG?

   mark: I have some early drafts for some of the protocol stuff,
   I like to start the virtual collabortion around Q3
   ... we could flush out a lot of details at TPAC, looking at the
   resources I have i can spend maybe 20/30% of my time

   anssi: TPAC could be a good time to get CG in a stage that we
   want

   mark: I want to charter to be done relatively quickly, in q3 i
   want to have some public work out

   ted: i want to know what it means to have the charter done?

   anssi: there's a review period of 30 days, where you can take
   it to the lawyers

   ted: what's the standard working group review time?

   francois: usually 6 weeks

   anssi: for CG it's one month
   ... so the proposal is to extend review period to 6 weeks
   ... i think this is a good comment, because also on our side
   the lawyers want to look at the papers
   ... I think we can take that into consideration
   ... so that means we would have the CG charter done even
   earlier
   ... so lets figure out the timelin
   ... we have like roughly the summer months to come up with a
   charter, lets say by the end of juli

   francois: the process says it's at least 4 weeks, so we could
   do 6 weekds

   ted: realistically speaking 1 month is not enough

   mark: I think the WG timeline is mostly around getting the
   requirements for exiting CR figured out
   ... and then scoping the work and finish the testing, so I
   think it will mostly be driven by implentation

   anssi: there's often the workload on the specside, that it goes
   down after CR, so you do the testing and implementors provide
   input

   mark: as we ship new implementations we might get more
   feedback, i dont anticipate any new feature requirements

   anssi: so no one proposes new features at this time? so the
   expectation is to stabilise the existing charter
   ... the plan is to extend with 3 or 6 months

Mozilla's input to open protocol discussion

   -> [16]Mozilla's protocol draft for the Presentation API

     [16] https://wiki.mozilla.org/WebAPI/PresentationAPI:Protocol_Draft

   schien: it's a proposal for the open protocol that will be used
   in Firefox browser and FxOS TV
   ... the requirements listed in the document is a subset of the
   requirements listed by Mark this morning
   ... there is a little bit more details like name and server
   address
   ... there will be information about device capability because
   the resolution might be a factor in the decision the user will
   make
   ... also supported media type for remote playback api
   ... expose I/O capabilities, for example can be used for
   authentification
   ... idea borrowed from routers

   mark: for aspect, resolution and media types, is that for
   controllers to filter screens more aggressively or is it for UX
   purpose?

   schien: for remote playback, if we try to do the mirroring, it
   will use this information
   ... it might use that for filtering but it's not certain
   ... we want to expose the protocol version so we can figure out
   if the device is compatible and add new features later
   ... for service launching, we need to provide some application
   id and page url
   ... also information about the session such as presentation id
   and bootstrap information to establish the communication
   channel
   ... there are some controlling messages that might be used
   during the service launching phase
   ... like the channel between two end points like
   connect/disconnect
   ... for security, we need to do device authentification
   ... first approach is passcode verification and also j-pake
   procedure
   ... using the passcode, we can create a one time key on both
   ends

   yavor: would you enter the passcode once or every time?

   schien: if the device doesn't recognize the other device, it
   will show the passcode
   ... using the passcode and the TLS certificate, it can generate
   a one-time auth key that will be stored on both devices
   ... so next time the device connect to the TV, the hash of the
   key can be provided
   ... so that the TV will know that the device is known

   sicking: do you try to authenticate the phone to the tv, not tv
   to phone?

   schien: authentification is both end
   ... using the j-pake procedure, both sides authenticate each
   other
   ... for data encryptions, the control channel using TLS

   is/the control channel using/the control channel is using/

   mark: in this proposal there will be up to two channels? one is
   TCP and the other is UDP?

   schien: the second is the same as webrtc

   mark: what's the reliability vs the control channel?

   schien: the control channel is for device availability query
   and [...]
   ... for data integrity, there is no need to do more because
   it's already using TLS and DLS
   ... [shows diagram of architecture and describes it]
   ... closing the communication is not trivial
   ... the control channel can only be established between the
   controller and the receiving side
   ... if the presenting context tries to close the communication
   channel, there will be no mechanism for the receiving side to
   notify the controlling side
   ... why the channel is being closed
   ... in presentation api, there is different close reasons, one
   is normal close another one is went away

   mark: you can make it in two phases, there is closing the
   connection and if there is no use for the data channel, it can
   be closed
   ... if you close the channel without telling the other side
   why, you have that issue
   ... but then, it will seen as a network disconnect
   ... you should send a message sending why before

   yavor: is the control channel open at this point?

   mark: it would have to use the communication channel

   schien: send the reason on the communication channel

   mark: it would have to send a special message to say this is a
   hang up, not a message for the page
   ... or alternatively, reopen the control channel, send the
   message and close it

   sicking: why do we need two channels?

   schien: the control channel is for UA to talk to each other
   ... while the communication channel is for browsing context
   ... I try to avoid multiplexing but not sure if worth it

   sicking: can't we set up a new channel when creating a new
   context on the tv?
   ... you send a control message first then that channel is used
   as a communication channel

   schien: in this case, we need to define a message format for
   delivering the messages

   mark: our track record of implementations is that there is
   almost 1 communication between Chrome and the Cast device

   yavor: is it possible that it is coming from how webrtc works?
   ... it will require signaling before connection

   schien: that's one reason that we need to establish a control
   channel
   ... different from the communication channel

   mark: our experience is that it's all one channel
   ... and some messages are treated as communication messages and
   some as control messages
   ... I believe there are some benefits of using data channels,
   for example, if we want to focus on scenarios not in a LAN
   ... it might behave better when WiFI is flaky
   ... those are potiential reasons but we decided not to go that
   way

   sicking: another approach is to have webrtc to be the low level
   communiaction channel and we send message trough webrtc
   ... the first control message is based on webrtc
   ... basically, the presentation api's protocol is layered on
   top of webrtc

   schien: unfortunately, webrtc can't be the first connection
   established
   ... you need a control channel to bootstrap webrtc

   sicking: should we use something than webrtc then?

   mark: in my opinion, webrtc shouldn't be mandatory
   ... unless there is a use case that specifically requires
   webrtc

   schien: the reason why I do that is because on the API side, we
   can pick between plain text and binary data
   ... it already defines the data format for delivering plain
   text/binary data over the same channel
   ... otherwise, we will have to redefine this for our own
   message format

   sicking: we can use web socket?

   mark: there are alternative like web sockets indeed

   schien: that's the details we can discuss in the CG
   ... if you want more details on the proposal, you can check the
   wiki
   ... I will keep it updated

   anssik: are schien and sicking working together? is flyweb
   using this work?

   sicking: we don't use this in flyweb
   ... we only use http and web sockets
   ... for discovery, we use mdns
   ... there is very little to re-use apart from the discovery
   part
   ... even that sounds challenging if it's going to use a
   passcode because we expect devices without screens to work with
   flyweb
   ... I'm a little bit uncertain if that code typing is actually
   practical
   ... my concern is that device makers optimize for UX and typing
   code is good for security but not practical

   mark: there are different modes you can pick
   ... you can do a visual verification instead of typing the code
   ... most users will bypass but that will solve the security

   sicking: even typing the code sounds insecure because one could
   make the smart tv show anything if you are MIM the TV
   ... both of those things are non starters to me
   ... Though, the more stuff we have, the harder it is to hack

   anssik: I see three sets of requirements: mark, schien and
   flyweb
   ... what can we do for standardization?

   sicking: I can see an optional security feature that may or may
   not be used for discovery and it will be up to the device

   mark: I anticipate the authentification to be the hardest part
   ... I believe we can find a good compromise but we might not
   have an answer soon
   ... I'm okay moving forward with other piecies in the meantime
   ... One requirement that isn't clear is whether WebRTC is a
   hard requirement
   ... I would prefer to avoid that for reasons stated earlier

   yavor: for us, establishing secure channel is all we need
   ... it's sound challenging
   ... whatever secure channel technology works reliably and we
   can do bi-directional communication, it is good for us

   sicking: are there high performance use cases requiring UDP
   sockets

   yavor: not right now, we will not send videos or key strokes
   ... there is play controls but no game levels interactions
   ... we mostly send commands and updates
   ... it's basically more like a chat
   ... in this model, what's the receiver page? the TV or a page
   on the TV?

   mark: the charter should be clearer but we are not trying to do
   an app to app authentification
   ... so the only guarantee is that you talk to a server that we
   trust

   yavor: if we establish some trust, is this trust valid for all
   sessions that are initiated with that tv or only the time frame
   of this page?

   mark: I think the idea is that the keys will have to be
   regenerated regularly

   yavor: with the flyweb model it's different because you auth
   with a page
   ... not with the tv, with actually short lived

   sicking: one you established the identity of the other side
   once, can you guarantee that it will stay true for the session?

   mark: yes, unless you navigate

CG rechartering

   mark: The charter is work in progress.
   ... Reiterate what are the goals.
   ... Pitch to browser vendors to move towards standardization.
   ... If our work is successful we should discuss what is the
   proper way to standardize.

   tidoust: IETF is proper way to go.

   anssik: What is the W3C position?
   ... The websocket is a good example.

   <tidoust> ACTION: Mark Foltz to look into software licenses for
   prototype implementations in the CG [recorded in
   [17]http://www.w3.org/2016/05/25-webscreens-minutes.html#action
   07]

   mark: Background of the working group.
   ... Scope - 5 different use cases.
   ... Developing of open source protocol is in scope.

   sicking: Having issues with the working group producing code.
   ... Prototype level code is fine, but historically was bad.

   anssik: Take implementation feedback.
   ... What happened from WebRTC?

   mark: The backend is shared the presentation layer is separate.

   anssik: We need to update the language.

   mark: Out of scope is to define what the UserAgent should do.

   <anssik> clarification to out of scope:
   [18]https://github.com/mfoltzgoogle/cg-charter/pull/3/files

     [18] https://github.com/mfoltzgoogle/cg-charter/pull/3/files

   mark: UA-1 protocol is out of scope.

   sicking: I didn't consider that this group would do FlyWeb. I'm
   interested in Bluetooth though.
   ... The presentation API would allow not requiring switching a
   network.
   ... Defining bluetooth protocol may belong to different group.

   mark: We can look at the discovery and contact the relevant
   groups later.
   ... We are not adding backwards compatibility.
   ... There would be ways to implement vendor extensions.
   ... 1-UA is out of scope, localization and accessibility too.
   ... Deliverables are first specifications.

   anssik: What is the required format?

   <tidoust> ACTION: Mark to strike the Deliverables intro text
   and jump to the specifications list directly in the CG charter
   [recorded in
   [19]http://www.w3.org/2016/05/25-webscreens-minutes.html#action
   08]

   mark: 3 main sections: 1) Discovery 2) Protocol for 2-UA mode
   3) Protocol for creating and controlling remote playback.

   Edward: Don't constrain it.

   mark: Is conformance something that we care now?
   ... Interesting things: Some ways to use BLE, how to use NFC,
   having network traversal.

   anssik: It is good to have these listed.

   Edward: I have some concerns. Can we exclude this section from
   the scope.

   tidoust: Scope helps with patents and keeping the group
   focused.

   Eric: Just leave the first two lines without specifying
   concrete items.

   mark: ACTION: We would remove the items and just keep generic
   description.

   <anssik>
   [20]https://github.com/w3c/web-platform-tests/blob/master/LICEN
   SE

     [20] https://github.com/w3c/web-platform-tests/blob/master/LICENSE

   Edward: Test Suites is section is not clear.

   <hober>
   [21]http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyri
   ght.html

     [21] http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html

   mark: Build a test suites to measure if the prototype matches
   the spec.

   tidoust: I think we should strike the whole section.

   anssik: We can use the web platform tests instead.

   <scribe> ACTION: Mark to strike the test section. [recorded in
   [22]http://www.w3.org/2016/05/25-webscreens-minutes.html#action
   09]

   <anssik> CG charter template:
   [23]http://w3c.github.io/cg-charter/CGCharter.html

     [23] http://w3c.github.io/cg-charter/CGCharter.html

   mark: Merge pull requests add notes and do new pull request.

   anssik: We should figure out the timeline when to get all the
   feedback in.
   ... We have feedback from Ed that we may need 6 weeks.

   mark: I want to TPAC to be productive f2f.

   anssik: Beginning of August we can have final chapter approved.
   ... We are at the end of the day and we can wrap up.
   ... Thanks to Mark - the host and everyone from Google. Thanks
   to the new arrivals.
   ... We are getting close, and thanks to the feedback from the
   implementors.
   ... Some people may be concerned that there wasn't enough
   incubation.
   ... Let's keep up the momentum.
   ... Next f2f is in Portugal.

   <tidoust> [F2F adjourned]

Summary of Action Items

   [NEW] ACTION: Mark Foltz to look into software licenses for
   prototype implementations in the CG [recorded in
   [24]http://www.w3.org/2016/05/25-webscreens-minutes.html#action
   07]
   [NEW] ACTION: Mark to strike the Deliverables intro text and
   jump to the specifications list directly in the CG charter
   [recorded in
   [25]http://www.w3.org/2016/05/25-webscreens-minutes.html#action
   08]
   [NEW] ACTION: Mark to strike the test section. [recorded in
   [26]http://www.w3.org/2016/05/25-webscreens-minutes.html#action
   09]

   [End of minutes]
Received on Wednesday, 1 June 2016 07:58:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 June 2016 07:58:34 UTC