Re: Poll for preferred API alternative

On Thu, Aug 30, 2012 at 3: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.
>

The argument made in the telco was that we should replace the current
design with the new CU-RTCWEB proposal, wholesale. As such I think the poll
in its current binary form is appropriate.




> 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 Friday, 31 August 2012 05:16:37 UTC