CG rechartering

[wayneca]

possible charter for second screen CG

@anssiko and I were discussing the possible new work for the CG to define a standard way to use the 2 UA second screen over a network. That would require changing the charter to allow the work, so I wrote an example draft charter.

Having an example architecture helps (at least us) getting permission to work on it -- so people have a rough idea of what a spec like that would be like.

[mfoltzgoogle]

I assembled some internal notes and put them on GitHub. Consider this an initial architectural proposal from Google. It is scoped to 1-UA mode, 2-UA mode, and remote media playback.

https://github.com/mfoltzgoogle/freeplay

There is a bit of chicken and egg. Until the scope of the charter is fleshed out then it will be hard to draw up a conclusive architecture. For example, if we include alternative discovery (i.e., Bluetooth) and communication mechanisms (i.e., cloud mediated) then the architecture will look quite different.

Above, I have scoped things more narrowly as I believe this will get us further traction on this work.

[louaybassbouss]

@wcarr thx for the draft charter. You mentioned some technologies/protocols in the Discovery section but I think concrete discovery and communication protocols should be decided later in the group. For example, BLE is also a potential technology to discover displays around me. What do you think?

[louaybassbouss]

@mfoltzgoogle thx for your proposal. Just one comment from my side: In the Presentation API we consider for now Web Content (mainly web pages) but on the protocol level we may need to be more generic e.g. to launch any kind of applications: a native mobile application (Android, iOS, etc.) may use the Freeplay protocol to discover Displays that provides a specific App (e.g. using App specific URL-scheme like vnd.youtube:// to discover Receiver Devices that support YouTube for example YouTube on Android TV). TV manufacturers can also use the same protocol to launch native Smart TV Applications.

[anssiko]

Thanks @wcarr, @mfoltzgoogle, and @louaybassbouss for your input!

All - please provide your feedback and further input with regard to the proposed Community Group rechartering that we initiated at F2F. You may just +1 if you think you'd be interested in contributing to the definition of such interoperable protocols for the Presentation API to allow us gauge the level of interest.

(This issue was opened as a response to an action from the F2F.)

[schien]

I put the implementation details on https://wiki.mozilla.org/WebAPI/PresentationAPI and I'm continuously adding more information onto the wiki page.

[wayneca]

@louaybassbouss The idea of the example architecture is in the bold paragraph right before the first example:

The following description is intended as an example architecture for a specification that this group will work on. It is included to make it clearer what type of work the group is limited to for the specifications. The group does not have to adopt this specific architecture, but it does describe the permitted scope of that the group can create a specification for. "

The CG doesn't have to adopt that specific architecture, but it clarifies what types of things need to be figured out.

Like BLE would be fine in what the group comes up with, but does show a pretty likely direction. I've added that draft charter.
(https://wcarr.github.io/cg-charter/SecondScreenCharterProposal20151110.html)

[mfoltzgoogle]

@wcarr Thanks for putting an initial draft together for feedback.

I am quite concerned that the proposed scope of the carter omits the 1-UA case. This was specifically mentioned as important by me in the Sapporo F2F. In fact this could be an easier use case to achieve interoperability because there is a complete, self contained, open source implementation available (WebRTC).

Imagine having a Raspberry Pi hooked up to a TV. Many HTML5 documents will perform poorly given its memory and CPU constraints and lack of GPU. But it is perfectly suitable for rendering a WebRTC stream at 720p or better.

I think the wording of the example architecture could be improved. For example it would be better to list specific requirements for each of the components and list example technologies that could be listed to implement them.

The charter should make clearer what specifications may be produced. In IETF style, the specifications will more likely follow the architectural layering and not the use case. For example there could be a specification for LAN discovery and control via TCP/IP, discovery and control via BLE/GATT, and a signaling protocol layered on top of either - that would be three specs.

There is no way to send control messages via DIAL so I don't think it's worth mentioning as an example technology. It simply does not meet the baseline requirements for Presentation API.

I don't want to overpromise on BLE. It can be used as a discovery mechanism but to implement control would likely require going through the Bluetooth SIG to register a new GATT service type. The security architecture is a bit of a mystery as well. I think it is a promising technology but I don't want to commit to it in our scope until due diligence has been done.

[mfoltzgoogle]

@louaybassbouss I think it's reasonable for the protocol to include some mechanism for vendor extensibility to additional URL schemes and/or content types. If an app ecosystem wants to re-use our work to facilitate launch and control, that's fine. Anything beyond that is really out of scope IMO, as the point of this work is interoperability among browsers and displays, and apps are tied to relationships between specific vendors and content providers.

[mfoltzgoogle]

@wcarr If you agree with my points would you like me to prepare a PR to address them in the draft charter?

[wayneca]

@mfoltzgoogle The intent was @anssiko (who I'd been talking to about that particular use case) would copy it to the CG repo and then develop it with particular issues on the draft charter there. I was thinking @anssiko would edit it and we'd close this Issue just in deciding whether to use it as a starting point or not. (the process part has improvements developed in several other charters)

[mfoltzgoogle]

@wcarr @anssiko If the plan is to get the process boilerplate out of the way and develop the content of the charter in the CG repo that seems fine. However it sounds like we don't have consensus on scope and deliverables. Please remove these sections before moving to the CG repo so they don't become de facto defaults.

[karim76]

@louaybassbouss I think that using the BLE idea for discovery is very interest to me. I can imagine the system that TV will send own information (IP, available state, etc,.) via BLE, and mobile can get this. After getting the information, Mobile will try to connect to TV via IP.

I have only one concern about above scenario. If Mobile and TV are not used same IP network, I think that they can't connect each other on the 2-UA. But, BLE do not consider about IP network, Mobile can get TV information via BLE and display to devices list.
Of course, existing other discovery solutions (mDNS, DIAL,...) are assumed same network (same hub, or same AP,...). In this case, I have no need to be concerned for connection.

If you have any idea or solution for above my concern, please let me know.
Thank you.

[louaybassbouss]

@karim76 thx for your feedback I agree with you about your concern if devices are not in the same network and but there are cases where BLE makes sense. Example: Present on a Display as guest (Controller and display are not in the same network but both are connected to the internet). In this case BLE will help to discover the display and maybe exchange some signalling information and launch the presentation. for communication WebRTC can be used. This should be possible even if the devices are not in the same network. BLE can be used as signalling channel e.g. to exchange WebRTC metadata (offer, answer, etc.). It is also possible to use WebSocket for the communication instead of WebRTC but this must be routed over a cloud server. In this case, during the BLE discovery the display sends its remote Endpoint and the controller connects to it.
To makes things clear: my proposal was only to put BLE in the discussion but not necessary as main protocol for discovery. maybe as additional optional protocol if we see there are relevant use cases for it. most currently available presentation devices (mainly TVs and streaming devices) support IP based discovery protocols (mDNS/DNS-SD, SSDP) and we should consider them first.

[anssiko]

Thanks for the input to date everyone! It looks like there's sufficient interest to look into rechartering the CG.

First, I'd like to clarify the expectations with regard to the process of CG rechartering:

Since we have multiple proposals on the table (which is good) and the scope is still being discussed, we will not take a single proposal as a starting point. Rather, we'll synthesize and iterate on the charter proposal considering all the input.

How we handle this concretely: I'll create a GH repo with only the common charter boilerplate in it (using the CG charter template), and from there onwards we'll use the usual GH workflow (PRs, issues) to evolve the CG charter until we're happy with it.

As a general guideline, it usually is a good practice to keep the scope tighter rather than looser and be as specific as possible in terms of expected deliverables. I propose we continue to use the process we have for the current charter that allows amendments to the charter subject to adequate support. This will allow us to add new work more easily as we learn more.

I will move forward with the practicalities latest next week. Meanwhile, please keep the good discussion going in this issue, and provide further input.

[tidoust]

I think the main reasons for starting this work are:

1. to define a base set of protocols that Presentation API implementers can refer to to implement the spec;
2. to improve interoperability between implementations, i.e. the possibility to associate a presentation controller with a presentation receiver even if they have not been implemented by the same user agent.

While I would love to see all possibilities covered, I would initially restrict the scope to developing the necessary glue around technologies that participants can agree on and plan to implement right away. For instance, mDNS appears in all proposals/implementation plans, so it seems like a good starting point for discovery. BLE could perhaps be addressed later on.

The charter should leave the door open for the CG to write requirements for additional technologies in any case (the proposed draft charter allows that), even though related technical specifications remain out of scope.

It should be relatively easy to update the CG charter to extend the scope once participants agree that some other technology needs to be covered. Well, at least it should be easier than doing the same thing in a Working Group.

[anssiko]

I've now created a webscreens/cg-charter repo for the Second Screen Community Group (CG) rechartering discussions and primed it with a CG Charter template that contains the common boilerplate. I left Scope of Work, Out of Scope, and Deliverables sections essentially blank to be filled in with your help.

Let's continue this discussion on CG rechartering in the corresponding GitHub issues in the webscreens/cg-charter repo (and don't forget to watch that repo, since this WG mailing list will not be notified of changes in the CG repo).