Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened .

Bernard Aboba <> Thu, 20 June 2013 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA6C821F9A52 for <>; Thu, 20 Jun 2013 10:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h-Z9H13Y71vh for <>; Thu, 20 Jun 2013 10:25:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F06921F9A4C for <>; Thu, 20 Jun 2013 10:25:09 -0700 (PDT)
Received: from BLU169-W28 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 10:25:08 -0700
X-TMN: [ExHn75a2trwK5//e9jDePNYm0O6999Ua]
X-Originating-Email: []
Message-ID: <BLU169-W2822F9E6EE5FAE67ABCA55938E0@phx.gbl>
Content-Type: multipart/alternative; boundary="_42c04f4e-1432-4c8e-9a75-0edba2e785f1_"
From: Bernard Aboba <>
To: Roman Shpount <>, "Hutton, Andrew" <>
Date: Thu, 20 Jun 2013 10:25:08 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Jun 2013 17:25:08.0733 (UTC) FILETIME=[1CB6CAD0:01CE6DDB]
Cc: "" <>
Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened .
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: Thu, 20 Jun 2013 17:25:21 -0000

Roman said: 

"My question is, would this WebRTC 1.0 API ever become a standard without SDP portion of it being well defined? Right not this is an opaque blob with little or no definition attached to it. It can be modified and extended in non-compatible way by an implementer with no changes to the actual external API surface."
[BA] I would note that the lack of definition in the SDP blob is not only an issue for the WebRTC 1.0 API, but it will also be an issue for a lower-level API if there is a requirement to demonstrate the ability to develop a shim on top to implement the WebRTC 1.0 API.   If WebRTC 1.0 is underspecified, and in particular if implementations either differ significantly from each other significantly or extend the functionality in undocumented ways, then a backward compatibility requirement on a lower-level API becomes very, very difficult to satisfy.   The practical reality is that a backward compatibility requirement needs to not only demonstrate compatibility with the "WebRTC 1.0 API" specification, but also with deployed implementations. 
Therefore my take is that an underspecified WebRTC 1.0 API effectively poisons the well.