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

>
> Then spend some reasonable amount of time to reach consensus shortly
> before/during/shortly after the meeting.


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.


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.

On Wed, Apr 6, 2022 at 9:35 PM Youenn Fablet <youenn@apple.com> wrote:

> 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)) 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
>
> The github repo is here:
> 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
>
>
>