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

Ted Hardie <ted.ietf@gmail.com> Mon, 17 October 2011 17:51 UTC

Return-Path: <ted.ietf@gmail.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 1C7B821F8A7A for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 10:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 AnqNF82sn80D for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 10:51:00 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B521F8663 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 10:50:59 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so1793638ggn.31 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 10:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zfj7dTxlQXQ3QEFnBsdpiBijZK1HaFSZ2oZEwDlksHE=; b=YXn1qbjHTWTCwBTRuxkZ6i3C3BoRsG7GBPVZguMFOEhMztN0T8DsOLt6B1ymS5YkvY x5gupmhgKMsCrIUTbjmbqLewtenbqPLgQNZUQ3bqDpL1Ov+IL1qgDY10CcH06jDK9Zje HdWht1hQcfX9YyPFDVgDO3ZbsHc1aBtUbmaeM=
MIME-Version: 1.0
Received: by 10.236.185.228 with SMTP id u64mr28349130yhm.91.1318873858380; Mon, 17 Oct 2011 10:50:58 -0700 (PDT)
Received: by 10.236.105.169 with HTTP; Mon, 17 Oct 2011 10:50:58 -0700 (PDT)
In-Reply-To: <CALiegfkNapr9rB29xDa2H5Ap0P6PJzQrzpkshBAURg6hwcRRHA@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> <CALiegfkNapr9rB29xDa2H5Ap0P6PJzQrzpkshBAURg6hwcRRHA@mail.gmail.com>
Date: Mon, 17 Oct 2011 10:50:58 -0700
Message-ID: <CA+9kkMCf-F8-t3WoqJkXNMhZirovrctFH9Yw5BzVxFDWW0a=RQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=20cf303f6bcad513ac04af823f4a
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: Mon, 17 Oct 2011 17:51:04 -0000

On Sat, Oct 15, 2011 at 1:43 AM, Iñaki Baz Castillo <ibc@aliax.net>; wrote:

>
> > Do you think you could support SIP identity with a javascript client?
>
>
> Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to
> have a list of CA's and verify the retrieved certificate by itself. A
> JavaScript client receiving an incoming INVITE with Identity and
> Identity-Info header could make a webservice call (i.e. using AJAX)
> and ask its web server to retrieve it and verify it in behalf of the
> client. And still that is SIP.
>
> So yes, I could support SIP Indentity with a JavaScript client.
>
>
I would say you did not do it within the JavaScript client, but built a
JavaScript client that simply trusted the results of the webserver.  This is
significantly worse than even the SSH-style limited identity we've discussed
before, because the Javascript client doesn't even check whether the
identity matches previous uses of that identity.  You also don't describe
how you go about assuring the path over which the media flows, which is a
part of sip identity.



>
> >
> > Well, given that you don't believe in the need for a protocol here at
> all,
>
> A protocol is needed, of course. But not a *specific* protocol.
>
>
> > but only an incredibly flexible API, it seems a bit unclear why you're
> not
> > making these points on the W3C public mailing list for this activity.
>
>
By "a protocol here", I meant "standardized in the IETF" sorry that was not
clear.


> I expect such work must come once the requirements for such API are
> done in this WG.
>
>
The work is ongoing now in both groups and the two are meant to coordinate.
Presuming that all the work will go on there to provide a model-agnostic API
is not effective coordination, at least in my view.


>
> > 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'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.
>
> There have been lot of arguments contrary to defining a "default
> signaling protocol". I don't want to repeat them again, but neither
> answer as if they don't exist.
>
>
There have been a lot of arguments, but speaking personally, they seem to
boil down to a preference for inferring a model (offer/answer) along with a
slow realization that much of the negotiation here (e.g. codec parameters)
cannot really be punted.  As I said before, if you go down the route of
creating a common model for negotiation and a common set of structured data
for the negotiation and security assurances, you have done the semantic work
of creating a protocol.  Failing to choose a common in syntax in that
situation is, in my experience, both odd and likely to decrease the amount
of deployment and increase the failure rate.

My personal opinion,

Ted Hardie