Re: Discussing new API proposals

On 7/17/13 10:17 PM, Matthew Kaufman (SKYPE) wrote:
> Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>>
>> We welcome new proposals and ideas to be made and discussed, and
>> think this WG is the right place to do so.
>
> That was made clear in the message about which list to discuss things
> on and the proper venue for discussion.
>
>> However, as outlined already last year, we think the WG should
>> focus on finalizing the current API draft (to a LC status) before
>> starting a new public/official document describing a new API.
>
> How is this even possible at this point? The "W3C API" simply punts
> the whole actual "API" to the IETF for standardization.
>
> Text like this in the spec: "The createOffer method generates a blob
> of SDP that contains a RFC 3264 offer with the supported
> configurations for the session, including descriptions of the local
> MediaStreams attached to this RTCPeerConnection, the codec/RTP/RTCP
> options supported by this implementation, and any candidates that
> have been gathered by the ICE Agent" are ridiculously underspecified,
> given that "a RTC3264 offer" can be almost anything that meets its
> syntax requirements, and yet the space of valid offers is clearly
> much smaller than this.
>
> So either 1) "this WG is the right place" to specify the entire API,
> in which case we really should get on that or 2) "the IETF WG is the
> right place" to specify pretty much all that matters, in which case
> the W3C WG is pretty much held hostage to a process that doesn't
> appear to be converging, especially now that people have realized
> that any time you want to extend SDP you need to A) go see the MMUSIC
> WG and B) make sure it won't break any of the SIP applications that
> use SDP.

The outset from the start was that this is a joint effort between IETF 
and W3C (and that is said in both charters). This leads to some 
consequences regarding split of work and coordination. I guess that is 
something we have to live with and handle in the best way we can.

>
>> We think it has advanced far already, there are working
>> implementations and it is used by application developers.
>> Abandoning it, or slowing it down, now would be a bad idea.
>
> Who is "we" in this case? Clearly not the application developers who
> have spoken up recently. Nor at least one of the major browser
> vendors.
>
>> Discussing different use cases that are hard to do with the present
>> API, and discussing approaches and ideas that would make those use
>> cases easier to achieve, would probably be an excellent exercise in
>> distilling out the main approach for a new API (or future API
>> extensions). We welcome such discussions.
>
> That sounds like a fun exercise. I don't see how it advances the goal
> of getting a W3C specification that others can implement in an
> interoperable way.

My mail was intended to invite to input on use-cases not well supported 
by the current API, and how we could make support those use-cases in a 
v2.0. I would prefer to discuss how to finalize the current API in a 
separate thread (but I do share your concern regarding documenting all 
the bits and pieces to allow for interoperable implementations).

>
> Matthew Kaufman
>
>
>

Received on Thursday, 18 July 2013 06:31:19 UTC