Re: Revisiting process to merge -extensions into -pc?

> In particular, I wonder if something like the WHATWG's Stage 3
> "Committed" wouldn't be a better fit - i.e. if it's clear that two
> implementers are ready to adopt the feature, adding that feature as a
> candidate addition to the main spec would seem pretty reasonable to me.
In an ideal world, the difference would just be the timing, right? I mean, if
implementers always implement what they have committed to.

I think spec maintenance and development is easier when the feature
is added to the main spec (it is easier to avoid misalignment if things happen
in the same document for example), and for API users it is also simpler.

So I think it is a good idea.

Stefan

On Fri, Mar 29, 2024 at 10:29 AM Dominique Hazael-Massieux <dom@w3.org> wrote:
>
> Hi,
>
> Our post-Rec guidance requires that only features that gain double
> implementation should be incorporated into the main webrtc-pc spec:
>
> https://github.com/w3c/webrtc-charter/blob/gh-pages/merge-guide.md#documenting-implementations
>
> I noticed that we have at least one such feature to consider,
> jitterBufferTarget:
>    https://github.com/w3c/webrtc-pc/issues/2952
>
> That being said, I also wondered if we shouldn't relax a bit our
> expectations in terms of merge requirement (which kind of happened
> organically e.g. for adding RTCIceCandidate.url/relayProtocol which
> aren't implemented twice yet).
>
> In particular, I wonder if something like the WHATWG's Stage 3
> "Committed" wouldn't be a better fit - i.e. if it's clear that two
> implementers are ready to adopt the feature, adding that feature as a
> candidate addition to the main spec would seem pretty reasonable to me.
>
> Thoughts?
>
> Dom
>

Received on Monday, 1 April 2024 12:05:51 UTC