00:00:34 <cpn> Mark: For 1-UA mode, would Chrome and Firefox be required to produce distinct implementations of the Receiving UA?
00:01:16 <cpn> Anssi: If we have two browsers using Blink, these often don't qualify as two interoperable implementations
00:01:56 <cpn> ... We may not have specific language in the Charter to define the implementations
00:02:20 <cpn> ... [describes charter]
00:02:33 <cpn> ... There's some flexibility for us to decide
00:03:31 <cpn> Mark: For 1-UA, Chrome and/or Firefox could support wired displays
00:04:24 <cpn> ... For 2-UA mode we have a couple of options, but to open this up to other browser vendors would require the open protocol
00:05:07 <cpn> Francois: We can have columns with Chromecast and Firefox OS TV as receivers
00:05:35 <cpn> Mark: Is each vendor required to implement both modes?
00:05:47 <cpn> Francois: No, that's not a requirement
00:07:22 <cpn> Anssi: We can always refine the test suite and add more implementation data, adding more colums for different devices as senders and receivers
00:07:39 <cpn> ... It could be even more complex, with a matrix of senders and receivers
00:07:44 <cpn> s/colums/columns/
00:08:49 <cpn> Anssi: Some vendors could only implement the sender, others only the receiver, this is one of the goals of the open protocol work
00:09:40 <cpn> Francois: I proposed to draft exit criteria
00:10:17 <cpn> Action: Francois to craft exit criteria for PR status
00:10:40 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
00:11:34 <cpn> Louay: To run some presentations on Google Cast we need to register in the Cast console, then use an ID as a hash parameter in the URL
00:12:15 <cpn> ... [describes test] https://github.com/w3c/web-platform-tests/pull/3062/files
00:16:15 <cpn> ... [discussion of Google Cast app ID and client ID values]
00:16:44 <cpn> Zhiqiang: We should also use the relative URL in our test suite
00:17:34 <cpn> Louay: Are relative URLs supported in Google Cast?
00:17:47 <cpn> Mark: I believe so, but you'd have to try it
00:19:17 <cpn> Louay: Do we need to include some Cast receiver library in the receiver page?
00:19:47 <cpn> Mark: I believe you need to include the SDK and initialise it
00:20:24 <cpn> Louay: Is there a specific name used for the communication channel?
00:21:02 <cpn> Mark: You can make up a name and sent it across, I can share some docs on how to do that
00:21:43 <cpn> Louay: Another question for Mozilla: Is there any way to run these tests on Firefox, what receiver devices can we use?
00:22:24 <cpn> schien: The receiver part is only on Firefox TV, so not available right now
00:23:35 <cpn> schien: Our plan is to ship the 1-UA mode in Firefox for Android, then in September open up the 2-UA mode for Firefox for Android and Firefox TV
00:24:07 <cpn> Louay: We need at least one implementation to make sure our tests work
00:24:34 <cpn> ... We're currently working on testing in Chrome
00:24:46 <cpn> ... I may need more information when we look at messaging
00:25:09 <cpn> ... For the current features: availability, connect, launch, we're fine testing in Chrome
00:25:32 <cpn> Anssi: Do the IDL tests currently match the latest editor's draft?
00:26:18 <cpn> Louay: Our last report wasn't on the latest draft, but I'll take another snapshot for the next test report
00:26:28 <cpn> ... Extracting the IDL from the spec is automated
00:26:45 <cpn> Anssi: What kind of test suite is needed for CR?
00:27:01 <cpn> Francois: We need a plan, but there's no requirement for a preliminary test report
00:27:23 <cpn> Mark: Do you run the tests on both Chrome desktop and Chrome Android?
00:27:26 <cpn> Louay: Yes
00:27:50 <cpn> ... "CA50" indicates Chrome Android and "CD50" Chrome desktop
00:28:23 <cpn> Anssi: Maybe add a legend to expand these names
00:29:36 <cpn> Louay: The WPT has a readme file in each folder, where we describe the names
00:29:50 <cpn> Anssi: Thanks for all the work you've done
00:30:00 <cpn> ... It looks like we have what we need for PR
00:30:23 <cpn> .. We should keep up the speed and momentum
00:30:50 <cpn> Louay: We'd like to have more contributors for testing, I currently have two students working on it
00:31:10 <cpn> ... available until the end of July
00:32:12 <cpn> Anssi: Hyojin, could the xxx project contribute tests?
00:32:16 <cpn> Hyojin: I'll check with the person in charge and contact Louay
00:32:52 <cpn> Zhiqiang: I have another person joining me to contribute tests
00:33:07 <cpn> Anssi: So there are 5 people now working on testing
00:33:16 <hyojin> s/xxx/WAVE
00:33:50 <cpn> Louay: I'm not sure about the dates to target
00:34:56 <cpn> Anssi: Any other topics for testing?
00:35:57 <cpn> Action: Loauy to verify the URL issue is fixed in Chrome canary v5.3
00:36:25 <cpn> Action: Mark to send Louay documentation on how to send messages to receiver apps
00:37:14 <cpn> Action: Everyone review the tests
00:37:55 <cpn> Anssi: Any other topics?
00:38:58 <cpn> Francois: There are still some open issues in GitHub to go through, looking those tagged as Enhancement
00:39:31 <cpn> ... There a 5 issues, four are P3
00:40:50 <cpn> Francois: Are we OK to address this in a future spec version?
00:41:34 <cpn> Anssi: I suggest changing the Enhancement tag to V2
00:42:58 <tidoust> i/Francois: There are still some open issues/Topic: Remaining issues/
00:43:52 <cpn> Francois: What needs to be done for #242?
00:44:11 <cpn> Mark: It's not a spec issue, I took an action to do this a while ago
00:44:21 <cpn> Francois: #283 error handling
00:45:42 <cpn> Mark: There's detail in step 5, can be put into a pull request
00:46:33 <cpn> Action: schien to send a pull request to define error handling on failure to establish presentation connection (#283)
00:47:11 <cpn> Francois: I think #293 has been done?
00:47:37 <cpn> Mark: It's still open from the previous pull request
00:48:23 <cpn> Action: Mounir to resolve #293
00:49:49 <cpn> Francois: #295 - references - I'm not sure if we can reference the WHATWG spec
00:50:40 <cpn> Mounir: The Remote Playback API currently only references WHATWG
00:50:50 <cpn> Francois: That's fine for now
00:51:09 <cpn> ... It's only when we get to CR and PR that we need stable references
00:51:52 <cpn> Francois: #299 Instead of patching HTML in our spec, we should propose a change to the HTML spec
00:59:21 <sicking> sicking has joined #webscreens
01:01:07 <cpn> [ -adjourned- ]
01:07:54 <tidoust> RRSAgent, draft minutes
01:07:54 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
01:09:45 <tidoust> RRSAgent, this meeting spans midnight
01:10:00 <tidoust> RRSAgent, draft minutes
01:10:00 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
04:46:15 <mounir> mounir has joined #webscreens
05:25:47 <ricksmit> ricksmit has joined #webscreens
05:38:23 <mounir> mounir has joined #webscreens
05:46:38 <sicking> sicking has joined #webscreens
05:57:50 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
11:26:08 <ricksmit> ricksmit has joined #webscreens
15:55:45 <RRSAgent> RRSAgent has joined #webscreens
15:55:45 <RRSAgent> logging to http://www.w3.org/2016/05/25-webscreens-irc
15:55:46 <sicking> sicking has joined #webscreens
15:56:22 <tidoust> Meeting: Second Screen WG F2F - Day 2
15:56:25 <tidoust> Chair: Anssi
15:56:45 <anssik> anssik has joined #webscreens
15:59:27 <tidoust> Present+ Anssi_Kostiainen
15:59:30 <tidoust> Present+ Mark_Foltz
15:59:48 <tidoust> Present+ Mounir_Lamouri
15:59:57 <tidoust> Present+ Rick_Smit
16:00:06 <yavor> yavor has joined #webscreens
16:00:07 <tidoust> Present+ Hyojin_Song
16:00:14 <tidoust> Present+ Chris_Needham
16:00:25 <tidoust> Present+ Shih-Chiang_Chen
16:00:38 <tidoust> Present+ Yavor_Goulishev, Francois_Daoust, Jonas_Sicking
16:00:45 <tidoust> Present+ Ed_Connor
16:04:29 <tidoust> Present+ Eric_Carlson
16:04:38 <tidoust> scribe: Francois
16:04:42 <tidoust> scribenick: tidoust
16:05:45 <eric_carlson> eric_carlson has joined #webscreens
16:06:41 <tidoust> Topic: Welcome to day 2
16:06:57 <tidoust> Anssi: We parked an issue that arose at a spin-off of issue #153
16:08:03 <tidoust> ... Problem is with the presentation URL that may contain additional proprietary parameters that get used instead of the URL itself.
16:08:15 <tidoust> Topic: Presentation request URL issue
16:08:46 <tidoust> Mark: A bit of history. There was strong pushback initially against supporting non HTTP/HTTPS schemes.
16:09:10 <tidoust> ... We found a workaround to allow to pass additional parameters
16:09:49 <tidoust> ... I looked at the code. There is very little probability that the extra parameters might collide with existing fragment identifiers.
16:10:24 <tidoust> ... Another concern was around what would happen if developers use the URL with other implementations.
16:10:34 <tidoust> ... Again, that's not going to do much.
16:12:36 <tidoust> ... One use case is to enable capability detection to allow developers to assert that a specific URL will be supported.
16:13:11 <tidoust> ... Instead of passing a list, a wrapping library could be used that tries the different URLs in turn.
16:15:28 <tidoust> ... We can mix Cast parameters and DIAL parameters. The beginning of the HTTP URL itself will be used for the 1UA case.
16:15:31 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
16:15:40 <tidoust> Anssi: This suggests no change to the spec.
16:16:01 <tidoust> ... Based on implementation experience, we can probably revisit this later on.
16:16:31 <tidoust> ... If we publish a CR and realize that we need to change this, we can republish another CR. That will add another delay.
16:16:55 <tidoust> Jonas: I think that we have strong evidence that what we have now does not work.
16:17:10 <tidoust> ... You're passing a URL but you're not treating it as passing parameters.
16:17:44 <tidoust> s/not treating/treating/
16:18:10 <tidoust> Jonas: You want a Cast identifier, and since the API only takes a URL, you work around that.
16:18:31 <tidoust> ... You're forced by the API to hack it.
16:19:26 <anssik> https://w3c.github.io/presentation-api/#user-interface-guidelines
16:21:22 <tidoust> 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.
16:21:49 <tidoust> Mounir: Yes, as soon as the spec suggests to use the URL, then it's not an opaque string anymore
16:22:28 <tidoust> Jonas: The semantics of this URL parameter is "load this URL onto the second screen", and that's not what you're doing.
16:22:53 <tidoust> Mark: It seems we're discussing implementation internals. What's the difference in practice?
16:23:46 <tidoust> Jonas: It makes a lot of differences. [analogy with fetch]
16:24:17 <tidoust> ... If you are interpreting the values differently from what the specification suggests, then you're not following the spec.
16:24:48 <tidoust> Ed: Where's the interop if the URL is interpreted differently by different implementations.
16:25:38 <tidoust> 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.
16:26:04 <tidoust> Mark: The meaning of the URL depends on the target device.
16:26:32 <tidoust> Jonas: The spec says to fetch the URL.
16:26:46 <tidoust> ... You're subverting the spec.
16:27:44 <tidoust> ... With "Navigating to an HTTP URL", the expectation is that you'll follow the HTTP protocol to download the resource.
16:28:13 <tidoust> ... If it redirects to other schemes, then so be it, but that's not what happens here.
16:28:36 <tidoust> Mark: Do you have a concrete proposal, then?
16:28:54 <tidoust> Jonas: You need an ability to say "please load this Cast app".
16:29:01 <tidoust> ... It should be something other than HTTP.
16:30:17 <tidoust> Mark: Your concrete proposal is that we require another scheme? Can the backend redirect to the cast scheme?
16:30:20 <tidoust> Jonas: Yes.
16:30:44 <tidoust> 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.
16:32:02 <tidoust> 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.
16:32:28 <tidoust> ... You can do that for URL spaces that you own, you cannot do it for other domains.
16:33:57 <tidoust> ... 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.
16:34:37 <tidoust> Mark: We can certainly construct these cast URLs behind the scenes. That will probably not impact the spec itself.
16:35:03 <tidoust> 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.
16:36:07 <tidoust> 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.
16:37:06 <tidoust> Francois: The spec does say to "navigate to the presentation request URL", so not sure we need something on top of that.
16:37:53 <tidoust> Jonas: My argument is that you can only control redirects for domains you control, not for others.
16:37:56 <sicking> sicking has joined #webscreens
16:38:40 <tidoust> SC: Question is how would this work with Firefox's implementation of the Presentation API.
16:39:05 <tidoust> Mark: This is really a vendor extension that should not be added to other calls.
16:39:39 <tidoust> 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.
16:39:56 <tidoust> ... We can do that much more easily if it's a cast:// scheme.
16:40:41 <tidoust> ... 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.
16:41:37 <tidoust> 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.
16:43:09 <tidoust> SC: For Firefox OS, we use app:// scheme to launch native apps. For generic content, it uses HTTP.
16:43:22 <tidoust> Mark: So we have a use case for fallback.
16:43:25 <tidoust> Jonas: Yes.
16:44:08 <tidoust> ... If things converge in the future, I can imagine that things converge on HTTP, we'll just ignore the rest.
16:45:18 <tidoust> Anssi: So you want an explicit extension mechanism.
16:46:03 <tidoust> Jonas: Yes.
16:46:46 <tidoust> Anssi: We don't yet have consensus it seems. I'd like not to block the spec today.
16:49:01 <tidoust> Francois: Also wondering about the relationship between URLs in the array. They may not be related.
16:49:35 <tidoust> Ed: Not a problem. That would match the API contract: the ability to pass multiple possibilities.
16:49:55 <tidoust> Francois: OK, same thing as for <video> sources now that I come to think about it.
16:52:02 <tidoust> [discussion on google.com/cast and cast:// scheme]
16:52:49 <tidoust> Mark: Let's try to separate the discussion between separating namespaces which I agree with, and the fallback mechanism.
16:53:41 <tidoust> Jonas: Adding a new protocol is a significant easier thing to do than changing the semantics of HTTP.
16:54:04 <tidoust> ... In the end, my summary is that I think that you're doing right now is not per specification.
16:54:55 <tidoust> 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.
16:57:02 <tidoust> SC: A specific scheme will help implementations detect early that the URL won't be supported.
16:57:55 <tidoust> Mark: We need to have clarity on the fallback mechanism. We plan to support the 1UA case soon.
16:58:15 <tidoust> Jonas: APIs that take either a string or a list of strings exist, no problem with that.
16:58:50 <tidoust> Mounir: Do you guys support 1UA?
16:59:24 <tidoust> SC: Yes, planned for September. 1UA is only for HTTP.
16:59:51 <tidoust> ... If the controlling app passes a non HTTP URL, it will be discarded.
17:00:01 <tidoust> Mounir: So you need the fallback mechanism too.
17:01:27 <tidoust> Anssi: So concrete spec changes?
17:01:49 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
17:02:46 <tidoust> 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.
17:03:26 <tidoust> Anssi: What is the impact on the implementation?
17:03:37 <tidoust> Mark: Will need to get back to you on that.
17:04:24 <tidoust> Jonas: Some of what is need already happens anyway.
17:04:37 <tidoust> Mark: Yes, it's more the plumbing in-between.
17:04:45 <tidoust> ... And there's also a UX impact.
17:07:43 <tidoust> 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.
17:08:04 <tidoust> s/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./
17:08:21 <tidoust> 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.
17:08:42 <tidoust> RRSAgent, draft minutes
17:08:42 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
17:10:34 <tidoust> Anssi: Good, moving on.
17:11:11 <tidoust> Topic: Open protocol
17:11:14 <tidoust> scribe: Rick
17:11:17 <ricksmit> scribeNick: ricksmit
17:11:42 <ricksmit> mark: prepared discussion for rechartering community group
17:11:57 <ricksmit> mark: put togheter pull request
17:12:07 <ricksmit> .. interesting discussions about scope deliverables
17:12:36 <ricksmit> ... little bit of history, CG started 2013
17:12:51 <ricksmit> ... input from Netflix, Mozilla, Goolge
17:13:30 <ricksmit> ... ansi checked in boilerplate charter
17:14:13 <tidoust> i/Mark: For 1-UA mode, would Chrome and Firefox be/scribe: cpn/
17:14:16 <tidoust> RRSAgent, draft minutes
17:14:16 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
17:16:58 <ricksmit> ... 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
17:18:11 <ricksmit> ... personally I think prototyping is helpful, if I have the resources I would like to build open source resources
17:20:06 <ricksmit> ... 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
17:20:42 <ricksmit> ... data that is passed between ua's should be secure
17:22:09 <AntonVayvod> AntonVayvod has joined #webscreens
17:23:32 <ricksmit> ... one thing we may want to include is provide a way for vendor extension. Seems that there is some pushback for vendor extensions
17:24:08 <ricksmit> Francois: what woudl the CG define?
17:25:00 <ricksmit> Mark: extension points for vender extensions
17:25:39 <ricksmit> yavor: for dial there's nothing we can use, for that point we need a propietary extension that supports playback controls
17:26:48 <ricksmit> ... 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.
17:28:15 <ricksmit> mark: the existing messaging for api is designed to handle this, like volume control
17:28:35 <ricksmit> ... for now I like to keep it really generic and understanding the use cases more
17:30:01 <ricksmit> Jonas: so for talking to a html application there's messaging for remote playback, for dial that doesn't exist?
17:31:47 <ricksmit> javor: so you can have applications that have messaging both ways?
17:31:54 <ricksmit> mark: yes
17:31:57 <ricksmit> yavor: that's great
17:32:28 <ricksmit> mark: I think a lot of these things are not we don't want to do, but maybe not have a high priority
17:33:54 <ricksmit> .. webrtc is not great for doing local area screencast, we're working on it
17:35:52 <ricksmit> 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
17:36:06 <ricksmit> ... how does chromecast handle that?
17:36:17 <ricksmit> mark: they send a url to the player and player handles it
17:36:51 <ricksmit> jonas: what I'm curious about would it make sense for the protocol support sending user credentials
17:36:59 <ricksmit> mark: I think that's sensible to do
17:37:15 <ricksmit> ... we want to make it easy for the url to be fetched
17:37:40 <ricksmit> jonas: what im thinkgin about is supporting a netflix dial application where you send user credentials to the app
17:39:05 <ricksmit> mark: you cant pass a license from one device to another, that's by design
17:39:35 <ricksmit> ... out of scope is also interactive presentations, interesting for gaming
17:40:13 <ricksmit> jonas: Im curious how important an unreliable channel is
17:40:28 <ricksmit> mark: I think gaming, they want a low latency
17:40:32 <ricksmit> ... couple of ms
17:40:58 <ricksmit> ... we have our chrome desktop team who is working on this and I could check with them how to handle this
17:41:44 <ricksmit> .. open question: accesibility, to have screenreader work across controller and receiver
17:42:48 <ricksmit> anssi: I would leave accessibility out of the scope
17:43:29 <ricksmit> mark: require display access control, like a password, now anyone can access the display
17:44:11 <ricksmit> in the past we also discussed the propagating origin information, so the TV nows what's the origin sending it
17:44:21 <ricksmit> mark: in the past we also discussed the propagating origin information, so the TV nows what's the origin sending it
17:45:58 <ricksmit> anssi: display capabilities was a controversial part of the api
17:46:54 <ricksmit> 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.
17:47:44 <ricksmit> jonas: on capabilities, one use case im interested in is something like supporting chromecast audio
17:48:31 <ricksmit> ... 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
17:49:27 <ricksmit> mark: what we do now is give the user info over the device
17:49:39 <ricksmit> ... so if it's audio show a little speaker icon
17:49:52 <ricksmit> anssi: is it an implementation detail?
17:50:21 <ricksmit> 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
17:50:38 <ricksmit> mark: you would have to tell the app that it's video content
17:50:53 <ricksmit> anssi: you still might want to override that
17:51:19 <ricksmit> jonas: maybe audio only vs video only could be a baselevel thing
17:52:35 <ricksmit> anssi: what is chromes way, is it like a prompt that tells you which devices you have?
17:52:55 <ricksmit> mark: the ux seems to have changed
17:53:10 <ricksmit> anssi: this is a point where people are struggeling with
17:53:36 <ricksmit> yanvor: does the application knows what to expect on the other side?
17:54:19 <ricksmit> mark: we decided that the app could feature detect what the device could do
17:54:33 <ricksmit> francois: when the user enters an url the website will detect
17:55:54 <ricksmit> mark: the requirements fall out of scope that i discussed earlier
17:56:21 <ricksmit> ... i think its important from ux point of view to know if it's avialable or in use
17:57:39 <ricksmit> jonas: so when you show the device picker it shows "jonas tv currently playing netflix" or something?
17:57:45 <ricksmit> mark: yes exactly
17:58:06 <ricksmit> ... we had discussions about power saving, this should also go for tv's
17:58:32 <ricksmit> yanvor: do you want to support wakeup lan?
17:59:37 <ricksmit> mark: we're discussing requirements so it would be a feature request
18:01:20 <ricksmit> ... connection is pretty similar to the scope discussions, displays should be able to deny connections
18:01:52 <ricksmit> anssi: reconnection is now part of application logic
18:02:04 <ricksmit> mark: an important part of the spec would be the connection lifecycle
18:02:10 <tidoust> RRSAgent, this meeting spans midnight
18:03:31 <ricksmit> mark: it's important to allow presentation from secure context, to have strong encryption, there are a number of approaches to handle this
18:04:11 <ricksmit> jonas: it's impossible to guarantee that you connect to the device that you're trying to connect to
18:04:42 <ricksmit> ... at no point you have a secure communication channel, you have to decide which parts you trust
18:06:29 <ricksmit> mark: the solution is in public key I think, and trust model
18:07:34 <ricksmit> mark: what do we have to support on the protocol level?
18:08:23 <ricksmit> ... query command, give the url an id, multiplex like multiple browsing context, passing locale for rendering display
18:11:19 <mfoltzgoogle> Presented slides: https://docs.google.com/presentation/d/1s_ZShYTKArSkXwjHRGpf8HBQaRweOi9H0fgd94I9mOw/edit?usp=sharing
18:19:45 <eric_carlson> eric_carlson has joined #webscreens
18:30:43 <ricksmit> ricksmit has joined #webscreens
18:31:03 <ricksmit> ricksmit has joined #webscreens
18:33:42 <tidoust> RRSAgent, draft minutes
18:33:42 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
18:33:47 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
18:36:57 <ricksmit> jonas: this is a presentation that I wrote for people a little less familiair with this topic
18:37:08 <ricksmit> ...flyweb is a project we're working on at mozilla
18:37:21 <ricksmit> mounir: like indexdb?
18:37:26 <ricksmit> jonas: yes like indexdb
18:37:29 <tidoust> i/jonas: this is a presentation/Topic: FlyWeb presentation/
18:37:57 <mounir> s/like indexdb/like b2g/
18:38:50 <ricksmit> ... 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
18:39:55 <ricksmit> 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
18:40:01 <ricksmit> ...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
18:40:41 <ricksmit> ...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
18:41:01 <ricksmit> ...so what we want to do is use the fact that the web is really good at on demand application delivery
18:41:40 <ricksmit> ...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
18:41:50 <tidoust> RRSAgent, draft minutes
18:41:50 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
18:42:08 <ricksmit> ...apps are really nice to show ui's but the installation and authentication are less nice
18:43:06 <ricksmit> ...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
18:43:34 <ricksmit> if we forget these assumptions, servers can be on any device, can talk over other transports discoverable vial locale
18:43:38 <ricksmit> ...if we forget these assumptions, servers can be on any device, can talk over other transports discoverable vial locale
18:45:14 <ricksmit> 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
18:46:13 <ricksmit> ...another thing we want to do is enabling p2p use cases, like phone to phone or desktop to desktop
18:46:38 <ricksmit> ... if i have browsed to a website, that website can turm my phone in a flyweb server, a discoverable server
18:47:46 <ricksmit> ... we have this working
18:48:07 <ricksmit> ... not production quality, it's not like we're working an actual implementation but so far it seems to be working well
18:48:26 <ricksmit> ... we use mdns to enable discover, and we can also the http request and websocket connections over the network
18:48:48 <ricksmit> ...we have some basic ui to scan for nearby devices and launch them
18:48:57 <ricksmit> ...our hope is to land within the next couple of weeks
18:49:39 <ricksmit> ...what we have right now is that is should all be encrypted
18:50:24 <ricksmit> ...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
18:51:13 <ricksmit> anssi: can i give my friend a flyweb url and he can click that and then gets this page?
18:51:23 <ricksmit> jonas: I dont know where' we're going to end up on that
18:51:33 <ricksmit> ...I have desktop builds where it should be working
18:51:43 <eric_carlson> eric_carlson has joined #webscreens
18:51:56 <ricksmit> anssi: so you have a spec for flyweb? Do you have plans to move that spec for further incubation?
18:52:07 <ricksmit> jonas: there are still things we're figuring out
18:53:17 <ricksmit> anssi: so you said you're using mdns, so that's the protocol of choice?
18:53:29 <ricksmit> jonas: it's up to debate but we're trying to reuse as much as possible
18:53:38 <ricksmit> mark: are using bluetooth for messaging?
18:54:03 <ricksmit> jonas: the idea is that we can do messaging over different transports, we havent done bluetooth yet
18:54:49 <ricksmit> ...so this is http right now, but it should also work with https over tls
18:55:19 <ricksmit> ...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
18:56:02 <ricksmit> ...the client api is super simple, you can use xhr or a websocket and then you can do the normal stuff
18:56:50 <ricksmit> mounir: why not using service workers?
18:57:19 <ricksmit> jonas: service workers is for running stuff in the background, at the moment this is not supposed to work in the background
18:58:14 <ricksmit> ...all we do is fire a fetch event, you can either create a response object from scratch or fetch resources or do whatever
18:59:01 <ricksmit> ...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
18:59:17 <ricksmit> ...there are like 1 or 2 interfaces that are new
19:00:01 <ricksmit> ...we need to define how discover works, so it could work across browsers
19:00:22 <ricksmit> ...so the network protocols should be defined, like mdns and http
19:00:36 <ricksmit> yanvor: how do you deploy private keys for the certifcates?
19:01:32 <ricksmit> 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
19:01:55 <ricksmit> ...we remember the certificate and associate it with an url name
19:03:30 <ricksmit> francois: from a ux perspective, do you prompt the user?
19:03:37 <ricksmit> jonas: this isn't implemented yet
19:03:57 <ricksmit> ...the idea is that when a website wants to publish a server that we'll ask the user are you ok with this website
19:04:30 <ricksmit> mark: can do server website find out the url?
19:05:09 <ricksmit> jonas: there might be reasons why the server wants to know it's own url
19:05:24 <ricksmit> ...but we havent actually had the need for that, most cases just serve relative urls
19:06:54 <ricksmit> ...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
19:07:07 <ricksmit> mark: it goes both ways, to the publication could publish a remote control app
19:07:24 <ricksmit> yanvor: does it matter which side is the server for WS
19:07:32 <ricksmit> jonas: for a UI it matters
19:08:50 <ricksmit> ... the next thing we're going to look at to support is bluetooth, but also NFC is somethign we're looking at
19:11:28 <ricksmit> ...there are several areas where we can still expand this
19:12:48 <ricksmit> anssi: we could message this in the CG scope
19:12:56 <ricksmit> jonas: this is still in very early stage
19:13:20 <ricksmit> anssi: if there's a reasonable overlap it sounds like a good idea, if we dont get huge scope expansion
19:13:33 <ricksmit> jonas: I dont think it would make sense to have flyweb go through the second screen WG
19:14:00 <ricksmit> francois: right now it's not in scope, but the WG might have to recharter, so it might be a window of oppertunity
19:14:22 <ricksmit> jonas: there need to be two interested parties, and dont know if Google is interested
19:14:45 <cpn> cpn has joined #webscreens
19:14:46 <ricksmit> ...one thing that i think would be useful into presentation api is the idea that a webpage could be a webserver
19:15:15 <ricksmit> ...instead of giving an url say get back to me and tell the device to get back to the controller
19:15:34 <tidoust> s/might have to recharter/will have to recharter end of October/
19:16:01 <ricksmit> anssi: so jonas you had a timeline?
19:16:08 <ricksmit> jonas: we're landing the code end of this quarter
19:16:30 <ricksmit> ...and you would have to go into config and turn it on
19:16:47 <ricksmit> anssi: when would you be interested to push this to a Community Group?
19:17:23 <ricksmit> jonas: I cant give a good estimate because it would be other people doing it
19:18:34 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
19:20:24 <ricksmit> jonas: 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
19:21:43 <ricksmit> ...we struggled a lot with the security on the web vs security on native because it's very different
19:21:51 <ricksmit> ...but the challenges are very similair
19:21:58 <ricksmit> ...and I think we can get it as good as native
19:22:23 <ricksmit> ...relatively easy we can incrementally make it more secure over time
19:23:50 <ricksmit> 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
19:26:08 <ricksmit> 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
19:26:23 <ricksmit> mark: I know you also want to support BT and potentially WS
19:26:50 <ricksmit> ...and then if you want to add extension that would be perfectly acceptable to
19:27:07 <ricksmit> anssi: if you have resources to share, could you please add them to the minutes
19:27:22 <ricksmit> jonas: there's a github repo but it's very out of date
19:27:33 <ricksmit> mark: you do have IDL checked in right?
19:27:40 <ricksmit> jonas: yeah it has IDL baked in
19:28:04 <ricksmit> ...I'll past the url of our project page
19:28:07 <sicking> flyweb project page. Often out-of-date: https://wiki.mozilla.org/FlyWeb
19:28:56 <ricksmit> jonas: it's mainly for us internally and has stuff that's not really relevant
19:29:19 <ricksmit> anssi: so what is your timeline for the CG?
19:29:59 <ricksmit> mark: I have some early drafts for some of the protocol stuff, I like to start the virtual collabortion around Q3
19:30:34 <ricksmit> ...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
19:30:50 <ricksmit> anssi: TPAC could be a good time to get CG in a stage that we want
19:31:15 <ricksmit> mark: I want to charter to be done relatively quickly, in q3 i want to have some public work out
19:31:43 <ricksmit> ted: i want to know what it means to have the charter done?
19:32:19 <ricksmit> anssi: there's a review period of 30 days, where you can take it to the lawyers
19:32:35 <ricksmit> ted: what's the standard working group review time?
19:32:42 <ricksmit> francois: usually 6 weeks
19:32:50 <ricksmit> anssi: for CG it's one month
19:33:52 <ricksmit> ...so the proposal is to extend review period to 6 weeks
19:34:37 <ricksmit> anssi: i think this is a good comment, because also on our side the lawyers want to look at the papers
19:34:46 <ricksmit> ...I think we can take that into consideration
19:34:55 <ricksmit> ...so that means we would have the CG charter done even earlier
19:35:02 <ricksmit> ...so lets figure out the timelin
19:36:01 <ricksmit> anssi: we have like roughly the summer months to come up with a charter, lets say by the end of juli
19:36:28 <ricksmit> francois: the process says it's at least 4 weeks, so we could do 6 weekds
19:36:45 <ricksmit> ted: realistically speaking 1 month is not enough
19:38:37 <ricksmit> mark: I think the WG timeline is mostly around getting the requirements for exiting CR figured out
19:39:01 <ricksmit> ...and then scoping the work and finish the testing, so I think it will mostly be driven by implentation
19:39:34 <ricksmit> anssi: there's often the workload on the specside, that it goes down after CR, so you do the testing and implementors provide input
19:40:06 <ricksmit> mark: as we ship new implementations we might get more feedback, i dont anticipate any new feature requirements
19:40:36 <ricksmit> anssi: so no one proposes new features at this time? so the expectation is to stabilise the existing charter
19:40:57 <ricksmit> ...the plan is to extend with 3 or 6 months
20:12:26 <ricksmit> ricksmit has joined #webscreens
21:13:37 <sicking> sicking has joined #webscreens
21:16:04 <tidoust> tidoust has joined #webscreens
21:16:25 <eric_carlson> eric_carlson has joined #webscreens
21:16:46 <ricksmit> ricksmit has joined #webscreens
21:18:26 <tidoust> Topic: Mozilla's input to open protocol discussion
21:18:33 <tidoust> RRSAgent, draft minutes
21:18:33 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
21:19:23 <schien> https://wiki.mozilla.org/WebAPI/PresentationAPI:Protocol_Draft
21:19:46 <tidoust> scribe: mounir
21:20:24 <mounir> schien: it's a proposal for the open protocol that will be used in Firefox browser and FxOS TV
21:20:53 <mounir> schien: the requirements listed in the document is a subset of the requirements listed by Mark this morning
21:21:16 <mounir> schien: there is a little bit more details like name and server address
21:22:04 <mounir> schien: there will be information about device capability because the resolution might be a factor in the decision the user will make
21:22:18 <mounir> schien: also supported media type for remote playback api
21:23:49 <mounir> schien: expose I/O capabilities, for example can be used for authentification
21:24:01 <mounir> schien: idea borrowed from routers
21:24:37 <mounir> mark: for aspect, resolution and media types, is that for controllers to filter screens more aggressively or is it for UX purpose?
21:25:10 <mounir> schien: for remote playback, if we try to do the mirroring, it will use this information
21:25:19 <mounir> ... it might use that for filtering but it's not certain
21:25:27 <cpn> cpn has joined #webscreens
21:25:55 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
21:26:32 <mounir> schien: we want to expose the protocol version so we can figure out if the device is compatible and add new features later
21:28:14 <mounir> schien: for service launching, we need to provide some application id and page url
21:28:31 <mounir> ... also information about the session such as presentation id and bootstrap information to establish the communication channel
21:28:44 <mounir> ... there are some controlling messages that might be used during the service launching phase
21:29:04 <mounir> ... like the channel between two end points like connect/disconnect
21:30:20 <mounir> schien: for security, we need to do device authentification
21:30:44 <mounir> ... first approach is passcode verification and also j-pake procedure
21:31:29 <mounir> schien: using the passcode, we can create a one time key on both ends
21:32:38 <mounir> yavor: would you enter the passcode once or every time?
21:32:51 <mounir> schien: if the device doesn't recognize the other device, it will show the passcode
21:33:12 <mounir> schien: using the passcode and the TLS certificate, it can generate a one-time auth key that will be stored on both devices
21:33:31 <mounir> ... so next time the device connect to the TV, the hash of the key can be provided
21:33:44 <mounir> ... so that the TV will know that the device is known
21:34:35 <mounir> sicking: do you try to authenticate the phone to the tv, not tv to phone?
21:34:42 <mounir> schien: authentification is both end?
21:35:02 <mounir> s/is both end?/is both end/
21:36:22 <mounir> schien: using the j-pake procedure, both sides authenticate each other
21:36:45 <mounir> schien: for data encryptions, the control channel using TLS
21:36:58 <mounir> is/the control channel using/the control channel is using/
21:37:31 <mounir> mark: in this proposal there will be up to two channels? one is TCP and the other is DP?
21:37:36 <mounir> s/DP?/UDP?/
21:38:09 <mounir> schien: the second is the same as webrtc
21:38:21 <mounir> mark: what's the reliability vs the control channel?
21:38:35 <mounir> schien: the control channel is for device availability query and [...]
21:39:09 <mounir> schien: for data integrity, there is no need to do more because it's already using TLS and DLS
21:39:40 <mounir> schien: [shows diagram of architecture and describes it]
21:44:28 <mounir> schien: closing the communication is not trivial
21:44:44 <mounir> ... the control channel can only be established between the controller and the receiving side
21:45:11 <mounir> ... if the presenting context tries to close the communication channel, there will be no mechanism for the receiving side to notify the controlling side
21:45:17 <mounir> ... why the channel is being closed
21:45:51 <mounir> schien: in presentation api, there is different close reasons, one is normal close another one is went away
21:47:26 <mounir> 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
21:47:39 <mounir> ... if you close the channel without telling the other side why, you have that issue
21:47:48 <mounir> ... but then, it will seen as a network disconnect
21:47:54 <mounir> ... you should send a message sending why before
21:48:08 <mounir> yavor: is the control channel open at this point?
21:48:15 <mounir> mark: it would have to use the communication channel
21:48:26 <mounir> schien: or send the reason on the communication channel
21:48:44 <mounir> s/or send the reason/send the reason/
21:49:01 <mounir> mark: it would have to send a special message to say this is a hang up, not a message for the page
21:49:18 <mounir> ... or alternatively, reopen the control channel, send the message and close it
21:49:23 <mounir> sicking: why do we need two channels?
21:49:33 <mounir> schien: the control channel is for UA to talk to each other
21:49:41 <mounir> ... while the communication channel is for browsing context
21:49:54 <mounir> ... I try to avoid multiplexing but not sure if worth it
21:50:15 <mounir> sicking: can't we set up a new channel when creating a new context on the tv?
21:50:33 <mounir> ... you send a control message first then that channel is used as a communication channel
21:50:58 <mounir> schien: in this case, we need to define a message format for delivering the messages
21:51:19 <mounir> mark: our track record of implementations is that there is almost 1 communication between Chrome and the Cast device
21:51:35 <mounir> yavor: is it possible that it is coming from how webrtc works?
21:51:42 <mounir> ... it will require signaling before connection
21:51:52 <mounir> schien: that's one reason that we need to establish a control channel
21:52:00 <mounir> ... different from the communication channel
21:52:09 <mounir> mark: our experience is that it's all one channel
21:52:22 <mounir> ... and some messages are treated as communication messages and some as control messages
21:52:43 <mounir> ... I believe there are some benefits of using data channels, for example, if we want to focus on scenarios not in a LAN
21:52:54 <mounir> ... it might behave better when WiFI is flaky
21:53:04 <mounir> ... those are potiential reasons but we decided not to go that way
21:53:19 <mounir> sicking:  another approach is to have webrtc to be the low level communiaction channel and we send message trough webrtc
21:53:28 <mounir> ... the first control message is based on webrtc
21:53:44 <mounir> ... basically, the presentation api's protocol is layered on top of webrtc
21:54:18 <mounir> sicking: unfortunately, webrtc can't be the first connection established
21:54:25 <mounir> ... you need a control channel to bootstrap webrtc
21:54:41 <mounir> s/sicking: unfortunately/schien: unfortunately/
21:55:11 <mounir> sicking: should we use something than webrtc then?
21:55:20 <mounir> mark: in my opinion, webrtc shouldn't be mandatory
21:55:37 <mounir> ... unless there is a use case that specifically requires webrtc
21:55:52 <mounir> schien: the reason why I do that is because on the API side, we can pick between plain text and binary data
21:56:07 <mounir> ... it already defines the data format for delivering plain text/binary data over the same channel
21:56:27 <mounir> ... otherwise, we will have to redefine this for our own message format
21:56:35 <mounir> sicking: we can use web socket?
21:56:45 <mounir> mark: there are alternative like web sockets indeed
21:56:56 <mounir> schien: that's the details we can discuss in the CG
21:57:15 <mounir> schien: if you want more details on the proposal, you can check the wiki
21:57:21 <mounir> ... I will keep it updated
21:58:09 <mounir> anssik: are schien and sicking working together? is flyweb using this work?
21:58:16 <mounir> sicking: we don't use this in flyweb
21:58:24 <mounir> ... we only use http and web sockets
21:58:31 <mounir> ... for discovery, we use mdns
21:58:44 <mounir> sicking:  there is very little to re-use apart from the discovery part
21:59:10 <mounir> ... even that sounds challenging if it's going to use a passcode because we expect devices without screens to work with flyweb
21:59:32 <mounir> ... I'm a little bit uncertain if that code typing is actually practical
21:59:58 <mounir> ... my concern is that device makers optimize for UX and typing code is good for security but not practical
22:00:05 <mounir> mark: there are different modes you can pick
22:00:19 <mounir> ... you can do a visual verification instead of typing the code
22:00:42 <mounir> ... most users will bypass but that will solve the security
22:01:13 <mounir> sicking: even typing the code sounds insecure because one could make the smart tv show anything if you are MIM the TV
22:01:33 <mounir> ... both of those things are non starters to me
22:01:47 <mounir> ... Though, the more stuff we have, the harder it is to hack
22:02:13 <mounir> anssik: I see three sets of requirements: mark, schien and flyweb
22:02:20 <mounir> ... what can we do for standardization?
22:02:40 <mounir> 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
22:03:07 <mounir> mark: I anticipate the authentification to be the hardest part
22:03:25 <mounir> ... I believe we can find a good compromise but we might not have an answer soon
22:03:37 <mounir> ... I'm okay moving forward with other piecies in the meantime
22:03:57 <mounir> ... One requirement that isn't clear is whether WebRTC is a hard requirement
22:04:27 <mounir> ... I would prefer to avoid that for reasons stated earlier
22:04:57 <mounir> yavor: for us, establishing secure channel is all we need
22:05:10 <mounir> ... it's sound challenging
22:05:43 <mounir> yavor: whatever secure channel technology works reliably and we can do bi-directional communication, it is good for us
22:05:58 <mounir> sicking: are there high performance use cases requiring UDP sockets
22:06:10 <mounir> yavor: not right now, we will not send videos or key strokes
22:06:20 <mounir> ... there is play controls but no game levels interactions
22:06:31 <mounir> ... we mostly send commands and updates
22:06:49 <mounir> ... it's basically more like a chat
22:07:36 <mounir> yavor: in this model, what's the receiver page? the TV or a page on the TV?
22:08:00 <mounir> mark: the charter should be clearer but we are not trying to do an app to app authentification
22:08:09 <mounir> ... so the only guarantee is that you talk to a server that we trust
22:08:36 <mounir> 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?
22:09:02 <mounir> mark: I think the idea is that the keys will have to be regenerated regularly
22:09:21 <mounir> yavor: with the flyweb model it's different because you auth with a page
22:09:29 <mounir> ... not with the tv, with actually short lived
22:12:03 <mounir> sicking: one you established the identity of the other side once, can you guarantee that it will stay true for the session?
22:12:41 <mounir> mark: yes, unless you navigate
22:19:52 <tidoust> Topic: CG rechartering
22:19:58 <tidoust> scribe: yavor
22:20:15 <tidoust> RRSAgent, draft minutes
22:20:15 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
22:20:24 <yavor> mark: The charter is work in progress.
22:21:34 <yavor> mark: Reiterate what are the goals.
22:22:42 <yavor> mark: Pitch to browser vendors to move towards standardization.
22:23:03 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
22:24:30 <yavor> mark: If our work is successful we should discuss what is the proper way to standardize.
22:25:24 <yavor> tidoust: IETF is proper way to go.
22:25:59 <yavor> anssik: What is the W3C position?
22:27:48 <yavor> anssik: The websocket is a good example.
22:29:03 <tidoust> ACTION: Mark Foltz to look into software licenses for prototype implementations in the CG
22:30:07 <yavor> mark: Background of the working group.
22:31:41 <yavor> mark: Scope - 5 different use cases.
22:32:11 <yavor> mark: Developing of open source protocol is in scope.
22:32:35 <yavor> sicking: Having issues with the working group producing code.
22:33:20 <yavor> sicking: Prototype level code is fine, but historically was bad.
22:35:28 <yavor> anssik: Take implementation feedback.
22:36:10 <yavor> anssik: What happened from WebRTC?
22:36:32 <yavor> mark: The backend is shared the presentation layer is separate.
22:37:17 <yavor> anssik: We need to update the language.
22:37:57 <yavor> mark: Out of scope is to define what the UserAgent should do.
22:37:59 <anssik> clarification to out of scope: https://github.com/mfoltzgoogle/cg-charter/pull/3/files
22:38:33 <yavor> mark: UA-1 protocol is out of scope.
22:42:45 <yavor> sicking: I didn't consider that this group would do FlyWeb. I'm interested in Bluetooth though.
22:43:36 <yavor> sicking: The presentation API would allow not requiring switching a network.
22:44:47 <yavor> sicking: Defining bluetooth protocol may belong to different group.
22:45:37 <yavor> mark: We can look at the discovery and contact the relevant groups later.
22:46:18 <yavor> mark: We are not adding backwards compatibility.
22:46:55 <yavor> mark: There would be ways to implement vendor extensions.
22:48:57 <yavor> mark: 1-UA is out of scope, localization and accessibility too.
22:49:59 <yavor> mark: Deliverables are first specifications.
22:50:37 <yavor> anssik: What is the required format?
22:52:01 <tidoust> ACTION: Mark to strike the Deliverables intro text and jump to the specifications list directly in the CG charter
22:53:19 <yavor> mark: 3 main sections: 1) Discovery 2) Protocol for 2-UA mode 3) Protocol for creating and controlling remote playback.
22:53:59 <yavor> Edward: Don't constrain it.
22:54:32 <yavor> mark: Is conformance something that we care now?
22:55:59 <yavor> mark: Interesting things:  Some ways to use BLE, how to use NFC, having network traversal.
22:56:16 <yavor> anssik: It is good to have these listed.
22:57:40 <yavor> Edward: I have some concerns. Can we exclude this section from the scope.
22:58:28 <yavor> tidoust: Scope helps with patents and keeping the group focused.
22:59:00 <eric_carlson> eric_carlson has joined #webscreens
22:59:18 <yavor> Eric: Just leave the first two lines without specifying concrete items.
23:00:26 <yavor> mark: ACTION: We would remove the items and just keep generic description.
23:01:07 <anssik> https://github.com/w3c/web-platform-tests/blob/master/LICENSE
23:01:20 <yavor> Edward: Test Suites is section is not clear.
23:01:50 <hober> http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html
23:01:53 <yavor> mark: Build a test suites to measure if the prototype matches the spec.
23:03:00 <yavor> tidoust: I think we should strike the whole section.
23:03:40 <yavor> anssik: We can use the web platform tests instead.
23:04:06 <yavor> ACTION: Mark to strike the test section.
23:06:55 <anssik> CG charter template: http://w3c.github.io/cg-charter/CGCharter.html
23:08:04 <yavor> mark: Merge pull requests add notes and do new pull request.
23:08:49 <yavor> anssik: We should figure out the timeline when to get all the feedback in.
23:09:26 <yavor> anssik: We have feedback from Ed that we may need 6 weeks.
23:10:35 <yavor> makr: I want to TPAC to be productive f2f.
23:11:14 <yavor> anssik: Beginning of August we can have final chapter approved.
23:12:13 <yavor> anssik: We are at the end of the day and we can wrap up.
23:13:16 <yavor> anssik: Thanks to Mark - the host and everyone from Google. Thanks to the new arrivals.
23:13:59 <yavor> anssik: We are getting close, and thanks to the feedback from the implementors.
23:15:18 <ricksmit> ricksmit has joined #webscreens
23:15:25 <yavor> anssik: Some people may be concerned that there wasn't enough incubation.
23:15:55 <yavor> anssik: Let's keep up the momentum.
23:16:31 <yavor> anssik: Next f2f is in Portugal.
23:17:34 <tidoust> [F2F adjourned]
23:17:37 <tidoust> RRSAgent, draft minutes
23:17:37 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webscreens-minutes.html tidoust
23:23:38 <ricksmit> ricksmit has joined #webscreens
01:06:06 <sicking> sicking has joined #webscreens
01:36:58 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
04:58:10 <tidoust> tidoust has joined #webscreens
06:01:32 <sicking> sicking has joined #webscreens
06:59:11 <ricksmit> ricksmit has joined #webscreens