RE: Discussing new API proposals

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.

> 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.

Matthew Kaufman

Received on Wednesday, 17 July 2013 20:17:31 UTC