Re: [rtcweb] New Draft - WebRTC JS Object API Model

Ted Hardie <ted.ietf@gmail.com> Mon, 01 July 2013 20:11 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 2586711E822D for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 13:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 NIsFVYg5kvDR for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 13:11:26 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70D11E8229 for <rtcweb@ietf.org>; Mon, 1 Jul 2013 13:11:25 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z11so4105680wgg.10 for <rtcweb@ietf.org>; Mon, 01 Jul 2013 13:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Ea9pQKW3SRMyITj+0hPh/g3nsiMcOr1r7oIsLgIWuI=; b=u+d6dzlUMOLqMDNL0WxXlvXrX4Gw3HUMVfC8pWp0f5q8yuOIzc08bm6mbVHDRC8fSZ G/CgJOtQbc4835sYiIugIiqBdW40VAZvKbxXDlo1d7hAr9aOXa3HRljBHwELau3CBmMm oahUWuMwt+ddJi03Yq/ywptMds9bW+rHoBULVNuuk+6naU4gPB2fGRhUKmJYjmRmhSGX CFD8Vv9yfraZCb50OAxZJMUvGiJQMShzKtPCTw+Iru4Njov4Bj7wlL2Q+ro4bQH078zA 0f0oJs5EjSVpnXffHsLxVhHDsC6lAGTDa1p7H58wL6DH3k+5/WBS4REJSxNj5kNtEAj9 ecSw==
MIME-Version: 1.0
X-Received: by 10.194.172.228 with SMTP id bf4mr20771098wjc.36.1372709483929; Mon, 01 Jul 2013 13:11:23 -0700 (PDT)
Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 13:11:23 -0700 (PDT)
In-Reply-To: <D0EB1EC9-F80F-467F-801D-AED39272F291@matthew.at>
References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <CALiegfmsahUM6w00thQSCu3CpKse2C3LKSb1LzkwodNgKTOK0g@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <CALiegfnAN9SJx0nLyegFJoQscG-18Gs4umd-pe7S3y6xREpByQ@mail.gmail.com> <CA+9kkMC5FoxKSz7DuHxN8cEO=0PDpoAGrLshpFmnDe3gco06cw@mail.gmail.com> <CALiegfnpj+nBdhn0g8A7iTdXKZdqvwyffjdLAOuM_qQkhTuKew@mail.gmail.com> <CA+9kkMA1PhoJB9qGUnXDUHRJNac5OszM4o5O7-6aCU-ahszMNw@mail.gmail.com> <CALiegfkei-dS-EHt2vqofft_uhKNz+UuK7R5LX3bgDkh=0ZwqQ@mail.gmail.com> <CA+9kkMCDXpZ99Gu85eRcyCbwW1M-4uacKPvU8R1zFbKiCfde2g@mail.gmail.com> <D0EB1EC9-F80F-467F-801D-AED39272F291@matthew.at>
Date: Mon, 01 Jul 2013 13:11:23 -0700
Message-ID: <CA+9kkMDR6n5UvcDEwUb_FC9AA5jwuKDCPxfv7hSiufEDZPQYvg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Matthew Kaufman <matthew@matthew.at>
Content-Type: multipart/alternative; boundary="089e013c6c122b6d7f04e078d5e4"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model
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, 01 Jul 2013 20:11:27 -0000

On Mon, Jul 1, 2013 at 12:22 PM, Matthew Kaufman <matthew@matthew.at> wrote:

>
> > Honestly, I have read it and I don't see how you avoid mandating some
> standard
> > interface between the JS and browser.  That needn't be SDP, but if it is
> causing the
> > two sides to negotiate candidate transports and emit RTP, it's going to
> be hard going
> > to avoid it being SDPNG.
>
> This lack of imagination among people designing the APIs we are supposed
> to use is disturbing.
>
> Have you read, just as an example, the CU-RTCWEB API? It achieves a
> browser API without resorting to SDP or anything like it.
>
>
I have read it, though I see from the date on it that it has been updated
since the last time I did so.  You are right that this does not look
anything like SDP, and it is therefore not clear to apply the moniker SDPNG
to it.  But CU-RTCWEB also contains elements that are standardized to meet
similar requirements, which I believe Iñaki is arguing is not needed.  To
put it in CU-RTCWEB terms, I don't see how not having a standardized
version of something like RtpStreamDescription,  RtpExtension, or
CodecDescription scales, since the result is that browser must understand
whatever approach the JS application chooses to use for those.

To restate this:  having the JS application to JS application API surface
not be standardized works because the private agreements can be expressed
in the application; having the JS application to browser interface be not
be standardized doesn't seem to me to work at scale. It could be done by
having an independent browser extension for every site that wants to use a
specialized API, but that hardly seems to meet the goals of the group.

Once again, no hats or company swag on,

Ted


If you insist on Offer/Answer *and* "opaque" blobs (that we all know people
> will modify anyway), then sure, SDP looks attractive... But that's just a
> failure to imagine a world where VoIP isn't based on SIP and SDP O/A.
>
> Matthew Kaufman
>
> (Sent from my iPhone)