RE: Discussing new API proposals

I am not happy with the idea of having the correct API be deferred to 2.0, but requiring browsers to also support the currently proposed 1.0 abomination. Not only will that undoubtedly constrain the 2.0 design (so that both the 1.0 and 2.0 API can be used to manipulate the same things), but browsers will be forced to support both for the foreseeable future, which doesn't solve any of the under-specification or implementability issues with "1.0".

Matthew Kaufman
________________________________________
From: Stefan Håkansson LK [stefan.lk.hakansson@ericsson.com]
Sent: Wednesday, July 17, 2013 11:30 PM
To: Matthew Kaufman (SKYPE)
Cc: public-webrtc@w3.org
Subject: 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 14:52:52 UTC