- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 19 Jul 2013 10:57:54 -0700
- To: Peter Thatcher <pthatcher@google.com>
- Cc: Adam Roach <adam@nostrum.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.
Received on Friday, 19 July 2013 17:58:22 UTC