Re: Scoping WebRTC 1.0

On 07/07/15 20:24, Peter Thatcher wrote:
> I'm supportive of the proposed process of, basically, "have a PR by
> September if you want it in 1.0".  I like how it's is a clear definition
> of what we need to look at in September, and gives us all impetus to get
> things done by a certain time.

Thanks for the feedback Peter. And note, we're talking about a 
"relatively baked PR", meaning the quality is good and that it has been 
around for some time to allow people to review and comment.

>
> By the way, I plan on getting out PRs for the following soon, certainly
> before September:
>
> RtpSender/RtpReceiever.getCapabilities (had good consensus at TPAC 2014)
>
> RtpEncodingParameters.maxBitrate (not as clear consensus, but lots of
> people mentioned the need at TPAC 2014)
>
> RtpSenderInit (has rough consensus on the list)
>
> SctpTransport (had rough consensus at TPAC 2014, and on the list in Nov
> 2014)

Thanks for the heads up.

>
> On Mon, Jun 29, 2015 at 11:31 PM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     Sorry for a rather long mail. It is about the scoping of WebRTC 1.0, and
>     the mail has three parts, “background”, “proposed process” and
>     “features”. We are especially eager to get feedback on the proposed
>     process *by July 10*, so if you’re going to read only one part read that
>     one.
>
>     Background
>     ==========
>     We think it is time to revisit the WebRTC 1.0 scope again. We made an
>     attempt late 2013, and at that time used the spreadsheet in [1] as basis
>     for the discussion.
>
>     We were not hugely successful at the time, but we think things are
>     different now. For one, many of the features discussed at that time are
>     now part of the spec (or in PR’s being actively discussed). Secondly,
>     the new Charter we will (hopefully) operate under soon [2] list “WebRTC
>     next version” as something that will get to FPWD Q1 2016 - this means
>     there is a clear place for the features we determine be beyond 1.0 to
>     go. And thirdly, the charter also says that WebRTC 1.0 should reach CR
>     in Q4 this year, meaning we should get serious on what is in and out of
>     it soon.
>
>     Proposed process
>     ================
>     We think that we should use the upcoming face-to-face meeting in
>     September to determine what is in 1.0. And in order to be “in” we will
>     require that the group (at the meeting) has consensus for the feature,
>     and that a relatively baked PR exists.
>
>     This means that proponents of features must use the time up to the f2f
>     to create and refine PRs, push for discussion on the list, and that the
>     group must help by providing feedback.
>
>     Is this a process we can follow? *Please provide feedback by July 10!*
>     Silence will be interpreted as being OK with this process.
>
>     Features
>     ========
>     Looking at the old 2013 spreadsheet in combination with github Issues
>     and PRs, it to us looks something like (note, this is not an official
>     position in any way, it is just an attempt to sort features based on our
>     understanding of where we are currently):
>
>     Features from 2013 labeled “Not in 1.0” that are now in the spec
>     ----------------------------------------------------------------
>     *RtpSenders/Receivers
>     *Rollback in state machine
>     *Track rejection (though we have the detail of making sure the rejected
>     track is not part of future offers)
>     *Bundle tuning
>     *Call hold
>     *Certificate handling APIs
>     *Identity
>
>     Features we seem to have consensus to add, need to sort details
>     ----------------------------------------------------------------
>     *replaceTrack
>     *unassigned media handling (PR #29 goes a bit)
>
>     Features where we have PRs/active discussion, but not clear
>     consensus to add
>     ---------------------------------------------------------------------
>     *ICE object
>     *DTLS  object
>     *codec parameters on RtpSenders
>
>     Features at risk for in 1.0 (may revisit in post-1.0 work)
>     ----------------------------------------------------------
>     *Partial offers/answers (no discussion or progress in IETF or W3C -
>     probably not in scope for post-1.0 either since it seems we're moving
>     away from SDP)
>     *API for Simulcast/SVC
>     *https://github.com/w3c/webrtc-pc/issues/4 CSRC added to RtpReceiver
>     *https://github.com/w3c/webrtc-pc/issues/5 indicate if temporal or
>     spatial video quality is most important - RtpSender
>     *ICE pool size
>     *Worker support for data channel
>
>     Stefan for the chairs
>
>     [1]
>     https://lists.w3.org/Archives/Public/public-webrtc/2013Dec/att-0076/Chairs__proposal_for_WebRTC_1.0_In_2FOut_-_W3C__1_.pdf
>
>     [2] http://www.w3.org/2015/06/webrtc-charter.html
>
>

Received on Wednesday, 8 July 2015 06:19:04 UTC