Anssi: Welcome back. See email I sent this morning. Proposed resolutions and actions manually labeled on GitHub.*
... [Looking at the agenda]

Matt: agree to postpone agenda topic on HbbTV as already addressed to some extent during day 1 and distilled in other issues, so fine not to have it as a priority topic today

Mark_Foltz: Some progress to show on designating a default presentation URL and on presenting the content of an <audio> and <video> element

Anssi: OK, let's reorder topics then.

Rethinking availability monitoring (#81)

See https://github.com/w3c/presentation-api/issues/81 issue #81 - Rethinking availability monitoring

Anssi: Trying to make developers life easy, availability monitoring was using a bit of an anti-pattern. Anton discussed with Mounir, Oleg and Mark Watson raised additional comments.

Mark_Foltz: Idea is, instead of having a global onavailablechange event, you would construct an event listener with "listenForAvailability" and then you either call "getAvailability" on that listener for a one-time use or attach an event listener to the onavailablechange property
... I did not have time to write code for that but that seems to work.
... The use case to check periodically for screens availability one time had not come up before. Our experience is that screens availability is something dynamic, especially if you are using a mobile phone.
... I would like to understand the use case for the one shot better.

Anssi: I can probably explain the use case I had in mind.
... "Find out whether there are available display(s), and if yes, show content on the display chosen by the user". My expectation was that the Web developer would just want to check for availability, and whenever there is a screen available, do something, else take another route.
... Let's take an example of a Web page that wants to project another Web page on a big screen. It would call "getAvailability", and when it resolves, you start the session, which prompts the user.

Mark_Watson: The idea is to display a "present" button when there are screens available. To do that, you have to start monitoring for screens as soon as the page loads and keep monitoring for changes afterwards

Oleg_Beletski: Same thing for Samsung where the button is greyed out. If you only need a one shot thing, you don't really need to start monitoring, startSession would be enough, would trigger monitoring and you don't need to monitor screens availability.

<anssik> http://w3c.github.io/presentation-api/#starting-a-presentation-session

Mark_Watson: So, startSession handles this, but some way to monitor available screens in the background would be pretty useful. Problem is enabling continuous monitoring when an event handler is attached to a property is considered bad practice, right?

Mark_Foltz: right.

Anssi: Adding an event listener should not have side effect, that's a shared practice.

Mark_Foltz: So, how does geolocation handle this?

Anssi: Example of the deviceOrientation. If your phone is staying flat and you attach an event listener, you will not get an event up until the phone moves. The spec cannot force the user agent to fire an event when the event listener is attached.

Mark_Foltz: OK, back to my proposal, we could have an "available" boolean property. Then you may want some way to dismiss the listener to stop monitoring.

Anssi: listenForAvailability could be getAvailability that returns an AvailabilityObserver that has a boolean and fires an "availablechange" event when the property changes.

Anton: It's up to the user-agent to stop discovery when the page goes to sleep. No need to explicitly close the event.

Mark_Watson: wondering about the need to have "onavailablechange" when you already have addEventListener, removeEventListener

Anssi: Mostly legacy. This is the way Web is working. The "on" way of attaching events is sometimes useful.

Oleg: During the lifecycle of the application, you may switch from one to two screens, then back to one, and so on. Monitoring available screens is an expensive process. Having a way to cancel the monitoring would be good.

Anssi: We should leave it up to user agents to implement "continuous" the way they want, meaning adjusting the frequency of discovery or prompting the user after some time for instance.

Oleg: I think discovery is the most costly operation in Miracast for instance

Anssi: My expectation is that you could get an availability observer with an available property set to "false" and that we would not mandate the user agent to run discovery in the background as such. The user agent could wait for the device to be plugged in before it resumes discovery for instance.
... That would be an acceptable implementation.

Oleg: I would still prefer to have a "cancel" method but we can add wording to warn developers that discovery can last until the end of the page lifetime. In geolocation, there is a way to stop listening.

Anssi: but not everyone does that.
... If you have a loop which alternates start/stop, it could be more costly for the device than just continuous monitoring.

Francois: Do we agree that calling listenForAvailability repeatedly will not trigger multiple discovery under the hood?

Anton: Yes

Mark_Watson: Note the spec should clarify that multiple calls to listenForAvailability must return different objects.

Schien: I'm fine with the direction currently discussed. One question I have is on the "params" parameter.

Anssi: Right, let's discuss this in the next agenda topic.

Anton: in Samsung, does discovery run only when you display the list?

Oleg: I think so, yes.

Mark_Foltz: We may want to make a small amendment to reject the promise if the device does not support continuous background monitoring then.

Anssi: I like it, yes.
... I think we're in agreement, updating the examples in sync with the changes would be good.

PROPOSED RESOLUTION: For issue #81, adopt proposal to have a "getAvailability" method on NavigatorPresentation that returns a Promise to get an AvailabilityListener (or observer) with a boolean "available" property and an "availablechange" event. Promise is rejected when user agent does not support background monitoring. startSession triggers discovery. No requirement on frequency of discovery (there may not be any in some period of time)

<mfoltzgoogle> mfoltzgoogle: One more thing: Ensure we specify how many AvailabilityListener objects get created when listenForAvailability() is called more than once.

<scribe> ACTION: Anton to update startSession example to use implicit discovery (pending pull request) [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action01]

<scribe> ACTION: Oleg to clarify implicit/explicit mechanisms in the spec, and review the relevant algorithms and examples. [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action02]

How to filter available screens according to the content being presented (#9)

See issue #9 - How to filter available screens according to the content being presented

Mark_Watson: Idea is to be able to filter screens that cannot display the content that you would want to display. Specifically relevent for DIAL apps for instance. You want to provide the URL at the beginning of the discovery.
... With the default presentation URL mechanism, this is actually covered.

Matt_Hammond: should we have a programmatic version as well?

Mark_Watson: In that case, the "getAvailability" method that we just discussed would address that.

Anssi: Generally, on the Web Platform, the developer tries things before he can know whether things work or not. This is a bit of departure.

Mark_Watson: You're not making the promise that it will work, you're just ensuring that pages know when it won't work

Jean-Claude: How would you know that the required app would be there?

<anssik> http://www.w3.org/TR/html5/embedded-content-0.html#dom-navigator-canplaytype

Mark_Watson: In the case of DIAL, it's the responsibility of DIAL to specify how to discover the app.

Anssi: The closest thing related to this that comes to my mind is "canPlayType" in HTML5.

Schien: Privacy concern. If you know that Netflix is not supported in the user environment, could you use that information to display relevant ads?

Mark_Foltz: Tying apps to origins might be a way to mitigate the problem. Up to DIAL in that case.

Mark_Watson: Good statement for the security and privacy section. If you have a discovery mechanism that allows you to tell which URL are supported and which are not, there should be some scoping by origin.

Mark_Foltz: The caveat that I would like to attach to this is that it really helps with DIAL. As soon as we have an HTML5 environment, this is kind of useless

Jean-Claude: Unless someone wants capability filtering

Mark_Foltz: Right.

Matt_Hammond: Instead of thinking it in terms of filtering, we could have it as a mechanism to hint on the specifics needed to support different mechanisms.

Mark_Foltz: The filtering would provide a better user experience.

Matt_Hammond: HTML5 as a fallback.

Mark_Watson: There may not be a compatible HTML5 fallback.

Anssi: I'm hearing Mark_Watson willing to have a mechanism to have remote capability detection.

Mark_Watson: The whole capability detection issue is a large and distinct issue. This is more restricted.
... Although the same solution could work in both cases.
... The goal is to find a reasonable solution with a good balance between UX and privacy concerns.

Mark_Foltz: Another direction would be to allow a page to force local content rendering.
... In the end, we have a mechanism in place and need to investigate more the privacy implications.

[some discussion on the default presentation URL and the fact that it can be used to filter devices as well]

<scribe> ACTION: Mark_Watson to look into privacy implications of filtering available screens according to the content being presented [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action03]

PROPOSED RESOLUTION: For issue #9, include a URL parameter to "getAvailability" (subject to amendments to issue #81) and update security and privacy considerations section based on privacy investigation.

Screen availability mechanism for multiple session (#40)

See issue #40 - Screen availability mechanism for multiple session

tidoust: if we want to support multiple screens, talking to multiple screen
... we don't know what happens to available boolean when you've already created the session
... and when you want to offer an app that can use three or four screen, it may prompt the user multiple times
... you may want to have only a single call that I may want to use multiple screens
... not sure if the spec should address it right now
... interested in two first points:
... 1) if I started a session, how do I know if there are still screens available

whywhat: user can still take the same device and start a session

schien: the best thing UA can do, on the trusted UA can show a flag of already user screens

tidoust: not worries about that, more about how the web app knows can call startSesssion() again

mfoltzgoogle: what is the use case? soccer game from two different angles
... maybe the UI is more like a "show me angle additional angle", should it be conditional to whether there are additional screens?
... adding an attribute to the AvailabilityListener for "are there unused screen available"
... our implementation has a definition of "unused screen"
... my questions: does this UC justify adding API surface to support this?

tidoust: I think this might be a v2 feature
... making sure we can add it while keeping backwards compatibility with the v1 API

mh: UA understands the sessions, their states

mfoltzgoogle: could make it explicit in the screen picker UI

markw: is there a UC for the web app to be able to say a certain screen cannot be reused, since the presentation is in progress, for example

PROPOSED RESOLUTION: no change to the spec, we may want to provide informative guidelines to the implementors on the screen picker UI with regard to best practices for highlighting screens that are already used by other presentation sessions, clarify we do not support multiple screen selections from the screen picker UI

Hongki: So, no multiple screen selections for this version of the Presentation API?

Francois: Right. If you feel strongly about this feature, the group needs concrete use cases that could be used to change the priorities.

Presentations from within nested browssing contexts (#79)

See Issue #79 - Presentations from within nested browsing contexts

mfoltzgoogle: default presentation source and what is the information source for browser context

schien: providing a browser ui to initialize presentation creates confusion for the user in case of nested contexts
... in Firefox there is a sharing icon to mirror the whole tab to the other screen, for default presentation UI FF will start presentation for default URL. That way we redefine browser behaviour.

Hongki: would like to create use case for nested browser context

<scribe> ACTION: Hongki update use cases to incorporate nested browser context issue [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action04]

<scribe> ACTION: Mfoltzgoogle Flush out behaviour of allow presentation attribute [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action05]

PROPOSED RESOLUTON: Clarify how multiple levels of nesting behaves

PROPOSED RESOLUTION: define a new "allowpresentation" content attribute for the HTML iframe element that controls whether default-presentation, startSession(), joinSesssion() are functional; define failure path in the relevant algorithms when this attribute does not exist, clarify how multiple levels of nesting behaves

Resumption of multiple sessions (#39)

See issue #39 - Resumption of multiple sessions

anssik: this is Francois proposal so please walk us through

tidoust: this is for the joinSession mechanism, what happens when you call startSession with the same url and id and if you can, what do you get when you call joinSession
... we probably shouldn't allow starting another session with the same url and id

mfoltzgoogle: I second that

tidoust: what happens when I call startSession with the same url and id? e.g. if the user selects another screen, UA closes the running session or...

mfoltzgoogle: we could have it always fail
... there's a use case to restart the terminated session which I'm okay with (the page recycles id)
... the alternative is to behave like joinSession if user picks the same screen but if I pick another screen the current session stops

whywhat: we have it stated in the use cases

mfoltzgoogle: automatic termination may be a little tricky, we should probably require an explicit close() from the page

mh: why do we require the presentation id to be passed by the page?

anssik: IIRC it was proposed by Jonas Sicking so that the page could share the id between the controllers (e.g. a game)

mfoltzgoogle: yes. we could omit the presentation id and let other pages join the same presentation session just by URL
... we could rely on the UA provided, hard to guess id and share it via local storage or cloud service to other pages
... we could also append it to the url but it felt cleaner to keep it separate

tidoust: if we don't have a good use case, we should drop it from startSession

obeletski: joinSession - does it join the locally started session or some session started by another controller? it's still confusing

tidoust: we did discuss something yesterday during the discussion of issue #19

obeletski: we can join session or we can join presentation, we should be more clear on the terminology

mfoltzgoogle: agree, this is a different concept, if we want to change the behavior to call startSession to pick the existing presentation - it would join the presentation

tidoust: does the user have to kill presentation first if she wants to start a new one?

mfoltzgoogle: yes, existing presentation will have to be closed explicitly

tidoust: do we still need presentation id for joinSession?

mfoltzgoogle: yes to avoid a random page/user connecting to the existing session without having to know the id

tidoust: then we have a malicious user / app problem to join the existing presentation

mfoltzgoogle: the presentation can't trust what's connected to it and adding an id would add a small security to it - the starter of the presentation would be trusted to share the id only to the right controllers

mh: I wonder how startSession that behaves joinSession map to HbbTV and DIAL? there's no guarantee that the right content is shown on the screen

tidoust: it seems like you can't implement joinSession (as in presentation) at all, no matter if you have the method or not

mfoltzgoogle: it depends on the presentation page whether to accept multiple connections, the spec should be clear

schien: q - we have three ways to receive a presentation session, we have two methods
... can we have three methods?

all: startPresentation, joinPresentation, resumePresentation|Session

mfoltzgoogle: hard to know what the user would pick - new screen or the one with the existing presentation

tidoust: we could show different screens for start and join
... we don't know if it's the first controller or not, so the page doesn't know what to call
... we perhaps should add a parameter to start session to specify if joining an existing presentation is okay or not
... later
... seems like the proposal is to remove id from startSession

mfoltzgoogle: we need a mechanism to join an existing presentation - either a new method or modify startSession

tidoust: it's probably related to issue #19
... limit ids to the UA session, note that the ids might be shared between UAs so might need to be more unique

PROPOSED RESOLUTION: drop id from startSession() without strong use case, the UA generates the id

Allow page to designate a default presentation URL enhancement (#26)

See issue #26 - Allow page to designate a default presentation URL

mfoltzgoogle: default presentation url gives a way to the UA to provide the best experience for the user if there's a default UI for presenting
... UA can also make the feature work more seamlessly if the user is streaming a tab and navigates to the presentation enabled page (e.g. navigated to YouTube - the UA starts the YT presentation)
... the other use case is voice action or a NFC tap or nearby proximity detection - present the url
... spec wise there's an implementation and spec changes in progress

anssik: schien what do you think from the Firefox point of view?

schien: not sure if the user would like to have the overridden behavior or the explicit behavior
... when I look at the default presentation url - developer needs to specify url in two places: the default one and the one for startSession
... if the page can create a session in advance and prevent default on the browser action - then the browser knows that the page has a specific way to handle the screen; if not, the browser can do its thing

mfoltzgoogle: walking through a scenario - user initiates the presentation via UA button, the browser sends an event to the page and waits if it will be handled by the page

schien: if the page handles the event, do nothing, if not, the UA defaults to tab casting
... we can prevent specifying the default url for that

mfoltzgoogle: how it would work from the implementation point of view? we would want to know if we need to start tab capturing or presenting the page's url

schien: the page would call startSession from |defaultsessionstart| and the UA would show the picker

mfoltzgoogle: setting up the UA would be hard beforehand if we need to wait for the page to do something

<scribe> ACTION: schien to write a proposed idl change for that [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action06]

schien: we seem to overload default presentation with many functionality

mfoltzgoogle: I'd like both Firefox and Chrome to come up with a good solution but it shouldn't be mandatory for other UAs to implement if the UA doesn't support tab streaming

PROPOSED RESOLUTION: review the two proposals and evaluate them against the use cases and requirements considering developers and implementors view points

URL schemes supported in presentation API (#76)

See issue #76 - URL schemes supported in presentation API

tidoust: what's the concern about limiting the schemes? Louay raised the issue but he's not here

anssik: we should define which schemes must be supported and leave the rest undefined

mfoltzgoogle: for me the content type is more important, we certainly support html content but not clear about files/mp4/data urls/webapps etc

PROPOSED RESOLUTION: do not restrict extensions that might want to make use of other URL schemes than http(s), however those alternative schemes are out of scope for v1

anssik: we have three issues left that seem to be hard to resolve in 7 minutes we have left before lunch; after lunch we'll have the MWS event and the closing session

Any Other Business

tidoust: we discussed streamlined way to publish drafts of the Presentation API spec; the process can now be streamlined with an automatic tool

<anssik> http://www.w3.org/2014/08/pubworkflow.html

tidoust: I suggest we do it and want to make sure the group is fine with this approach

anssik: it means the publications will happen when we did significant progress; I'll let Francois implement it for the group
... hear no concerns so let's do it
... thanks for your contributions and for participating in the event

[morning session adjourned]
[Open session on the Presentation API at Fraunhofer FOKUS 5th Media Web Symposium follows]
[F2F resumes after that open session]

Allow page to turn itself into a presentation session (#32)

See issue #32 - Allow page to turn itself into a presentation session

Summary of discussion during F2F wrap-up session: there may not be a need for a page to explicitly turn itself into a presentation session. The user agent could do that on its own (or asking for user permission first). The only part that may need to be adjusted to enable that use case is how the presenting page gets a pointer to the first session if it can be created after the page is loaded.

<scribe> ACTION: @tidoust to investigate possible adjustments to the spec to allow a presenting page to detect when the first session is created in that case. [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action07]

Also note that the page needs to run in private browsing mode for the user agent to be able to turn it into a presentation session.

Presenting the content of an audio/video element (#13)

See issue #13 - Presenting the content of an audio/video element

Anton: [showing proposal on screen]
... Pretty similar to what we have in our Cast extension. The Cast button appears as a video player control button, allowing the video to be casted to a separate screen.

<anssik> http://avayvod.github.io/chrome-android-remote-playback.pdf

Anton: It works well when the Web application does not use a custom UI for video playback.
... There are no API for remote video playback
... Also issues with subtitles and encrypted video.
... Based on that, the proposal is an extension to the MediaElement to add a "remote" attribute that kind of emulates the Presentation API.
... The object contains a "start" and "stop" method.
... Also the <source> element should be extended to disallow remote playback.

Anssi: Is it something that you have implemented?

Anton: It can easily be implemented.

Anssi: I like the approach. The migration path is very simple for the developer too.

Francois: getAvailability filters potential devices based on the source URLs and media type?

Anton: right

Anssi: Does it make sense to have this evolve in a separate spec?

Anton: I think so.

Francois: One thing I wonder about is, once you've strated, all media features do not necessarily apply to the remote playback, depending on the underlying protocols being used.

Anton: Right.

Anssi: [showing Big Buck Bunny video to demo video content presentation]
... +1 for the native implementation of that along the lines you suggest.

Matt_Hammond: The start and stop methods are not about starting/stopping the playback but rather about starting/stopping the session, right?

Anton: Yes.
... to the question of unsupported features, the MediaElement already supports that to some extent. We should just ensure things are properly specified.

Anssi: This work is in scope by charter, and we can organize the split in specs the way we want so it's fine to move forward.

[Francois mumbling about pros and cons of having one spec or two specs]

<scribe> ACTION: Anton to figure out a name for the spec and continue the work [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action08]

<scribe> ACTION: @tidoust to create the repo on GitHub for the spec once we have a name (and short name) for it. [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action09]

Anssi: Could be Media Presentation API

Louay: I note that the same mechanism could be used for images.

Francois: For images, I would say the regular Presentation API is enough since you're just not going to need the communication channel and not going to connect to features provided by the ImgElement in HTML5 except to extract the source URL.

Anssi: for the dummy case, it could be just a hint on the image element that the user agent could use to propose to render the image on an UPnP Photo Renderer.

Jean-Claude: It could be done with a JS library, no need to have a standard attribute.

Anssi: You mean we could take an image and turn it into a video with one frame.

Francois: using "poster"

Anssi: Exactly.

<anssik> http://www.w3.org/TR/html5/embedded-content-0.html#attr-video-poster

Francois: seems convoluted.

Anssi: right, could be used for prototyping.

[note that goal is to support constrained devices that can only render pictures, not videos]

Oleg: Wondering about the Web Audio API and chaining with the Presentation API. Also with the "sinkId" property that the Audio Output Devices API is defining.

Francois: good points, we will need to liaise with these groups and keep an eye on alignment.
... So, in summary, we have a good starting point, and a few questions that will come back to bite us afterwards, that looks good!

Add facility for the opening page to add cloud paired screens as presentation targets (#61)

See issue #61 - Add facility for the opening page to add cloud paired screens as presentation targets

Anssi: Last issue on our plate for this F2F.

Mark_Foltz: Basically, it would be a way to extend the way browser attaches to other screens by allowing pages to implement their own mechanism.
... We would need to make sure that the UI picker is pretty clear that the user agent is not responsible for these screens.
... Generally, from a practical point of view, on pre-DIAL TV platforms for instance, there is a way to control Youtube using out-of-band communications.
... I don't have a specific mechanism proposed yet, but looking for feedback on the idea.

Louay: I can show a demo on this.
... [showing demo]
... Currently I propose a cast button that display a simple dialog to launch the application on a virtual display.
... If the feature was there, this could be merged with other available displays.
... It's pure JavaScript.

Anssi: I'm thinking, from the spec perspective, whether the spec should care about the presence of the proxy.

Mark_Watson: The browser does not care about the device but needs to show it in the list

Mark_Foltz: we need some way for the page to register these devices and then inform the page that one of them has been selected.

Mark_Watson: maybe we should change the name of the issue because "cloud-paired" seems to require some cloud-based solution that may not occur in practice.

Francois: so no integration with the Presentation API once the user has picked up the screen?

Mark_Foltz: Right, what is a weird is that the session would not behave the same way as other possible sessions.
... I think it's a nice-to-have feature, not necessarily a must-have feature.

Anssi: summary is we could keep it as an open enhancement issue and revisit later on.

Wrap-up

Anssi: Thanks for participating. Sending my summary email right away. 10 days from now, proposed resolutions will become resolutions unless someone raises concerns before that.
... On to schnitzels!

Anton: Two small points as feedback for the F2F. One is we did change the agenda a few times over the last couple of days. The second point is that it's hard to discuss API changes without being able to see concrete proposals.

Anssi: True, maybe we can add something such as Etherpad or a Google doc.
... Very good idea, thanks for the feedback.

[F2F adjourned]