Summary of the CfC to publish a FPWD of "Capture Handle - Bootstrapping Collaboration when Screensharing"

The Call for Consensus (CfC) to publish a First Public Working Draft (FPWD) of "Capture Handle - Bootstrapping Collaboration when Screensharing" concluded on April 6, 2022.

The original announcement is here:
https://lists.w3.org/Archives/Public/public-webrtc/2022Mar/0068.html

6 responses were received:

In favor:
Bernard Aboba (with comments): https://lists.w3.org/Archives/Public/public-webrtc/2022Mar/0072.html
Elad Alon: https://lists.w3.org/Archives/Public/public-webrtc/2022Mar/0073.html
Harald Alvestrand: https://lists.w3.org/Archives/Public/public-webrtc/2022Mar/0091.html
Carlos N. Reina: https://lists.w3.org/Archives/Public/public-webrtc/2022Mar/0088.html

Objection:
Jan-Ivar Bruaroey: https://lists.w3.org/Archives/Public/public-webrtc/2022Apr/0021.html

No opinion expressed:
Youenn Fablet: https://lists.w3.org/Archives/Public/public-webrtc/2022Apr/0025.html

The Chairs will discuss next steps.

Bernard
For the Chairs


Appendix

Bernard's comment was as follows:

"I would like to mention two issues in the repo (neither of which need to be fixed to publish the FPWD).

Issue 35<https://github.com/w3c/mediacapture-handle/issues/35>: [Enhancement] Expose Content-Hint.   This potential enhancement (filed by Elad) strikes me as potentially useful.
Issue 43<https://github.com/w3c/mediacapture-handle/issues/43>: Tab capture restriction. This one I filed myself.  It's more of a question than an Issue."

Jan-Ivar's objection was as follows:

"I object to publishing a Capture Handle (identity) FPWD, due to issues
filed in #11 and #12.

There’s disagreement in #11 over whether setCaptureHandleConfig, as
defined, is too powerful: it is meant to be a bootstrap for a cross-origin
messaging channel, not be one itself. If implemented as-is, my concern is
applications might immediately become dependent on its side-effects, since
misusing it as a local messaging channel seems simpler than its designed
purpose (setting up e.g. a RESTFUL api to reach cross-origin) in many cases.

There’s disagreement in #12 over API shape, whether getCaptureHandle()
belongs on the track. Tracks are designed to be cloned and even transferred
to workers. It seems undesirable that a cross-origin messaging channel be
given to all media consumers. Instead, a dedicated CaptureController object
that is neither cloneable nor transferable seems a superior location, to
separate control (affecting all tracks) from consumption of a single track.

The reader of the FPWD should be made aware of these outstanding issues in
the document itself.

The process [1] states:

*"For all Working Drafts a Working Group:*

   - *should** document outstanding issues, and parts of the document on
   which the Working Group does not have consensus, and *
   - *may** request publication of a Working Draft even if its content is
   considered unstable and does not meet all Working Group requirements."*

Assuming there are no other objections, my objection can be resolved by
documenting the above lack of consensus as Notes in the document itself,
like we recently did for Region Capture.

[1] https://www.w3.org/2020/Process-20200915/#maturity-levels
[11] https://github.com/w3c/mediacapture-handle/issues/11
[12] https://github.com/w3c/mediacapture-handle/issues/12 "

Youenn's comment was as follows:

"As of the particular WG draft, I have the following feedback, given on webkit-dev mailing list a month or so ago.
1. The use cases are fine, although the proposal is currently restricted to tabs having a tight coordination (same origin typically). Reducing a lot the level of required coordination between capturee and capturer seems like an important requirement.
3. The current API allows to share a single string for all capturers no matter the capturer origin (as long as origin is in the allowed list). It seems that identity could be different depending on the capturer origin. For instance, a capturee could expose its context ID (https://w3c.github.io/ServiceWorker/#client-id <https://w3c.github.io/ServiceWorker/#client-id>)) if capturer is same origin but just its origin for all other capturers. Replacing the allowed list mechanism by a map-like API would be more flexible without adding much complexity.
4. The idea is to share identity from captured page to capturer page. On the web, the foundation of page identity is origin. The current API allows exposing a partial identity, i.e. an application-provided string without the origin. The scenarios in the document do not motivate AFAICS this 'partial' identity. It seems origin should be the first thing a captured page might want to share if it desires so. The fact that, by default, the origin is not exposed is not encouraging either.
5. Some of the usecases would be better suited with their own specific solution (use case 3 and 4 for instance, a property that directly tells whether capturee === capturer). I think they should be pursued on their own and removed from the document.
6. Capture handle creates a one way broadcast/postMessage-limited-to-string mechanism if capturee repeatedly calls the capture handle API as events will be fired on capturer for each API call. If introducing a messaging API as use case #1 mentions, this mechanism might become redundant with this future messaging API. It would be good to consolidate the current proposal based on use case #1 next steps.
7. Capture Handle Identity is really about screenshare, not about camera/microphones, it would be good to make that clear in the links/spec short names."

Elad's response was as follows:
"[Elad] I think this is a *great suggestion*. I think we should do that, and we can *in
addition* do even more. The editors of documents maintained by this WG
currently meet once a week for one hour and discuss all documents together
in no particular order. How about we set up bespoke meetings for new
documents? Ultimately, I believe we'd be investing *less* time if we do so
in a concentrated manner. The following documents would benefit of this
treatment:

   - Capture Handle Actions
   <https://w3c.github.io/mediacapture-handle/actions/index.html>
   - Capture Handle Identity
   <https://w3c.github.io/mediacapture-handle/identity/index.html>
   - Viewport Capture <https://w3c.github.io/mediacapture-viewport/>
   - Region Capture <https://w3c.github.io/mediacapture-region/>

I’ll try to find some time this week to file corresponding issues if nobody beats me to it.


[Elad] Thank you. If you also send a PR to document these disagreements, that'd
also be greatly appreciated. As these are your objections, you're most suited to formulate them accurately."