[rtcweb] New language (was: ... WebRTC JS Object API Model)

Martin Thomson <martin.thomson@gmail.com> Mon, 01 July 2013 18:57 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1928F11E8228 for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 11:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CWpge00ZTOwb for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 11:57:53 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1811E8234 for <rtcweb@ietf.org>; Mon, 1 Jul 2013 11:57:53 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f11so4044377wgh.27 for <rtcweb@ietf.org>; Mon, 01 Jul 2013 11:57:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=IJ5yFBuoG1pOtCR/FO3IjexT6f5gDw+clU76bHmbVKI=; b=vEM9I5z+TY2WT5LWFTc4JxoL3SF1gNSDdPLaKi/95lu0LXkGwbzrUneq7ghF58ylCp sQuFF16Rlqcx+9frc0b7VpWBWJTf55DJpL/DvvY2MG1uSWjvoTAS8HTB2A7BNvw+M95F cFGdjhPfY1DFPXLq0N61BGOdN/QoD/VYPBE0bkPhdXqEPBmsTMyjtoVmHWfkLKCFKJKn JOp1TNNM6mRQBS/TfFrYQaIC1nwnsBdZ2mJpd9ZIGYhdJlv4LEr/yiIrCT48WtHRc5sT cIddzZBm0Rhrns7Ojia8wrZj284XrBwD93Aiu7oGkrr/UdXJtned4A0O3tA8QE2kCin6 qY/Q==
MIME-Version: 1.0
X-Received: by with SMTP id fv11mr12923764wic.65.1372705072371; Mon, 01 Jul 2013 11:57:52 -0700 (PDT)
Received: by with HTTP; Mon, 1 Jul 2013 11:57:52 -0700 (PDT)
Date: Mon, 01 Jul 2013 11:57:52 -0700
Message-ID: <CABkgnnV6ss8cs0GRjkKZ1rDG76F6ZBRoPpm7Td7gUGoZnMzkvA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [rtcweb] New language (was: ... 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 18:57:54 -0000

On 1 July 2013 11:17, Ted Hardie <ted.ietf@gmail.com> 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 is an important argument, but it's only correct up to a point.
And that is misleading.

SDP does a lot of things that an API can do in far simpler ways.  Take
BUNDLE, or the plan A/B/No question.  We all know what these need to
do, but we are encumbered by existing SDP - which is no single thing -
in trying to reach a conclusion.

Interconnectedness makes SDP hard.  Harder than it needs to be.  The
main advantages of a new form of expression come from its ability to
isolate problems. For instance, separating transport establishment was
clearly a big win for Jingle in terms of flexibility, simplicity,

But those examples speak directly to your point.  A new "language"
might be unencumbered in a way that might make addressing these
problems easier, it might even be more capable, but it is still just a
new way of saying the same old thing.

Offer/answer is the problem.  It's a contrivance that can be chosen or
rejected depending on how you plan to interact with the API.  That
embeds a negotiation engine into the browser, along with all the
machinery for how to negotiate everything that SDP expresses.

Negotiation is an extra, a feature that the IETF decided to add to the
API to make it "easier to use".  That wouldn't be a problem if it
weren't mandatory, but it's the only way to do anything.  (In
contrast, CU-RTC-Web provides a negotiation feature, but it's an
optional extra.)

So SDP truly becomes a problem when coupled to offer/answer.  The way
that features interact become a problem for standardization, not
because they interact with each other - interaction problems are what
engineers are for - but because they are negotiated.

And it's not the SDP negotiation that is the worst: it's the
negotiation of what it means.  We all know what it means, but I'm
certain no two people "know" SDP the same way.  That means another
sort of negotiation.  And those negotiations require that those
engineers be sent to places like the IETF to argue endlessly, or play
at politics.