W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 12:04:35 -0700
Message-ID: <CAJrXDUHFwq46NUB5MDhY1d+5PD+GSt9tERHwpV4W4=D+KXV0VA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Adam Roach <adam@nostrum.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jul 19, 2013 at 10:57 AM, Martin Thomson

> On 19 July 2013 10:39, Peter Thatcher <pthatcher@google.com> wrote:
> > So, are you trying to say "Look how hard this is to do with SDP.  We're
> not
> > even done yet.  It will be even harder without SDP"?
> In the Atlanta meeting (Nov 2012) I remember waiting for those damned
> elevators with Justin.  He said something like: "So, if we'd chosen
> comment 22 [CU-RTC-Web] do you think we'd be done by now?"  I was
> quick to answer, "Of course not."  After all, we'd only made that
> proposal 3-4 months earlier.  I know that nothing gets done in less
> than a year, and this is not a small undertaking.
> Since then, I've gained a more nuanced view.  We've set an impossibly
> high bar for this specification, including all sorts of crazy
> features: FEC, simulcast, layered codecs, congestion control,
> undeployed codecs, multiplexing, and not to mention a new data
> channel.
> In reality, SDP never negotiated all that crap before.  Worse, despite
> the existence of RFCs for most of these features, it turns out that
> most implementations were proprietary.  We couldn't even agree on what
> an m-line represents.
> So, if asked the same question today, I'd probably have to say: "We'd
> at least have had basic scenarios shipped.  We might not have sorted
> out the hard cases like layered codecs, but we do have basic
> functionality."
> What we have this the complete antithesis of any project I've been
> involved in over the past 10 years.  It's gold-plating the pink
> squirrel.

> If we want to ship this thing, then we should be managing scope, not
> protecting it.

Slight aside, but is this a correct model of what has happened with regards
to scope?

The W3C is waiting for the IETF RTCWEB WG.  The RTCWEB WG is waiting for
the MMUSIC WG.   The MMUSIC WG has years worth of things that aren't well
defined in SDP that it's now taking the opportunity to define (a sort of
"RAI 2.0").  And everything back to the W3C is blocked by these things that
aren't well defined in SDP, meaning WebRTC isn't done until MMUSIC defines
all these things in SDP that have been piling up for years.

Is that accurate?  If so, I agree that "scope management" would be a good
thing to consider.
Received on Friday, 19 July 2013 19:05:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC