Re: Microsoft API Proposal

Matthew, thanks for this reformulation!

It seems to me that a lot of the points you make below are already on 
the table in different contexts, many of which have languished because 
they were not being pushed while people were off implementing the stuff 
required for interoperation. (at the moment, we have people reporting 
interworking between Chrome and Asterisk + some other "legacy" devices).

When I read the Microsoft proposal first, it seemed to me that a core 
feature of the proposal was 3 "no"s:

- No PeerConnection object (replaced with a cloud of transport-related 
entities)
- No SDP description (replaced with a cloud of APIs on those 
transport-related entities)
- No mandatory-to-implement codecs (not replaced with anything)

It so happens that I (as a technical contributor) disagree with all 3 of 
those proposal components; if you're happy to work on a successive 
refinement of current proposals without necessarily insisting that those 
3 removals be done, I'm sure we'll find easier ways forward.

             Harald


On 08/27/2012 10:10 PM, Matthew Kaufman wrote:
> In order to further clarify, I think it makes sense to consider the "Microsoft API Proposal" as a proposed set of deltas from the existing edit of the document. It was written in full specification format in order for clearer reading of some of these deltas that are fairly significant.
>
> I'm not sure what would be easiest for the editors or chairs, but perhaps it would make sense to take a list of these individual differences and turn them into issues in the issue tracker to be resolved. Some of these are quite non-controversial, such as congestion feedback information that we have proposed exposing that others on the list have agreed should be exposed but for which APIs are not yet documented. Others, of course, will elicit some discussion and debate, such as the proposal to replace SDP or to remove the offer/answer state machine logic.
>
> A starting, but likely incomplete list of issues, might have titles like:
>
> - Testing of continued connection liveness
> - Are MediaStreams mutable objects?
> - Provide congestion feedback API for flows
> - Serialization of duplicated tracks
> - Rollback of offers
> - Programmatic description of described streams
> - Learning of network change events
> - Learn what ICE candidates are in use
> - Pausing and muting of streams
> - Description of state/behavior is currently incomplete
> - Priority allocation
> - DTMF onTone event
> - Control connection establishment based on certificate
> - API for discovering capabilities
> - Bandwidth allocation
> - Bandwidth estimation feedback
> - Expose additional ICE state
> - Document how the different state machines interact
> - Interoperability with varying ICE and ICE-like agents
> - H.264 SVC support
> - Set Security Description
> - Remove offer/answer
> - Split SDP between PeerConnection and MediaStream
> - Remove SDP
>
> If it would be helpful, we could produce either a document or a series of emails to the list listing the specific changes proposed for each of these items.
>
> Matthew Kaufman
>
>
>
>
> -----Original Message-----
> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
> Sent: Monday, August 27, 2012 10:11 AM
> To: Adrian Bateman
> Cc: Martin Thomson; <public-webrtc@w3.org>
> Subject: Re: Microsoft API Proposal
>
>
> My apologies Adrian - I had somehow missed your reply.
>
> Thanks for clarifying.
> Cullen
>
> On Aug 27, 2012, at 9:30 AM, Adrian Bateman <adrianba@microsoft.com> wrote:
>
>> On 25 August 2012 09:42, Cullen Jennings (fluffy) wrote:
>>> On Aug 25, 2012, at 9:47 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>> On 25 August 2012 06:42, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>>>>> sorry, I am confused on what an unofficial submission to the w3c
>>>>> is. Is this a submission from the W3C member
>>> (in this case Microsoft) or this a random comment sent to a public
>>> mailing list. I was under the impression you were the Microsoft
>>> representative and emails from you represented the Microsoft position. I'm happy to receive random emails to a public list, but I think you need to be very clear about which this is.
>>>> Consider this input to the working group.  No more, no less.
>>>>
>>>> Not exactly random.  We strive very hard to minimize local entropy.
>>>>
>>> that did not answer my question
>> I answered your question a few weeks ago.
>> http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0071.html
>>
>> It is neither a Member Submission (which is not appropriate since it
>> is in the scope of an existing working group) nor is it random. It is a member contribution under the Process as I indicated previously.
>>
>> Cheers,
>>
>> Adrian.
>>
>>
>>
>
>
>
>

Received on Tuesday, 28 August 2012 07:25:18 UTC