A concern during TAG review has been raised by @annevk regarding the potential for user lock-in to a particular vendor's products because of poor interoperability between implementations. In this case we are concerned with interoperability between user agents (for the 2-UA implementation) and between user agents and "dumb" wireless displays (for the 1-UA implementation).

Note that in the charter [1] we explicitly designated the standardization of the network protocols for display discovery, control and communication as out of scope for the work of this group.

Once everyone is back from vacations, this issue can track the work item to discuss the status of interoperability and the plan moving forward. This is an important item and I want to ensure everyone has a say.

[1] http://www.w3.org/2014/secondscreen/charter.html#scope

Source for this issue is @annevk's feedback on www-tag and the follow-ups to the thread.

All - this issue raises an important point. Please familiarize yourself with the topic.

I am back from vacation and can investigate on this issue. As a first step we can collect most relevant technologies/protocols that my be relevant for the 1-UA and 2-UA implementations. What do you think?

Thanks @louaybassbouss. That would be good data to orientate us on the landscape, help make an informed decision.

As noted, such network level protocols are explicitly out of scope for this WG under its current charter. However, they might be specified in another group or SDO. There's some precedence for such setup e.g. in WebSocket API and its protocol, or the most recently WebRTC. In the case of WebRTC, some aspects such as the signalling channel "is provided by unspecified means" i.e. no single protocol is mandated which sounds like the situation with the Presentation API currently. That is not helping with interoperability either, just noting to draw some parallels to other efforts that are ongoing.

@louaybassbouss : As said in #164, I would really be interested in explicit definition of 1-UA and 2-UA but also in a relevant technologies and protocols as examples.

That sounds great. Please proceed!

@louaybassbouss Thanks for getting the ball rolling on this. Markdown is great for this type of complementary material. Since this doc would not be on the Rec Track, we'd be fine with contributions from non-participants too. @tidoust let us know if we'd need to add some language to the doc to make that aspect clear.

As usual, the first commit does not need to be perfect or complete -- we'll iterate on it based on feedback.

@anssiko Also the contents would be mostly informative, so no worries to have on the patent policy front. On top of a welcoming invitation for everyone to contribute, I don't think we need to add any specific language.

I just submitted a new PR #175 with initial version of the interoperability document.

It seems very wrong to me by the way to design an API on top of a protocol for which the patent landscape is unclear @tidoust. This happened before with <video> and the result has not been great.

Which protocols are you most concerned with, @annevk ? Discovery, launch, communication, streaming?

Right now, the API is not designed on top of any particular protocol, more because there were different valid solutions and it seemed great to have a common API on top of them, than because of patent issues. I definitely get the point on interoperability, which is what the group is now investigating. Do you also mean to say that there must be a way to implement the API on top of RF-licenced protocols?

Yes of course. We can't just ignore parts of the technology stack.

Also see the review of the Presentation API prepared by the TAG:

[[
This proposal breaks new ground in that (outside of web driver) this API has the capability of launching new browsing context sessions on potentially physically remote devices. The proposal does not attempt to define any of the transport layer functionality that would make these connections interoperable, such that we can only assume that the feature can only be supported by different instances of the same user agent running on both the "controlling" device and the "presenting" device. (However, the spec does allow for scenarios where the user may wish to present to a second screen that is physicaly connected to the same device.)
]]
https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md

See relevant discussion at TPAC F2F:
http://www.w3.org/2015/10/28-webscreens-minutes.html#item02

ACTION: Anssi to trigger the re-chartering discussions of the Web Screens Community Group around the idea of interoperable protocols
ACTION: Anssi to draft a reply to issue #153 based on F2F discussions
ACTION: Mark to craft a PR to investigate requiring (or strongly recommending) support for attached displays

Looping in this issue:

After TPAC a repo was created for discussing the idea of interoperable protocols for the Presentation API. A venue for these discussions was proposed to be the CG. We received some initial input based on which I crafted the initial draft CG charter structure.

• Draft CG charter: https://webscreens.github.io/cg-charter/

For future contributions toward this protocol-level issue, I'd ask to use the following repository:

• Repo: https://github.com/webscreens/cg-charter
• Issues: https://github.com/webscreens/cg-charter/issues

We haven't yet progressed on the protocol-level discussion far enough to say we'd be ready to recharter the CG. Thus I'd like to keep this issue open and encourage interested people to submit their feedback and proposals.