Re: WebRTC Poll Result Analysis and Next Steps

All,

based on input at the Telco Sept 17th, the chairs propose a slight 
rewording of the plan for moving forward:


* At this time, we will continue working on a design based on the
PeerConnection object and use of SDP at the API interface.
* We will continue to work on all items that have been raised as
possible technical issues. Not all of these will be ready for inclusion
in the first version of the spec (for instance, the timeline of the IETF 
RMCAT WG is well beyond where the first version of the W3C spec can 
expect to reference a standards-track congestion control mechanism), but 
we will strive to make available at the API level the tools that are 
clearly needed for any underlying implementation.
* Once the current specifications are completed, the WG will consider
again the possibility of making a different interface specification
available. This is contingent on:
- the continued perception that there is a need for another interface
- demonstrated ability of applications built on top of such an interface 
to interwork with applications built on top of the existing interface

Stefan for the chairs

On 09/10/2012 03:48 PM, Stefan Hakansson LK wrote:
> The chairs have analyzed the result of the poll, and based on that, we
> have created a candidate plan that we would like to seek feedback from
> the group on.
>
> Poll results
> ============
> The poll of opinion on the WEBRTC preferred API alternative closed on
> Friday, September 7, 2012 [1].
>
> At the time of closing, 26 individuals had been registered as giving
> their opinion, of which 17 were listed as representatives of
> organizations participating in the WEBRTC WG, and one has the status of
> “invited expert”. The chairs feel that this gives a fair sampling of the
> active participants both among people who are listed as representatives
> of their organizations and among people who are not.
>
> Of these 26, 4 supported "Alternative 2" and 22 supported "Alternative
> 1"; none indicated that they needed more discussion among the
> alternatives. Most supplied some reasoning with their indication of
> support; many of these indicated that the belief of the participant was
> strongly held.
>
> In the organization dimension, individuals representing 10 of the W3C
> member organizations that participate in the WEBRTC WG gave their
> opinion. For 8 of those 10, all individuals preferred "Alternative 1",
> for 1 all individuals  preferred "Alternative 2", and for the last 1
> there was an even split between "Alternative 1" and "Alternative 2".
>
> The chairs have discussed this situation, carefully considering the W3C
> consensus policies, the status of implementations, and the status of the
> specs, and have concluded that we will seek the consensus of the group
> behind the following candidate plan:
>
> Candidate plan
> ==============
> * At this time, we will continue working on a design based on the
> PeerConnection object and use of SDP at the API interface.
> * We will continue to work on all items that have been raised as
> possible technical issues. Not all of these will be ready for inclusion
> in the first version of the spec (for instance, the timeline of the IETF
> RMCAT WG is well beyond where the first version of the W3C spec can
> expect to reference a standards-track congestion control mechanism), but
> we will strive to make available at the API level the tools that are
> clearly needed for any underlying implementation.
> * Once the current specifications are completed, the WG will consider
> again the possibility of making a lower layer interface specification
> available. This is contingent on:
> - the continued perception that there is a need for such an interface
> - demonstrated ability of applications built on top of such an interface
> to interwork with applications built on top of the existing interface
>
> Note that feedback on the plan proposed is most welcome.
>
> This timing requirement does not mean that work needs to wait; it just
> means that the WG will not formally adopt such a specification as a work
> item before the Last Call is issued on its present documents. WG
> participants are of course free to work on whatever proposal they desire
> to work on.
>
> Background
> ==========
> The chairs looked at the options for getting consensus.
>
> The alternatives in the poll were laid out to focus on a couple of
> identified actions that differentiate the CU-RTC proposal from the
> PeerConnection proposal. These are actions that need to be either taken
> or not taken.
>
> There is no sign that further discussion would bring a number of people
> to a clear opinion that don’t currently have one - there is no support
> for option 3 in the poll.
>
> There is also clearly very little hope of gathering a consensus behind
> either removing SDP or removing the PeerConnection object from the API -
> there is too little support for "Alternative 2", and too much vocal
> disagreement with it.
>
> Therefore, by the rule of "whenever you’ve eliminated the impossible",
> the only reasonable approach that can lead to a consensus position is
> one that is based on Option 1 - going ahead with a proposal that
> includes SDP and the PeerConnection object.
>
> However, we recognize that some people would prefer to build
> applications that do not touch SDP in any way, shape or form. Thus, it
> makes sense to make sure that as far as possible, communication can be
> achieved without touching SDP. We also recognize that the exact use of
> SDP and SDP features is currently underspecified, making it difficult to
> build interoperating UA implementations, and, for the interop to legacy
> cases, difficult to write applications that modify the SDPs to enable
> interop. This is something that must be sorted out, the main
> responsibility for this lies with the IETF rtcweb WG.
>
> Stefan for the chairs
>
> [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0211.html
>

Received on Wednesday, 3 October 2012 16:37:04 UTC