Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

Tim Panton <> Wed, 12 October 2011 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C43BB21F8C04 for <>; Wed, 12 Oct 2011 03:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q+tfnhUFF3OX for <>; Wed, 12 Oct 2011 03:31:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F28B621F8BDE for <>; Wed, 12 Oct 2011 03:31:25 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id 22AA137A902; Wed, 12 Oct 2011 11:44:07 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-26-805858366
From: Tim Panton <>
In-Reply-To: <>
Date: Wed, 12 Oct 2011 11:31:14 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
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: Wed, 12 Oct 2011 10:31:26 -0000

On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:

> On 10/12/11 11:46, Neil Stratford wrote:
>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <> wrote
>> One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.
>> I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.
>> As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.
>> Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
> Yup. And I suspect they're all subtly different.

You could look at that in a positive light - 
as evidence that there are multiple ways to solve this problem and deduce:
	a) it isn't impossibly hard
	b) there isn't one 'correct' way of doing it.

Which would lead me back to specifying as _little_ as possible and letting innovation take place.