Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)

Peter Thatcher <> Fri, 12 July 2013 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91A0521E80A9 for <>; Fri, 12 Jul 2013 11:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4wNjLAr+ICjw for <>; Fri, 12 Jul 2013 11:22:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22c]) by (Postfix) with ESMTP id 9D95221E80A5 for <>; Fri, 12 Jul 2013 11:22:02 -0700 (PDT)
Received: by with SMTP id uo1so9262820pbc.3 for <>; Fri, 12 Jul 2013 11:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FvsIv7D5axYJSWQ5uD9AR/jNrfZPbLet7tPmseqo+p0=; b=XsKnEPMzKJeI5L90qNdn2QfdzwljCbuk7v7K+HEfapzBnZUZJh6ch6KVvfSP8pc+vM k93WGF1WRrJMDB3riV2qZXgir0GVoCT1L7xRQ7QBbW/teC77fhAevANixuF4xdJvAMaG NVeYtPSYQH4LFpX5I7fn5Aw5sQZNjidtpMjSIX2ca7UH/WXgnnxjoa4gL0ixGBPpMPTK HM8YfVG6QO1XjPbM44bjuShgzSC30ZJPwr6y5iAXZJqIUVJX0zYwnR8Ito3wTwyx5xtI mqUZTYnzr49Ar7Q3/kUNs6xYZP7hUmBGK2cMv/DPCXCqW2mUrOZmUNc39f6VP4C3Y/+0 Ip8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=FvsIv7D5axYJSWQ5uD9AR/jNrfZPbLet7tPmseqo+p0=; b=EfVFbIDYrNCp1zMgZxpi6DPV6EQTR3HJWXeWRebgK5xTjDefDJqGgDnvGDEBnRfITG o+Yr21I2OZqP8R7mMGK1nqvAJxBHvr5j0LYR1ZvVjAdMKH5v6AIgNTnIl6a0zVZ3ABME xNL9pcYEexQvcpHyXAlTAj+n173y27uqkNtnaBiJIPbSIJ/BdmL4WFKRyKqJCOvtjMCG fooWLM93oMKWIiQHXR+EzhFjr6KDfL+bxgGfPWqa0wiuM264YmC3Rl2lnQ8yY73bnJpW tE0+I7HSMF5mpYolX9zxJjWI4BQmbnoQUIlm6HtUHGUWb6VlMTUnQ8CqNcIFEHkvx8LW MRqg==
X-Received: by with SMTP id r4mr45103234pac.57.1373653322110; Fri, 12 Jul 2013 11:22:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 Jul 2013 11:21:21 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Peter Thatcher <>
Date: Fri, 12 Jul 2013 11:21:21 -0700
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="bcaec51f99e54f49c504e15496f0"
X-Gm-Message-State: ALoCoQl/oNYoGOwuFjfizsAxF3IinVdbVmu+WA5VNjrIPokw+BpoVVFaBAB8N166/Zs9o7I2or7Cikj3OGxbXqH+FYLAbq6CyxcV4vAVUJTLqgkPtnsX5AZfob3gSJyKWPK41OIPPZtU37dil0KNy6NMDOQTGxy5j0TfSeaUjEqHGbPVjekNdL1GL7nZNGdaaDjuf43j/8gC
Cc: "Cullen Jennings (fluffy)" <>, "<>" <>
Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2013 18:22:05 -0000

On Fri, Jul 12, 2013 at 10:41 AM, Martin Thomson

> On 12 July 2013 10:19, Peter Thatcher <> wrote:
> > I think advanced JS apps are going to use every control knob they can get
> > to, whether it's anticipated and well-supported or not.    I think
> there's a
> > good chance that a a popular WebRTC web app will use some SDP mangling
> that
> > wasn't anticipated, but happened to work, but then the browser can't
> remove
> > it because it will break certain websites.  It could get even worse if
> > someone writes a popular WebRTC wrapper library that uses tricky SDP
> > mangling that is then used by lots of websites.  Certain SDP mangling
> > techniques might end up becoming a defacto standard API that can't be
> > removed, even if it was originally a bug.  Or worse, one browser will
> have
> > to implement the SDP mangling or even the bugs of another, because WebRTC
> > apps have come to rely on them.
> >
> > In fact, it's already the case that Chrome and Firefox support far
> different
> > SDP manglings.  I don't think any web apps rely on that yet, but it's
> only a
> > matter of time before someone figures out "hey, if I mangle the SDP on
> this
> > browser this way and on that browser that way, I can do things I
> couldn't do
> > otherwise".  Or worse, an advanced web app developer says "hey, I can
> make
> > this work well on browser X via SDP mangling, but not on browser Y, so
> I'll
> > put a 'best used with Browser X' icon on my website". Then that someone
> > writes an abstraction on top of that, and then maybe shares that with
> > others, and it goes from there.
> >
> > I think we're in a race with web developers to see if they'll figure out
> > mangling before we provide a way to avoid SDP mangling.   Who do you
> think
> > moves faster?
> This is one of the arguments we've made against the use of SDP.  There
> is a remedy for this (aside from comment 22 ;), but it's a fair amount
> of work:
>  - provide very explicit and detailed instructions on what SDP to
> produce under all starting conditions, and
>  - provide very explicit and detailed instructions on what to do with
> every single bit of SDP that is provided.

If we write it down with such detailed instructions, is a browser banned
from accepting more than the explicitly allowed SDP in calls to
setLocalDescription and setRemoteDescription?  For example, what if lots of
web apps get SDP from a particularly popular gateway device that adds a
particular SDP attribute, and if the browser "listens" to that SDP
attribute, things work better (for example, it might be a bandwidth-related
attribute).  Can the browser "listen" to that SDP attribute even though it
isn't explicitly supported by the WG?  Or does it have to wait for it to be
added to the explicit instructions?

> That is what I believe to be necessary if this API is to have any hope
> of real success.
It depends on how you define "real success".   I think the API has already
had success for simple use cases, seeing as two browsers have working,
interoperable implementations for the simple use cases.  It's the advanced
ones I see being problematic.

> Unfortunately, when I sat down to do this, I barely made it to t=
> sections.  I simply cannot justify spending the time required for that
> sort of chore.

Well, then you're almost finished.  All you really have left are the m=
sections :).