Re: Call for Consensus (CfC) to publish a FPWD of "Capture Handle - Bootstrapping Collaboration when Screensharing".

I see a trend where the WebRTC WG adopts a document and very quickly, the roughly same document goes to FPWD.

This has some advantages (triggering the exclusion call sooner), but this has also some drawbacks.
In particular, this does not leave much time for the WG to try reaching consensus on the major issues, like the ones Jan-Ivar mentioned.

I think the minimum bar should be to list the potential contentious issues so that we can present/discuss them during a WG meeting.
Then spend some reasonable amount of time to reach consensus shortly before/during/shortly after the meeting.
Then, update the document if we reach consensus.
Otherwise document lack of consensus in the draft and continue reaching consensus in parallel.

We haven’t really done this for capture region and I do not feel great about it.
I think we should try to apply this for capture handle.
What do WG members think about this idea?

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.

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

Thanks,
 Y

> On 23 Mar 2022, at 00:14, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> This is a Call for Consensus (CfC) to publish a First Public Working Draft (FPWD) of "Capture Handle - Bootstrapping Collaboration when Screensharing".
> 
> The document is available for inspection here:
> https://w3c.github.io/mediacapture-handle/identity/index.html <https://w3c.github.io/mediacapture-handle/identity/index.html>
> 
> The github repo is here:
> https://github.com/w3c/mediacapture-handle <https://github.com/w3c/mediacapture-handle>
> 
> In response, please state one of the following:
> 
>   *   I support publishing a FPWD of the Capture Handle (identity) specification
>   *   I object to publishing a Capture Handle (identity) FPWD, due to issues filed in open bug <#number>
> 
> The CfC will end on April 6, 2022.
> 
> Bernard
> 
> For the Chairs