WebRTC Poll Result Analysis and Next Steps

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 Monday, 10 September 2012 13:48:53 UTC