Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Martin Thomson <martin.thomson@gmail.com> Wed, 19 June 2013 17:46 UTC

Return-Path: <martin.thomson@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 B95EA21F9A97 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 10:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqmXyMHX4atY for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 10:46:59 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D629B21F9B3E for <rtcweb@ietf.org>; Wed, 19 Jun 2013 10:46:56 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id q58so4690295wes.19 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 10:46:56 -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=ujNzrIHd/ZfLR1BbA0pjFg0a4vyTuZNECzeWZXSPcd8=; b=EBZDXYSmEm+dylCbPx6zHX8XI00OCoF5CZrjaB054xHu9EVzf+qomGFCqVQE/JQuZg FLJJB5PFG2A+4sVywFBtZijvwpG28btXbHsgKJzv+DdHrztjqkpsHNvzqazmG3N+YgGW YRUnjrAEWsD1xwDpia4004S6wGX+Bxaur5V0IYWYxYlnaVij0DoRkwMN3N4B8vI9FxVW bK9Wji+T5C/F2r07c6A2WFrWGoDsN+pOpw7ks8IUQ5m0cQyS3yE+CH3Ext5P8XNXf20T 67CwhNIARsaJw/1ywmN0L7rm39IIr3iHWzN9XLUPnqZJ7pRn1UkN609vsUBSb3iJMQon bWwQ==
MIME-Version: 1.0
X-Received: by 10.180.20.46 with SMTP id k14mr2930378wie.14.1371664016023; Wed, 19 Jun 2013 10:46:56 -0700 (PDT)
Received: by 10.194.60.46 with HTTP; Wed, 19 Jun 2013 10:46:55 -0700 (PDT)
In-Reply-To: <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com>
Date: Wed, 19 Jun 2013 10:46:55 -0700
Message-ID: <CABkgnnXjnN4WZA4QB-N3-u_Or5tTt=gjFYbvZj9mWQcdZPA98g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: text/plain; charset=UTF-8
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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: Wed, 19 Jun 2013 17:46:59 -0000

On 19 June 2013 08:15, Peter Thatcher <pthatcher@google.com>; wrote:
> Unfortunately, Microsoft's input seems to be "our way or the highway"

The good thing about this forum is that correcting gross
misrepresentation is as easy as it is to propagate it.

Microsoft's input is that Offer/Answer is difficult to remove without
also removing a reliance on SDP at the same time.  CU-RTC-Web is a
demonstration of one solution to that problem that we believe is
workable.  That proposal was input, not ultimatum.  We'd be happy to
consider other alternatives, but we don't believe that any attempt
that retains both O/A and SDP to be a worthwhile step.

The proposals I've seen for incremental refinement don't successfully
avoid the SDPNG trap.  Most increase the API surface area, often
dramatically, which burdens both browser implementations and API
users.  I personally don't believe it to be possible to avoid this
problem without tackling the core problem, which unfortunately
requires a little bit of courage.