23:45:57 <RRSAgent> RRSAgent has joined #webscreens
23:45:57 <RRSAgent> logging to http://www.w3.org/2015/10/29-webscreens-irc
23:46:09 <tidoust> RRSAgent, make logs public
23:46:44 <wonsuk> wonsuk has joined #webscreens
23:46:44 <tidoust> RRSAgent, this meeting spans midnight
23:47:29 <tidoust> Meeting: Second Screen WG F2F - TPAC 2015 - Day 2/2
23:47:40 <tidoust> Agenda: https://www.w3.org/wiki/Second_Screen/Meetings/Oct_2015_F2F#Agenda
23:47:43 <tidoust> Chair: Anssi
23:48:28 <TaejeoungKim> TaejeoungKim has joined #webscreens
23:49:00 <tidoust> Present+ Travis_Leithead
23:49:10 <tidoust> Present+ Jean-Claude_Dufourd
23:49:56 <tidoust> Present+ Shih-Chiang_Chien
23:50:02 <tidoust> Present+ Louay_Bassbouss
23:50:07 <tidoust> Present+ Francois_Daoust
23:50:13 <tidoust> Present+ Anssi_Kostiainen
23:51:02 <jinwoo_mbp> jinwoo_mbp has joined #webscreens
23:51:12 <tidoust> Present+ Jinwoo_Song
23:51:13 <Louay> Louay has joined #webscreens
23:51:14 <tidoust> Present+ Taejeoung_Kim
23:51:41 <tidoust> Present+ Yukinori_Endo
23:59:45 <tidoust> Present+ Mark_Foltz
00:01:12 <tidoust> Present+ Tomoyuki_Shimizu
00:01:35 <tomoyuki> tomoyuki has joined #webscreens
00:01:57 <tidoust> Present+ Hyojin_Song
00:02:05 <takeshi> takeshi has joined #webscreens
00:02:11 <tidoust> scribe: tidoust
00:02:29 <tidoust> [Anssi kicking off the meeting]
00:03:11 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
00:03:29 <tidoust> Anssi: Looking at the agenda. Travis is here to discuss the TAG review. We'll start by discussing audio and video rendering, then move on to horizontal reviews.
00:04:28 <tidoust> ... Several of them: Technical Architecture Group (TAG), Privacy, Security and Accessibility.
00:04:32 <mfoltzgoogle> +q
00:04:57 <tidoust> Francois: There's the i18n review as well, which we actually did as well. Feedback was roughly that there was no internationalization issue.
00:05:09 <Zakim> Zakim has joined #webscreens
00:05:20 <anssik> q?
00:05:26 <anssik> q+ mfoltzgoogle
00:05:30 <anssik> ack mfoltzgoogle
00:07:02 <tidoust> Mark: Takeshi and I had a discussion. There may be an issue with the local character set used in the presentation. Question about some possibility to set the requested locale through the Presentation API.
00:07:11 <hyojin> hyojin has joined #webscreens
00:07:46 <tidoust> ... I think we just need to check the rules for settings the rules for encoding and locale for the group.
00:08:26 <tidoust> ... Encoding of the strings passed through the communication channel.
00:10:40 <tidoust> Travis: There's a specific USVString type in WebIDL that can be used for such purpose.
00:11:01 <tidoust> Mark: WebSocket probably has something along these lines, we should reuse that.
00:11:55 <tidoust> SC: If we cannot pass this kind of locale requirement during the application launching phase, there may be a problem for sites that use the local locale.
00:12:37 <tidoust> Mark: If you, as a controller, wants to start a presentation, the question is: would you rather specify the preferred locale of the presentation?
00:12:56 <tidoust> Anssi: OK, it sounds we should add a topic on the agenda to discuss that more thoroughly.
00:13:56 <tidoust> Jean-Claude: Date passed between endpoints could be interpreted differently, is that the problem?
00:13:58 <tidoust> Mark: Yes.
00:14:20 <tidoust> Louay: We need to address this from an end-user perspective. Smartphone is personal device. TV may not be.
00:15:16 <tidoust> ... You may want in your application to have different languages, so we may need a way to decide of a different behavior. What is the default setting and is there a way to change it, basically.
00:15:30 <oonishi> oonishi has joined #webscreens
00:15:44 <tidoust> Anssi: OK, agenda updated.
00:16:41 <tidoust> [reviewing the rest of the agenda]
00:17:36 <tidoust> Present+ Chris_Needham
00:19:32 <tidoust> Anssi: Any comment on the agenda?
00:19:35 <tidoust> [none heard]
00:19:50 <tidoust> Topic: Presenting the content of an <audio> or <video> element (#13)
00:20:07 <mfoltzgoogle> Mounir and Anton have a github with the gist of the proposal.
00:20:08 <mfoltzgoogle> https://github.com/mounirlamouri/htmlmediaelement-remoteplayback
00:20:14 <tidoust> Anssi: Mark will report on the proposal from Mounir and Anton
00:20:32 <mfoltzgoogle> There are two documents https://github.com/mounirlamouri/htmlmediaelement-remoteplayback/blob/master/use-cases.md
00:20:42 <tidoust> Mark: See GitHub for the proposal.
00:20:43 <mfoltzgoogle> Use Cases and Requirements
00:20:52 <mfoltzgoogle> https://github.com/mounirlamouri/htmlmediaelement-remoteplayback/blob/master/proposal.md
00:21:12 <tidoust> ... Two documents in there, one that list use cases and requirements, and one describes the proposed interfaces
00:21:13 <mfoltzgoogle> WebIDL for extending HTMLMediaELement
00:21:20 <Louay> Louay has joined #webscreens
00:22:11 <tidoust> ... Basically, we want to add a feature to media element that allows for remote playback. You can also disable this feature.
00:22:40 <sangjo> sangjo has joined #webscreens
00:22:41 <tidoust> ... We're trying to capture the common use case, where there is an src that targets a stream that can be played in other browsers.
00:23:17 <tidoust> ... There are proprietary solutions for that, in Safari 7 and 9 to allow remote playback on AirPlay that you can detect from the app.
00:23:32 <tidoust> ... Once the user picks the device, Safari takes over video playback.
00:23:40 <Dewa> Dewa has joined #webscreens
00:24:19 <Travis> Travis has joined #webscreens
00:24:36 <Travis> Yes, Microsoft Edge recently announced a casting feature: http://venturebeat.com/2015/10/29/microsofts-newest-windows-10-preview-for-pcs-comes-with-edge-media-casting-ask-cortana-in-pdfs-in-edge/
00:24:56 <tidoust> Louay: I think Firefox for Android supports something like this for Chromecast
00:25:02 <tidoust> SC: Right, that's browser UI.
00:25:10 <Travis> also: http://blogs.windows.com/windowsexperience/2015/10/29/announcing-windows-10-insider-preview-build-10576/
00:25:40 <tidoust> Mark: Chrome has a similar functionality through the Cast button
00:26:14 <mounir> The basic idea of the API is for websites to be able to implement custom controls and still have this feature.
00:26:15 <tidoust> ... The Browser UIs section describes the different implementations so far. Mostly similar from browser to browser.
00:26:22 <mounir> The same way they can re-implement play/pause/seek and fullscreen
00:27:35 <tidoust> [going through the Android remote playback workflow]
00:28:11 <tidoust> Mark: Play/Pause/volume are the key features you would want. Seeking is important as well.
00:28:26 <cpn> cpn has joined #webscreens
00:28:30 <tidoust> ... It's been a very popular feature for the use of Cast on Android.
00:30:00 <tidoust> ... The basic use cases is that a Web site should be able to know if there is a display available, know when there is remote session already connected, control the remote playback through play/pause/... commands
00:30:03 <YxE> YxE has joined #webscreens
00:30:48 <tidoust> ... The ability to know when the remote playback is connecting is I think useful because there will usually be some sort of buffering on the remote side because the playback actually starts
00:31:12 <tidoust> s/basic use cases/basic requirements/
00:31:24 <tidoust> ... Any comment?
00:33:11 <tidoust> Francois: Judging from Travis link, MS Edge seems to now offer a similar option
00:33:26 <tidoust> Mark: Working with Miracast?
00:33:33 <tidoust> Travis: Yes, and DLNA.
00:35:00 <tidoust> Mark: The basic idea of the disable feature is that by default, it should work, but the app may want to disable the default browser behavior to provide custom controls.
00:35:26 <tidoust> Anssi: Let's review the interface proposal
00:36:36 <tidoust> Mounir: On the media element itself, there would be a new attribute adding a new object to the element, and a flag to disable the remote playback default behavior.
00:37:04 <jcdufourd> jcdufourd has joined #webscreens
00:37:10 <tidoust> ... The "remote" attribute would always be set. You would call the getAvailability() method to check that there are available displays.
00:37:20 <tidoust> ... This is similar to how the current Presentation works.
00:37:57 <tidoust> ... "start" allows the custom control to actually start the playback. I do not know what the Promise returns here.
00:38:10 <tidoust> Jean-Claude: What about controls?
00:38:26 <tidoust> Mark: The controls remain on the media element. They would just control the remote playback.
00:38:36 <tidoust> ... You cannot send additional messaging
00:38:37 <mounir> start() will show a UI to select a device, the Promise<bool> returns whether a session is starting
00:38:54 <tidoust> Jean-Claude: Internally, the implementation would proxy the commands to the remote end.
00:38:57 <tidoust> Mark: Right.
00:39:09 <mounir> start() is a name that might change in the future for something more about UI (like .showControls())
00:40:25 <tidoust> Mark: We can probably find a common set of controls that are implemented everywhere.
00:41:00 <anssik> [ demonstrating remote controls for play/pause/seek using a similar demo http://webscreens.github.io/requestshowmedia/demo/ ]
00:41:31 <tidoust> SC: Firefox OS tries to define a minimal set of commands and status reports for remote video.
00:43:02 <tidoust> Francois: Not there are media accessibility requirements that might apply and affect this set
00:44:06 <tidoust> Louay: What about DRM content? How do you filter the devices that are available? DRM is just an example, there may be other things such as video quality or streaming format (e.g. HLS)
00:44:10 <jcdufourd> jcdufourd has joined #webscreens
00:45:13 <tidoust> Mark: If it's 1-UA mode, you would expect things to be supported. If it's 2-UA mode, you need to check the codec of course. For EME, the license may only apply to one local device so remote playback may not be supported at all.
00:45:24 <tidoust> ... That's questions that need to be addressed
00:45:57 <tidoust> SC: For Firefox, we pick only the most simple scenario, where the video is trying to play an HTTP url.
00:46:22 <tidoust> ... And also we are whitelisting the supported codecs, e.g. sending the MP4 source to the remote end.
00:47:17 <tidoust> [reviewing Mounir's IRC comments]
00:48:57 <tidoust> SC: for "start", it's about custom UI done by the Web App. The showControls approach would more be a way to let the user agent handle things by itself
00:49:26 <tidoust> Anssi: Are you guys interested in moving this forward?
00:49:38 <tidoust> Mark: I think so.
00:49:48 <tidoust> ... We want that feature to be better integrated with the Web page.
00:50:08 <tidoust> ... Better user experience with custom controls.
00:50:40 <mounir> We want to ship the attribute to disable default controls as soon as possible
00:50:42 <tidoust> Anssi: Is is a good proposal for something you might implement in the future, Shih-Chang?
00:50:58 <mounir> the current browser default controls are providing a bad behaviour when used with Presentation API
00:51:11 <mounir> we need this attribute to provide a smooth experience for websites
00:51:37 <mounir> (ie. the idea is that a website using Presentation API and has default controls, the users will end up seeing two "Cast" buttons that will behave slightly differently)
00:51:47 <tidoust> SC: Maybe. It is probably more a priority for things such as Youtube, but that's something we will probably address in the future.
00:52:16 <tidoust> Anssi: It seems it would be good to move this to an Editor's Draft. Do we have editors?
00:52:45 <tidoust> Mark: I can't speak for people who are not around but know Anton is willing to work on the feature
00:53:01 <tidoust> Anssi: I note the feature is in scope of the Working Group
00:53:14 <mounir> I think Anton and I will can edit the spec
00:53:15 <tidoust> ... It will be separated from the Presentation API, because it is different
00:53:41 <kinjim> kinjim has joined #webscreens
00:54:04 <tidoust> ... Any objection to moving forward?
00:54:35 <tidoust> ... Seeing that Mounir and Anton "will can" edit the spec, so that's good.
00:55:06 <mounir> :)
00:56:01 <tidoust> PROPOSED RESOLUTION: for issue #13, Anton and Mounir will spec an Editor's Draft that follows the proposal shared with the group so far.
00:56:40 <tidoust> Anssi: I thinkg it's good not to have a dependency between the two specs, as implementers may want to implement one or the other spec.
00:58:24 <mounir> Avoiding dependencies is something we did in the current spec.
00:58:37 <mounir> As you can see, it is reusing designs from the Presentation API but not the same interfaces
00:58:58 <tidoust> Mark: One thing to consider. The bad experience now is that if a browser implements the Presentation API and this remote playback, there may be two approaches to provide a similar experience from an end-user perspective, hence the need to be able to disable the remote playback to take control of the experience.
00:59:59 <tidoust> Anssi: It may be a good idea to create the Editor's Draft on GitHub in a dedicated W3C repo
01:00:02 <mfoltzgoogle> Thanks Mounir for joining.
01:00:02 <tidoust> ..
01:00:27 <tidoust> Francois: That's totally doable. I'll see with Mounir and Anton how they prefer to move forward. Happy to create the repo.
01:00:32 <tidoust> s/..//
01:00:42 <tidoust> RESOLUTION: for issue #13, Anton and Mounir will spec an Editor's Draft that follows the proposal shared with the group so far.
01:00:55 <tidoust> Topic: TAG review of the Presentation API
01:01:12 <tidoust> Anssi: I'd like to thank Travis for the TAG review.
01:01:28 <tidoust> ... Can you take us through the document?
01:02:06 <tidoust> scribe: mfoltzgoogle
01:02:47 <mfoltzgoogle> Travis: Reviewed 1-2 months ago from the perspective of the TAG.  Good patterns, etc.
01:03:30 <mfoltzgoogle> ...High level, the spec is breaking new ground.  Idea of remote controlling a remote browsing context.
01:03:57 <mfoltzgoogle> ...Today Web content is tied to screen you are interacting with physically.  Interactivity, display live in the same local sphere.
01:04:19 <mfoltzgoogle> ...Even opening new windows, opens in the constraints of the browser.  Browser ensures that communications are available.
01:04:54 <mfoltzgoogle> ...window.open(), browser creates a new frame.  Channel created to opener window.  Multiple constraints applied:  Essentially on the same thread as the rest of the Web platform.
01:05:14 <wonsuk> wonsuk has joined #webscreens
01:05:18 <mfoltzgoogle> ...Web developers expect to forward node trees to other contexts.
01:05:43 <mfoltzgoogle> ...Now connecting to a completely separate device, and remote controlling it.
01:06:18 <mfoltzgoogle> ...I found it interesting that the API is a high level experience detail.  But not much detail on how to create an interoperable communications channel.
01:06:50 <mfoltzgoogle> ...Prevents a scenario where three browsers are able to communicate to the same presentations.
01:08:03 <mfoltzgoogle> ...However other specs use a structured cloning algorithm that is not specified.  Assumed to be in same browser.
01:08:32 <mfoltzgoogle> ...send() API is different from postMEssage().  Is that intentional?
01:09:08 <mfoltzgoogle> ...Security and privacy.  Reminds me of fullscreen.  Iframes may need additional permission - a separate permission may be more appropriate.
01:09:48 <mfoltzgoogle> ...API creates a session object that represents the remote session.  It seems that when I say start the game, and a couple of friends join, and I can leave.
01:10:35 <mfoltzgoogle> ...Lifetime and ownership model of the second screen.  Is it a separate entity, is it tied to the opener, or does it live while there is a live connection.
01:10:44 <mfoltzgoogle> ...There is a stop API.  What happens if you never call it?
01:12:36 <mfoltzgoogle> ...Security requirements for communication channel.  When the controlling page is loaded securely, what is the guarantee on channel.  The TAG+WebAppSec has a security questionnaire (where these questions came from).
01:13:32 <mfoltzgoogle> ...What is your view of the origin of the second screen.  Is the expectation that it becomes its own origin, separate relationship.  Is it client-server or client-client?
01:14:42 <mfoltzgoogle> ...Client-server is well understood, each side makes its own decisions.  Client-client is limited to what capabilities.  Each client has to choose what origins it can accept messages from.
01:14:48 <mfoltzgoogle> ...postMessage model
01:15:23 <dwim_> dwim_ has joined #webscreens
01:15:48 <anssik> scribeNick: anssik
01:16:14 <anssik> Francois: no postMessage, since the recipient may not be friendly
01:16:24 <anssik> ... back to the same model as in WebRTC
01:16:49 <anssik> ... this was the motivation to switch to send() primitives
01:17:33 <anssik> ... if the device I'm using want to connect to another device, unable to check that the connection is not faked
01:17:51 <anssik> ... no way to convey trust
01:18:23 <anssik> ... IOW, what you receive cannot be trusted
01:19:23 <anssik> ... there is no way for the web app requesting presentation to tell its origin to the second screen device in a secure way, or the other way around: for the second screen to trust the sending side origin
01:19:50 <anssik> [ Travis repeating the use case ]
01:20:18 <anssik> Francois: identity check would happen through some sort of signalling channel, that is not specified
01:20:33 <anssik> ... having postMessage on this origin would set false expectations
01:20:54 <anssik> ... when you're in a single user agent you can trust the origin
01:21:13 <anssik> Mark: Any origin-based model cannot be trusted if the UA cannot be trusted
01:22:31 <anssik> ... delegating the trust to third party one viable options
01:22:48 <anssik> Travis: existing model in a browser that is the same you're doing
01:22:53 <anssik> ... open PayPal in one tab
01:23:02 <anssik> ... open commerce side in second tab in the same UA
01:23:23 <anssik> ... those two origin do not know they're loaded related to each other, totally isolated
01:23:41 <anssik> ... still postMessage let's you to postMessage to * world with some payload
01:23:59 <anssik> ... UA will faithfully delivered the payload to all origin that are valid per the filter (*)
01:24:10 <anssik> ... it is a push model, instead of pull model
01:24:28 <anssik> ... it becomes the responsibility of receiving party to do the validation of the received data
01:24:39 <anssik> ... it is trivial to write a protocol atop this model
01:24:52 <anssik> ... e.g. say "I wasn't expected to receive a message at all"
01:25:14 <anssik> ... if A has an origin loaded on my machine, B on another origin on another machine
01:25:53 <kenneth_> present+ kenneth
01:26:14 <tomoyuki> present+ Tomoyuki_Shimizu
01:26:25 <anssik> Francois: with postMessage, in a single UA, you trust your UA
01:26:35 <anssik> ... in 2-UA, you have to trust two UAs
01:26:47 <anssik> ... we do not think that it is a good idea to rely on the same mechanism
01:26:56 <anssik> ... because it does not build the same trust model
01:27:13 <anssik> ... can of course implement one's own auth protocol atop
01:27:34 <anssik> Travis: I can do MITM between two tabs, a new security dimension
01:27:48 <anssik> s/can/can't/
01:28:14 <anssik> ... when you initiate a new remote connection, is it handled by a single UA only?
01:28:26 <anssik> ... or with a protocol that is shared between the two
01:28:43 <anssik> Francois: we're protocol agnostic, so many implementations are possible
01:29:58 <anssik> Travis: it is hard to give security advise given the protocol is not specified
01:31:15 <anssik> Travis: Private mode browsing for the presenting context
01:31:36 <anssik> ... not sure about the status of the related TAG document
01:31:44 <anssik> ... how would you reference it?
01:32:34 <tidoust> Anssi: At one point, we were wondering whether the second screen browsing context should be required to be in private browsing mode.
01:35:09 <tidoust> Francois: Use case is that the controlling side is likely a private device, while the remote end may be a shared one, so implementations will most likely run the receiving browsing context in incognito-like mode.
01:35:47 <anssik> Travis: these requirements would need to be pushed down to respective specs
01:35:53 <tidoust> i/Anssi:/scribe: tidoust
01:36:20 <tidoust> i/Anssi: At one point,/scribe: tidoust
01:36:28 <tidoust> i/Travis: these requirements/scribe: anssik
01:38:35 <anssik> Travis: there are cases where the user input would be required, like access to a mic
01:38:53 <anssik> Mark: true, there are also cases where there could be interactivity
01:39:13 <anssik> ... we provide developers means to detect whether the content is interaction or non-interactive
01:40:37 <anssik> Ed: there are plenty of cases on the platform that are about user interaction, e.g. alert() and expect user to be able to interact
01:40:53 <anssik> ... we have an assumption you do not need to know if some sort of input is possible
01:41:19 <anssik> ... examples:
01:41:22 <anssik> ... no keyboard
01:41:27 <anssik> ... no keypresses
01:41:37 <anssik> ... now you just listen to keypresses but never get one
01:41:44 <anssik> ... generic model for eventing
01:41:57 <anssik> ... this is a bigger guestion, not specific to the Presentation API
01:42:07 <anssik> Travis: often APIs are designed to fair gracefully
01:42:19 <anssik> ... e.g. you just do not get Promise back
01:43:13 <anssik> ... sync behaviour that expects user input, e.g. alert() and <input type=file> are examples of ones that have problems with blocking
01:43:31 <anssik> Mark: we may want the developer to require an interactive or non-interactive second screen
01:43:48 <anssik> ... "only show interactive screens"
01:44:49 <anssik> Mark: try things, if they don't work, try something else
01:45:55 <YxE> YxE has joined #webscreens
01:46:19 <anssik> Mark: as the spec editor asking, if the private mode browsing spec does not materialize what to do
01:47:18 <tidoust> Present+ Ed_O'Connor
01:47:31 <wonsuk> wonsuk has joined #webscreens
01:48:00 <anssik> Ed: each browser behaves differently in terms of private browsing mode currently
01:49:23 <anssik> Travis: I'll take an action to investigate the status of private mode browsing spec
01:49:41 <anssik> s/private mode browsing/private mode/
01:50:38 <anssik> Mark: with this feedback, I can improve the spec in this regard
01:51:10 <mfoltzgoogle> ACTION: Mark to define a presenting browsing context that sets an empty initial state.
01:51:18 <mfoltzgoogle> ...Including storage and permissions.
01:51:49 <anssik> Travis: 3. Fingerprinting and screen availability monitoring
01:52:16 <anssik> ... the web page want to know whether there's second screen before requesting one
01:52:28 <anssik> ... that's what this is about
01:53:23 <anssik> ... TAG has a take on unsanctioned tracking i.e. not all tracking is bad
01:53:39 <anssik> ... the user has the choice whether to be tracked or not, think cookie usage
01:55:07 <anssik> ... sanctioned tracking, revealing IP address in WebRTC ICECandidate negotiation
01:55:41 <anssik> ... in that example, WebRTC has a plan how to fix that without exposing the IP
01:56:09 <anssik> ... maybe that becomes an option how to configure their systems to be in more control over their private data
01:56:21 <anssik> ... the availability of the second screen did not seem a huge concern
01:56:45 <anssik> ... to draw another parallel, canPlayType already has more exposure
01:57:32 <anssik> ... adds a bit more tracking data, but not too concerned with availability
02:01:56 <akitsugu> akitsugu has joined #webscreens
02:04:10 <anssik> ACTION: Mark to reach out to Permission API editors to see how it interacts with Availability
02:04:32 <anssik> Travis: 4. Dealing with legacy content
02:04:52 <anssik> ... touched this one already a bit
02:05:00 <anssik> ... device w/o an ability to take input
02:05:24 <anssik> ... has dramatic effect on how you view the allowpresentation attribute
02:05:37 <anssik> ... I wrote that probably do not want to piggy-back on allowfullscreen
02:05:56 <anssik> ... however if you are then essentially projecting to a "readonly browsing context"
02:06:02 <anssik> ... maybe allowfullscreen is ok
02:06:23 <anssik> ... especially if the device that is presenting is just driving the view, or a mirror copy
02:06:33 <anssik> ... it is like a fullscreen experience
02:06:42 <YxE> YxE has joined #webscreens
02:06:44 <anssik> ... if is a separate thing, it may not be approviate
02:07:02 <anssik> s/approviate/appropriate/
02:07:23 <anssik> Mark: do UAs allow persistent permission for fullscreen
02:07:25 <anssik> Travis: no
02:07:43 <anssik> ... it is a few APIs that use ask forgiveness model
02:09:35 <anssik> ... there are certain threats for fullscreen, like spoofing the OS UI
02:11:39 <anssik> ... all shipping browsers implement the Fullscreen API with ask for forgiveness permission model
02:14:35 <anssik> Travis: has the Screen Capture API in WebRTC considered in designing the Presentation API?
02:15:04 <anssik> Anssi: it is addressing the mirroring use case, for the Presentation API mirroring is out of scope explicitly
02:16:24 <anssik> [ skipping 5. Presenting the content of an <audio> or <video> element was already discussed ]
02:17:13 <yxw> yxw has joined #webscreens
02:17:22 <YxE_> YxE_ has joined #webscreens
02:18:12 <tidoust> Topic: Privacy review of the Presentation API
02:18:25 <tidoust> scribe: cpn
02:19:11 <cpn> https://lists.w3.org/Archives/Public/public-privacy/2015JulSep/0120.html
02:20:02 <cpn> Anssi: We asked the Privacy WG to look at the Presentation API
02:20:13 <cpn> ... Anssi and Mark attended a call with them some time ago
02:20:51 <cpn> ... Greg from the Privacy group tested their privacy questionnaire against the Presentation API
02:21:00 <yxw> yxw has left #webscreens
02:21:03 <cpn> ... The results are in the email linked above
02:21:27 <cpn> ... Let's see what actions we should take from these results
02:22:57 <cpn> ... Item 2, does the specification collect personally derived data?
02:23:05 <YxE_> YxE_ has left #webscreens
02:23:43 <cpn> Anssi: This doesn't look to be actionable
02:24:03 <cpn> ... Item 3: Does the spec generate personally derived data?
02:26:22 <cpn> ... We seem aligned in our consideration of the incognito mode
02:26:38 <cpn> Francois: Should we ask clarification on the audio/video case?
02:27:44 <cpn> Shih-Chang: They seem to be thinking more of video sharing than the Presentation API
02:29:09 <cpn> Action: Francois to contact PING to better explain the Presentation API and that audio/video will be done in a separate specification
02:29:46 <cpn> Topic: Accessibility review
02:30:28 <cpn> Francois: When we created the Second Screen WG we got early feedback from the Protocols and Formats WG
02:30:52 <cpn> ... The group is now known as APA
02:31:07 <cpn> ... We changed a few things in the charter before the group started
02:31:29 <cpn> ... They are working on a media accessibility user requirements specification
02:31:44 <cpn> ... Some requirements relate to secondary screens and other devices
02:32:10 <cpn> ... This isn't what the Presentation API is about, not the same as presenting the video itself
02:32:16 <anssik> https://github.com/w3c/presentation-api/issues/162
02:32:24 <cpn> ... I've written a response to share with them
02:34:19 <cpn> [Francois summarises his comments in the issue list]
02:34:57 <cpn> Anssi: Does Google's implenentation distinguish discovered devices when presenting the list
02:35:22 <cpn> ... Yes, we have several types, such as Cast devices, DIAL devices
02:36:04 <kinjim> kinjim has joined #webscreens
02:36:25 <cpn> MarkF: What defines an accessible UA?
02:37:05 <cpn> Francois: There are the UAAG guidelines, has requirements for accessibility friendly UAs
02:37:29 <cpn> ... But there aren't precise conformance claims
02:38:38 <cpn> MarkF: I don't see a simple solution, but could discuss internally
02:39:58 <cpn> Action: Francois to amend the SD-1 review (drop the second section) and send back to the APA
02:41:28 <cpn> MarkF: Browser extensions can enable accessibility functions making use of markup in the page
02:42:06 <cpn> Shih-Change: And similar in Firefox, but we have screen reader mobile support also
02:42:16 <cpn> [SD-2]
02:42:50 <cpn> s/[Francois summarises his comments in the issue list]/[SD-1]/
02:42:59 <cpn> Anssi: No actions here
02:43:02 <cpn> [SD-3]
02:43:26 <kinjim> kinjim has joined #webscreens
02:44:11 <cpn> MarkF: This might relate to the video proposal, if there's a new control it should be made available to assistive features
02:45:01 <cpn> [SD-4]
02:45:48 <cpn> Francois: In the 1-UA case how would we expose the browsing context  to accessibility services?
02:46:09 <cpn> ... The plug-in would need access to the DOM being rendered
02:46:21 <sangjo> sangjo has joined #webscreens
02:46:36 <cpn> Anssi: There could be a use case such as tabbing between elements
02:47:16 <cpn> MarkF: I think this should be explicitly mentioned in the spec
02:48:08 <cpn> s/Shih-Change/Shih-Chang/
02:48:56 <cpn> Shih-Chang: There should be a clear statement that the platform should allow the screen reader to work on the presenting page rather than the remote page
02:49:55 <cpn> Action: Francois to ask the APA for suggested clarifying text
02:50:21 <cpn> s/Action: Francois to ask the APA for suggested clarifying text/Action: Francois to ask the APA for suggested clarifying text (SD-4)/
02:50:31 <cpn> [SD-5]
02:52:40 <cpn> Action: Francois to initiate the review with the APA WG
02:53:39 <cpn> Topic: Security review
02:54:35 <cpn> Anssi: We have done the self-review questionnaire
02:55:03 <cpn> https://github.com/w3c/presentation-api/issues/45
02:55:44 <cpn> MarkF: I think the three issues to focus on are: the cross origin nature of the API, secure and insecure context, and authenticating the user agents
02:56:08 <cpn> ... allowing the user to extend the trust model across user agents
03:09:19 <tidoust> tidoust has joined #webscreens
03:52:10 <jcdufourd> jcdufourd has joined #webscreens
03:56:11 <tidoust> tidoust has joined #webscreens
04:03:02 <tomoyuki> tomoyuki has joined #webscreens
04:03:42 <TaejeoungKim> TaejeoungKim has joined #webscreens
04:05:22 <jinwoo_mbp> jinwoo_mbp has joined #webscreens
04:05:49 <cpn> cpn has joined #webscreens
04:06:44 <tidoust> Topic: Security review of the Presentation API
04:06:48 <tidoust> scribe: tidoust
04:07:13 <tidoust> [Most of group participants had lunch with Mike West, from WebAppSec WG]
04:07:37 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
04:08:06 <aizu> aizu has joined #webscreens
04:08:13 <tidoust> Mark: First question was: is there any concern about the API beging fundamentally cross-origin?
04:08:22 <tidoust> ... There was a feeling that this was acceptable
04:08:43 <tidoust> ... There is no way to force the other side to give you information that it would not otherwise.
04:09:47 <tidoust> ... Regarding the secure context requirement, the feeling is that the overall risk is relatively low: there is permission involved, the API can do little harm to users.
04:09:48 <YeX> YeX has joined #webscreens
04:09:50 <oonishi> oonishi has joined #webscreens
04:11:21 <tidoust> ... On fingerprinting issue for getAvailability, we have this ability to perhaps limit that by rejecting availability monitoring in non-secure contexts to prevent man-in-the-middle script injection. Not sure this needs to be in the spec.
04:12:49 <tidoust> Anssi: I think there is an interest to require secure contexts for exisiting APIs that have shipped. Geolocation is an example. The idea could be to leave that open to implementers.
04:13:24 <tidoust> Francois: Not exactly the same thing. If geolocation was re-written, it would require secure contexts. We may choose not to follow the secure requirement because of some rationale, for sure.
04:14:39 <Zakim> Zakim has left #webscreens
04:14:46 <tidoust> Anssi: If you had secure context restriction in an implementation that is not required by the spec, do you still conform to the spec?
04:15:07 <tidoust> Francois: Interesting point. I think so, although it's true that you would not always follow exactly the same steps.
04:15:44 <tidoust> Mark: I think we can be a bit more specific in the spec.
04:16:29 <tidoust> Francois: In the spec, steps typically need to contain some prose that allows the user agent to reject a request for security reasons.
04:16:42 <tidoust> Mark: Right, same wording as for permissions.
04:17:51 <tidoust> [some discussion on user interaction]
04:18:28 <Louay> Louay has joined #webscreens
04:19:19 <tidoust> Mark: The third item discussed was mixed content rules for the API. If you're in an unsecure context, we probably do not want to allow a presentation on a secure context. There will be no way for the user to know whether the controller is running under unsecure/secure context.
04:19:51 <anssik> Present+ Takeshi_Kanai
04:20:47 <tidoust> Jean-Claude: Mixed content is a warning you would get when you mix secure and non-secure content. Or any secure resource access from an unsecure context.
04:20:49 <tidoust> Mark: Yes.
04:21:17 <takeshi> takeshi has joined #webscreens
04:21:53 <tidoust> Francois: So there is a requirement to add in the spec to prevent an existing receiving presentation running in a secure context from receiving input from a controller running in a non secure context.
04:21:56 <zqzhang> zqzhang has joined #webscreens
04:21:56 <tidoust> Mark: Correct.
04:22:47 <tidoust> Jean-Claude: it's strange to be able to join an HTTPS session from another unrelated one
04:23:41 <tidoust> Francois: That ties in the discussion we had this morning
04:24:18 <tidoust> ACTION: mfoltzgoogle to propose wording to prevent mixing HTTP and HTTPS
04:24:32 <schien> this is the current statement in mixed content:
04:24:36 <schien> A resource or request is optionally-blockable
04:24:36 <schien> when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web.
04:25:00 <tidoust> Mark: Finally, we touched the question of behavior of nested frames again.
04:25:10 <nsakai> nsakai has joined #webscreens
04:25:23 <tidoust> Anssi: Mike presented the idea of delegating the trust from the top-level context to the nested one, which could perhaps apply long-term.
04:25:36 <tidoust> Mark: Yes, and I have a couple of names to get in touch with.
04:26:08 <tidoust> ... This was more from a permissions perspective. In our situation, the permission is really just for the presentation, no long term permission.
04:27:45 <tidoust> Anssi: Related to issue #80, this got discussed as well.
04:28:17 <tidoust> Francois: Yes, follows the discussion with Travis as well. My understanding is that there is no real way to spec normative requirements on that topic since we're not addressing protocols.
04:28:23 <tidoust> ... More informative guidelines in the end.
04:30:13 <tidoust> Anssi: In a way, issue #80 is out of scope of the group. At least, that is out of our hands.
04:31:00 <tidoust> PROPOSED RESOLUTION: for issue #80, close issue as out of scope, and focus on informative guidelines in security section.
04:32:08 <tidoust> Mark: Yes, anything we can write today would depend on a not yet existing spec.
04:32:10 <tidoust> RESOLUTION: for issue #80, close issue as out of scope, and focus on informative guidelines in security section.
04:32:52 <tidoust> Francois: The security self-review questionnaire should be sent out to the WebAppSec WG instead of the Web Security IG.
04:32:55 <tidoust> Anssi: Indeed.
04:33:11 <tidoust> ACTION: Francois to send self-review security evaluation to WebAppSec WG for review.
04:33:33 <tidoust> Topic: Internationalization review of the Presentation API
04:35:10 <tidoust> Francois: i18n group has not raised strong concerns so far, but discussion this morning suggests that there may be i18n use cases
04:36:38 <tidoust> Takeshi: The concern is that most of the Web content is rendered with the current locale. The typical problem is that maybe backslash character will be interpreted as Yen in Japanese, something else in Chinese and Korean.
04:37:06 <tidoust> ... These countries share the same character codes but display different characters.
04:37:44 <tidoust> Anssi: The default fonts are different.
04:39:41 <tidoust> Francois: What is specific for this API is the controlling side may want to suggest the preferred locale for the receiving side, and then for message passing, strings may be interpreted differently.
04:40:25 <tidoust> Takeshi: We can have some rendering of characters different on both screens even if they are specified in UTF-8 / UTF-16
04:40:42 <markw> markw has joined #webscreens
04:40:49 <tidoust> Jean-Claude: My suggestion is to describe the font that is used on the controlling side.
04:43:02 <tidoust> Francois: I'm surprised that the same Unicode character could be represented by characters with different meanings by different fonts.
04:43:28 <tidoust> ... Encoding may indeed change the meaning of a character, but once it's mapped as a Unicode character, it should not be interpreted directly.
04:43:36 <tidoust> ... Worth investigating and finding pointers.
04:44:11 <anssik> scribeNick: anssik
04:44:22 <anssik> Francois: in Presentation API we cannot impose locale on the receiving site
04:44:31 <anssik> ... also, the message passing uses the string type
04:44:53 <anssik> ... when you send a string, you're using the JS string type
04:45:17 <anssik> ... it does not allow you to use the full set of characters in a JS string
04:45:35 <anssik> ... the two ends should not be interpreted, since it is not encoded
04:46:06 <anssik> ... as Travis was referring to an USVString http://heycam.github.io/webidl/#idl-USVString
04:46:39 <anssik> ... my question is: I do not understand how this affects the messaging channel of the Presentation API
04:47:17 <anssik> Jean-Claude: if the system is different (e.g. Windows, Mac), the glyphs you see will be different
04:49:06 <anssik> ACTION: Francois to investigate the possibility for a JS string to be represented differently by different glyphs and locales
04:49:31 <anssik> s/represented/rendered/
04:53:56 <anssik> Francois: does specifying the locale when starting a presentation has a use case?
04:54:46 <jcdufourd> jcdufourd has joined #webscreens
04:54:53 <anssik> Jean-Claude: should we mandate that the receiver will use the same locale?
04:55:13 <anssik> Anssi: should this be SHOULD and not MUST?
04:55:18 <anssik> Mark: support SHOULD
04:55:20 <wonsuk> wonsuk has joined #webscreens
04:55:35 <anssik> Jean-Claude: support SHOULD too
04:56:06 <anssik> Francois: if you have examples of things that break due to this issue
04:56:35 <anssik> ... you are encouraged to open an issue on GH: https://github.com/w3c/presentation-api/issues/new
04:58:36 <tidoust> Topic: Implementation status discussion and demos
04:59:56 <Louay> Louay has joined #webscreens
05:00:20 <mfoltzgoogle> We have two entries.  Controlling API: https://www.chromestatus.com/feature/6676265876586496
05:00:37 <mfoltzgoogle> Receiving API: https://www.chromestatus.com/feature/5414209298890752
05:01:02 <Louay> Louay has joined #webscreens
05:01:57 <tidoust> Mark: Implementation of the receiving side. That ships by default. On the controlling browser, that's still under a flag.
05:02:38 <tidoust> Anssi: You can still do updates of the IDL?
05:02:54 <tidoust> Mark: Yes, we do not expect developers to pick it up before it is stable.
05:03:20 <tidoust> ... Support for Chromecast through the Cast protocol. For TVs, it supports the DIAL protocol.
05:03:31 <tidoust> ... That's the initial target.
05:03:43 <tidoust> ... We also have tab mirroring, but that is not part of the Presentation API
05:04:47 <tidoust> Anssi: done through the Media Capture API?
05:04:55 <tidoust> Mark: Not familiar with that proposal.
05:05:08 <tidoust> SC: That's what we have in Firefox, related to getUserMedia.
05:05:19 <anssik> s/Media Capture/Screen Capture/
05:05:23 <tidoust> Mark: The WebRTC team would be the right ones to ask.
05:05:32 <anssik> [ Screen Capture API http://w3c.github.io/mediacapture-screen-share/ ]
05:06:05 <tidoust> ... The receiving API is still work in progress. A little bit behind the controlling API.
05:06:10 <katashin> katashin has joined #webscreens
05:07:01 <tidoust> ... This will enable us to support a wide range of URLs. With the current implementation, we only support URLs that map onto Cast or DIAL applications.
05:07:33 <tidoust> Anssi: Does the meta-boxes "controller" and "receiving" map directly to the conformance classes in the spec?
05:08:08 <tidoust> Mark: Sort of. The two boxes have the controlling and receiving interfaces implemented.
05:08:19 <tidoust> ... That may be specific to our use case.
05:09:40 <Louay> Louay has joined #webscreens
05:10:03 <tidoust> Kendo: Current the Cast protocol is using the DIAL protocol?
05:10:27 <tidoust> Mark: Not exactly, we support DIAL for discovery purpose. mDNS is used otherwise normally.
05:10:37 <tidoust> ... We don't use the DIAL endpoint to actually launch applications.
05:10:46 <tidoust> RRSAgent, draft minutes
05:10:46 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/29-webscreens-minutes.html tidoust
05:11:05 <YusukeNakaya> YusukeNakaya has joined #webscreens
05:11:16 <tidoust> s/Kendo:/Yukinori:/
05:11:34 <tidoust> SC: For Mozilla, we're trying to complete the implementation of the receiving side.
05:11:54 <tidoust> ... For the controlling side, we support basic functionality such as 1:1 connections but no session resumption.
05:12:19 <tidoust> ... We have the basic support for controlling and receiving sides for the 2-UA mode.
05:12:46 <tidoust> ... Same code on both ends.
05:13:05 <schien> https://drive.google.com/open?id=0ByMsmvMKVzjBVGxXU1pZdXB2bVk
05:13:23 <tidoust> ... For the protocol choices that we have right now, see the slides
05:13:29 <Louay1> Louay1 has joined #webscreens
05:14:03 <tidoust> ... The protocol side for discovery uses mDNS right now. For application launch, we did not know which protocol to use, so we created a very simple one.
05:14:43 <tidoust> ... During the application launch, we have a very small control protocol for each endpoint to provide offer/answer-like semantics such as TCP points
05:14:56 <tidoust> ... For the message transportation, we support raw TCP socket.
05:15:17 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
05:15:24 <mfoltzgoogle> +present
05:15:27 <tidoust> ... and we plan to support WebRTC, so there will be two communication channels.
05:16:08 <tidoust> ... We're also developing the 1-UA mode for attached displays and Miracast. First to be deployed on Firefox OS devices.
05:16:35 <tidoust> ... And also for the 2-UA mode controlling side, the first platform that we're going to launch will be Firefox for Android.
05:16:43 <anssik> rrsagent, generate minutes
05:16:43 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/29-webscreens-minutes.html anssik
05:17:25 <tidoust> ... We'll limit that to a limited audience, to the Firefox add-on developers.
05:17:32 <tidoust> ... That's our current plan.
05:22:49 <tidoust> [Short presentation of the Presentation API polyfill, to investigate different discovery/launch mechanisms, and implement algorithms in the spec to uncover spec bugs: https://github.com/mediascape/presentation-api-polyfill/ ]
05:40:16 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
05:47:11 <katashin> katashin has joined #webscreens
05:48:02 <cpn> cpn has left #webscreens
05:49:04 <tidoust> [Implementation demo from Mark with Cast SDK on top of the Presentation API]
05:49:51 <tidoust> [Implementation demo from Louay of a multi-player game]
05:50:33 <YxE> YxE has joined #webscreens
05:50:58 <takeshi> takeshi has joined #webscreens
05:51:44 <tidoust> Louay: Happy to share code underlying the demos on a GitHub repo
05:51:55 <tidoust> Anssi: The webscreens organization seems to be a good fit for that
05:52:14 <tidoust> Louay: Great, I just need a gh-pages branch. Static files.
05:52:36 <tidoust> Topic: Use cases review
05:52:52 <tidoust> Anssi: My assumption is that you are familiar with the use cases
05:53:01 <tidoust> ... Any new use case that are not covered
05:53:46 <shoko> shoko has joined #webscreens
05:54:18 <tidoust> Francois: Mentioning the scenario that would not require a communication channel
05:54:39 <anssik> https://github.com/w3c/presentation-api/blob/gh-pages/uc-req.md
05:54:43 <tidoust> Jean-Claude: already covered by the use cases, although requirements are not the same.
05:55:14 <tidoust> Louay: Maybe the requirement is to put more information so that you can end up with more devices in the selection box
05:55:32 <tidoust> Anssi: I think you can take a stab at drafting a "future" section.
05:55:41 <tidoust> ... That's good homework.
05:56:00 <tidoust> ... I suggest we don't deep-dive in this topic right now.
05:56:09 <tidoust> ... Make an offline copy for the flight ;)
05:56:16 <tidoust> Topic: Testing
05:56:32 <tidoust> Anssi: An important part of the standards process.
05:56:51 <tidoust> -> http://testthewebforward.org/ Test the Web forward
05:57:03 <anssik> scribeNick: anssik
05:57:08 <tidoust> -> https://github.com/w3c/web-platform-tests Web Platform tests repository
05:58:06 <anssik> Francois: we will need as part of the W3C Process an implementation report
05:58:13 <anssik> ... to advance from CR to PR
05:58:25 <anssik> ... what that means in practice is we need to build a test suite
05:58:35 <anssik> ... implementations of the API are covered
05:58:57 <anssik> ... each normative statement in the spec should have test case(s)
05:59:24 <anssik> ... it should be from an external perspective to ensure interoperability meaning they implement the normative statements in the same way
05:59:57 <anssik> ... we've done it differently over the years and now trying to converge to web-platfom-tests and testthewebforward.org
06:00:14 <anssik> ... GH repo under the hoods https://github.com/w3c/web-platform-tests
06:00:29 <anssik> ... one folder per spec that is being tested, and each folder contains the test suite for the corresponding spec
06:00:45 <anssik> ... what I suggested is to merge with that initiative and use that framework to create our test suite
06:00:57 <anssik> ... as part of this framework there's a test runner
06:01:10 <anssik> ... e.g. idlharness.js to test the interface
06:02:19 <anssik> ... the harness lets you to run unit tests, reftests
06:02:33 <anssik> ... ref test allows you to compare the rendering with a reference image
06:02:50 <anssik> ... the last fallback is manual testing
06:03:16 <anssik> ... given we're in unchartered territory, so testing needs to require two devices: controller and receiver side
06:03:27 <anssik> ... IOW, it is two conformance classes in the spec
06:03:44 <anssik> ... most of the specs will rely on the existence of the other side, so we must be able to emulate that other side
06:04:01 <anssik> ... there's no readymade solution, we must come up with a solution how to test that
06:04:46 <anssik> Louay: similar issues with HbbTV testing
06:05:13 <anssik> Francois: the test runner relies on user interaction, so testing receiving side where user interaction is not possible causes challenges
06:05:22 <anssik> ... this suggests is a good idea to start the testing activity
06:05:36 <anssik> ... we'd need a testing lead aka Test Facilitator
06:05:45 <anssik> ... it is a good role to have in a group
06:06:26 <anssik> ... it is good for that person to be not a person who already has a defined role in the WG, such as editor, chair
06:06:56 <anssik> Louay: I can look this and see if we could help with testing, will come back with an answer next week
06:07:29 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
06:08:02 <anssik> ACTION: Louay to talk to internal QA dept to figure out whether we can commit to work on testing
06:08:10 <anssik> Anssi: thanks!
06:08:48 <kinjim> kinjim has joined #webscreens
06:09:01 <anssik> Francois: an example: semantics when sending an empty message should be tested, in WebRTC
06:10:48 <anssik> Anssi: asking whether browser implementers has some tests to contribute
06:11:03 <anssik> Mark: happy to upstream relevant tests to w-p-t
06:12:20 <anssik> ... issues with features that are platform specific, how to act on browser UI controls
06:13:24 <anssik> Present+ Zhiqiang_Zhang
06:13:38 <anssik> Zhiqiang: we have some tests for Crosswalk
06:13:54 <anssik> ... Crosswalk project has an implementation of an earlier version of the spec
06:15:09 <anssik> Shih-Chiang: we are trying to split the tasks from the protocol layer
06:15:19 <anssik> ... so that we can use the protocol layer as the trigger point
06:15:31 <anssik> ... using protocol simulation
06:16:43 <tidoust> scribe: tidoust
06:16:56 <tidoust> Topic: Plans to advance on the Recommendation track
06:17:06 <tidoust> [showing an overview of the different steps]
06:17:41 <tidoust> Anssi: Starting from an Editor's Draft, then a First Public Working Draft, which leads to several iterations as Working Draft, until we believe we are feature complete.
06:17:56 <tidoust> ... At which stage, we switch to Candidate Recommendation.
06:18:21 <tidoust> ... To move to Proposed Recommendation, we have to provide an implementation report that we just talked about.
06:18:39 <tidoust> ... The hard part is indeed creating the test suite and having implementations conform to the spec.
06:19:02 <tidoust> ... Roughly speaking, we should publish one more drafts after TPAC.
06:19:18 <tidoust> ... And being optimistic, we would switch to Candidate Recommendation after that.
06:19:32 <tidoust> ... My suggestion is to start the testing effort as soon as possible as it may reveal issues with the spec.
06:20:14 <tidoust> ... Once you have the implementation report, there is not much to do to switch to Proposed Recommendation.
06:20:24 <tidoust> ... We have been doing good progress in this group.
06:20:36 <tidoust> ... Any question or concern with that?
06:21:42 <tidoust> Francois: Note the need to have horizontal reviews to switch to Candidate Recommendation, which we already started.
06:22:35 <tidoust> Mark: I think feature-wise we're mostly done. On top of open issues, I'd like to make an editorial pass on the spec to reorder this.
06:22:52 <tidoust> ... I'd like more concrete feedback from the Privacy group. Otherwise I don't see major issues to moving forward.
06:23:25 <tidoust> Anssi: That was it. I'd like to thank everyone from participating.
06:24:01 <tidoust> ... Thanks for the time at TPAC. Thanks Takeshi for the dinner organization! It will be long remembered :)
06:24:18 <tidoust> ... I'm confident that we can get the spec to the final stage in some near future.
06:24:40 <tidoust> [Meeting adjourned]
06:24:44 <tidoust> RRSagent, draft minutes
06:24:44 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/29-webscreens-minutes.html tidoust
06:25:00 <YxE> YxE has left #webscreens
06:26:11 <tidoust> i/Mark: Implementation of the receiving side/scribe: tidoust/
06:26:23 <tidoust> RRSagent, draft minutes
06:26:23 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/29-webscreens-minutes.html tidoust
07:02:38 <wonsuk> wonsuk has joined #webscreens
07:06:45 <oonishi> oonishi has joined #webscreens
07:23:20 <jcdufourd> jcdufourd has joined #webscreens
07:46:30 <mfoltzgoogle> mfoltzgoogle has joined #webscreens
07:56:26 <oonishi> oonishi has joined #webscreens
08:25:36 <mfoltzgoogle> mfoltzgoogle has joined #webscreens