Re: Discussing new API proposals

On Thu, Jul 18, 2013 at 7:52 AM, Matthew Kaufman (SKYPE) <
matthew.kaufman@skype.net> wrote:

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


I think I know what you're trying to say here, but this doesn't appear to
be a complete sentence.  Perhaps it was longer and you deleted something
while editing?


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