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

Adam Roach <adam@nostrum.com> Fri, 19 July 2013 17:50 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5239821E80D3 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3GbjAmrWT-j for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:50:14 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A81821E80B6 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:50:08 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHnweR077272 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:49:59 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51E97C41.5050208@nostrum.com>
Date: Fri, 19 Jul 2013 12:49:53 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Peter Thatcher <pthatcher@google.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com> <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <CAD5OKxtKLMf_d=8GSMrqfNhDHPe9MFP2ZTKzZHFn9CyMr-gSVQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <CAD5OKxvGfkgRp6tXwbOu_kVteHiBBqsyR5ixH18FMKjCNGO8VQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com> <C50FDAD5-492C-4A83-AD6D-464242FB4A05@iii.ca> <CALiegfneUj=kzDjR_E1=S-bqAajaPUE3f_A2g8oGriFyPhamPA@mail.gmail.com> <51E96B5B.2050302@nostrum.com> <CAJrXDUFtPwHNznRHYgMpSr8U04Y+toDHubJ5fK-2qtnsURtL7g@mail.gmail.com>
In-Reply-To: <CAJrXDUFtPwHNznRHYgMpSr8U04Y+toDHubJ5fK-2qtnsURtL7g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 17:50:16 -0000

On 7/19/13 12:18, Peter Thatcher wrote:
> Please try to consider what you sound like to a web developer who is 
> trying to use WebRTC and finding SDP to be difficult API surface.

I think any time someone says they've used the SDP directly as a control 
surface in a JavaScript application, it indicates a hole in the current 
WebRTC specification that we need to fix.

SDP is not supposed to be the WebRTC API surface.

I think we all pretty much agree that SDP is not supposed to be the 
WebRTC API surface.

I think we're pretty much all on the same page that we need to add stuff 
to the current API to handle these use cases.



> Maybe I'm wrong, but I'm guessing what you're saying will sound like. 
>  "my use case (legacy interop) is the most important and my solution 
> (SDP) is the best solution for everyone and I know better because I've 
> been working on it for longer".  Hubris?

No, you've misunderstood pretty much everything I said. I'll summarize 
in fewer words.

My point is that we need to solve these problems one way or another, and 
SDP isn't really the reason it's difficult.

But by incorrectly deciding that SDP (or offer/answer, depending on who 
you listen to) is the reason it's hard, we're trying to throw legacy 
interop out the window for very little gain. And, while not the only (or 
even main) consideration, legacy interop has significant value. It would 
be a shame to destroy that value based on a misconception.

These issues aren't hard because of SDP. These issues are hard because 
they're hard.

/a