Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Neil Stratford <neils@belltower.co.uk> Sat, 15 October 2011 09:12 UTC

Return-Path: <neils@vipadia.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 3C74B21F8B4C for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 02:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.939
X-Spam-Level:
X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 qUOXUZWI1Jcv for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 02:12:34 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 910E821F8B18 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 02:12:34 -0700 (PDT)
Received: by iabn5 with SMTP id n5so3792703iab.31 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 02:12:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.3.225 with SMTP id 33mr5006443ibo.87.1318669954074; Sat, 15 Oct 2011 02:12:34 -0700 (PDT)
Sender: neils@vipadia.com
Received: by 10.231.200.146 with HTTP; Sat, 15 Oct 2011 02:12:34 -0700 (PDT)
In-Reply-To: <CA+9kkMDsWyKdvXSRMV0OGEeEYbSENFHSOovNJDUGK30N_pGrnQ@mail.gmail.com>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com> <ABB0E87F-DEEF-4386-A718-D48E00F5961A@acmepacket.com> <CALiegfnHuYJnX3rnuDGbZPB4NvK=dCTJ=iLcu+zguP5wo_uPqQ@mail.gmail.com> <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <CALiegfn6nv1D2HjeMo-jPDh9Acph7JdH1DT1xZXUtHqzqxya3Q@mail.gmail.com> <CA+9kkMB3p1u7hRX_vO1bQbQ2z-V+0rLiJmi+ZqkEA0mqc66keQ@mail.gmail.com> <CALiegf=26_6r_YjBCmO+6_GnrAzi=KcLoPFqUi-y1E8m_gWreQ@mail.gmail.com> <CA+9kkMDsWyKdvXSRMV0OGEeEYbSENFHSOovNJDUGK30N_pGrnQ@mail.gmail.com>
Date: Sat, 15 Oct 2011 10:12:34 +0100
X-Google-Sender-Auth: 2qEcdlVXMniOtkIQYGzbDC3cQ1o
Message-ID: <CABRok6nsVH5tYfwFqQpmjF=Kj-wZQDB9XUX8oOee8r3wr51fKA@mail.gmail.com>
From: Neil Stratford <neils@belltower.co.uk>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=00151773de8e304a6004af52c6eb
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Sat, 15 Oct 2011 09:12:35 -0000

On Fri, Oct 14, 2011 at 11:41 PM, Ted Hardie <ted.ietf@gmail.com>; wrote:

>
> A truly well structured API here will imply, at least in my view, at least
> a common model for negotiation and a common set of structured data to be
> passed via this javascript-implemented protocol.  Doing that without
> defining a standard protocol is actually harder than doing it while defining
> a protocol.
>

I disagree that there is any requirement for a common model for negotiation.
By all means ensure that the API enables the implementation of SIP and
XMPP/Jingle, but to start with a single protocol and use that to define the
API will undoubtedly lead to unnecessary limitations in the API.


> I've heard the various arguments against defining one, but none of them
> seems to stand up against the base fact that you can have a standard
> protocol--known to be available--without restricting the ability to create
> proprietary protocols using the same API.
>

Which is true, so long as you don't let your protocol choices leak into the
API definition, which is unfortunately already the case with SDP.

Neil