Re: Poll for preferred API alternative

We used a whole interim meeting to discuss your proposal and now you don't want us to ask if we should adopt your proposal? That is rich. 

As usually, my belief is that Microsoft has a huge financial incentive to create as much delay as possible on all the WebRTC work.


On Aug 30, 2012, at 4:52 PM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:

> I cannot answer any of the three proposed alternatives because I have to objection to the substance of this "poll".
> 
> On the call, it was clear that there were at least three, if not four, areas of possible contention. One was "the stuff we all agree needs to be added", and I don't think we need a poll for that. The second (and third, if split) was the use of SDP as the API surface, and in particular the use of SDP Offer/Answer semantics with that API. And finally was whether PeerConnection should be replaced by a larger number of objects with more specific functions.
> 
> So in that sense, the below poll fails to allow participants to express a desire for (for instance) removing the Offer/Answer state machine and possibly SDP while keeping the existing PeerConnection object.
> 
> In addition, I believe that conducting the poll in the below fashion will fail to meet the guidelines specified at http://www.w3.org/2005/10/Process-20051014/policies.html#managing-dissent ...namely the statement,  "Groups SHOULD favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people."
> 
> A poll which attempts to determine what creates the weakest objections for each of the points of contention would be appropriate. (By, for instance, asking which alternatives one could live with vs. what would be highly objectionable.) One which attempts to lump the issues together and determine what is supported by the largest majority is not. The below statement "If this call results in a clear preponderance... the WG chairs will take that as direction" combined with the questions posed DOES NOT COMPLY with the W3C process as I understand it.
> 
> Matthew Kaufman
> 
> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
> ...
> 
> The two alternatives, as the chairs see them, are the following:
> 
> 1) Continue with a design based on the PeerConnection object, using SDP as part of the API, roughly in the style of the current API description.
> 2) Remove the PeerConnection object and all use of SDP from the API, and pursue an API roughly in the style of Microsoft's CU-WebRTC proposal.
> 
> In order to make this call, we're calling for the WG participants to make their opinion known, by indicating one of three alternative opinions:
> 
> 1) The group should continue with a design based on the PeerConnection object, using SDP as part of the API.
> 2) The group should remove the PeerConnection and all use of SDP from the API, and pursue a design based on the CU-WebRTC proposal.
> 3) This participant does not have enough information to state an opinion at this time.
> 
> The chairs will make the result of the opinion tally public after the end date.
> 
> If this call results in a clear preponderance for one of the alternatives, the WG chairs will take that as direction - if the last alternative has a clear preponderance, the WG chairs will direct the WG pursue further discussion of this topic only, putting all other work on hold until this is resolved; in the two other cases, the chairs will direct the WG pursue the chosen design option, and leave the other to others to follow up if they wish, but not drive it further in the WG.
> 
> This is not a vote - it is a tallying of opinions. If a preponderance of preference is clear, the chairs will ask the WG if it agrees that a consensus exists to proceed based on that preference.
> 
> Please state your opinion before Friday, Sept 7, and communicate this to the chairs. Mail to the list is an acceptable means of communicating your opinion.
> 
> Stefan for the chairs
> 
> 
> 
>

Received on Monday, 3 September 2012 15:03:32 UTC