Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

Peter Thatcher <pthatcher@google.com> Thu, 07 March 2013 20:56 UTC

Return-Path: <pthatcher@google.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 6479C21F8AA1 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 12:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 jCOLWNZcJXKY for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 12:56:46 -0800 (PST)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9504421F8581 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 12:56:46 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id fy7so523881vcb.2 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 12:56:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IWkTY9P8fifcZhH/yIvw7sSIadDSjoCTx+2Rlqia6q8=; b=Kh7nP+o8Sr5WC2B9I4IOFZ+bp0vI2z4PjWVSjxTwDdhewYxAp+IeXxRCNhLRxed4SG nvG2Qdcr6XCVRKupRi2/fggPC5hh/77xxASKsN+IU57947EvJvo7NhPVgjEfyuYJBznX WAk9BwMdzLZo7Fwa7m/iBgOdvZj7ejlxYswU4heAqE9YivpYH7CRcPH6fHApewjC4SFS nRRlaQVWtqKUo/nRIJO7klZYtZ6vX5i5Vlbkzr3lM1H8rACyk+uOm96KSlrQVLXgWSf7 ONveJlQ3BTO/vubTxh4StgAColkbmgbDrkJVuBBGVXf98Ckf6ax+uk3ZQSNjvpT45TZU nedQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=IWkTY9P8fifcZhH/yIvw7sSIadDSjoCTx+2Rlqia6q8=; b=pCmNU/Czob/P3zCsjOXoga/DCKtQFuKyTEOHX8xlFIKDFQnFDa0KU0sd1IA17HdVOQ hOFUdsMk8NrICqy3C7MuSqJQcQ8m8UVYD5gidOtiLSF1OqyUjU0nsAuZsfrzwsCW6lI5 bZ6/Dmenx4GjZcNvvBiUzxey9P4kDlzsfj6ZSq8QeF7sKRQDwZ85esv9p6AwEdEBlo6o PRrMcGUurWZCqmuL4vB64utLwD75cMvb60IdWle1c703EKRCozlMWQe/QHsh8qjQrCxi QWHn5vOdW+NrXAzofonevTWZ6zzR06jJV04S+sEBg9j0OmNG6sFzsHWaBbmvP0q65mRr TmNg==
X-Received: by 10.52.70.228 with SMTP id p4mr11493089vdu.89.1362689805998; Thu, 07 Mar 2013 12:56:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 12:56:05 -0800 (PST)
In-Reply-To: <CABcZeBMt7vaMnhcDD0-U7n6Hn-T=sHcGUGEV4=vAs8DVcoi-CQ@mail.gmail.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CAJrXDUGSMfQ=SNrSxKVvay=4JUXHULy0cO2pRN9+iFJ23doWZQ@mail.gmail.com> <CAJrXDUHvcsuN6vXs8wku_aUrs-siHdn2wBDOJBgpgDPJySgdSg@mail.gmail.com> <CABcZeBMt7vaMnhcDD0-U7n6Hn-T=sHcGUGEV4=vAs8DVcoi-CQ@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 7 Mar 2013 12:56:05 -0800
Message-ID: <CAJrXDUGqxDxS5=_YnLOWVT6xOgXYuspGS5U2gXevc+PP2vLdHw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQkVoDu234bzMZI+IIf/3qbeOT5Y++5VkIYTbtpuVJi8c9k4Vgs63R40iQNi8SSknDNK+fsSvSCUo9xbPKSBiq66qoG60N1WS93J41dCpnFIj7Pb4dd42frHHedfBC+awaynmryuVkDwYI2eJYoQzvJAOiD/HNpWeEtBEFKctRjXvp9Fw9AN2cGi6CG5DRlkfEqgZl4X
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 20:56:47 -0000

Having a JSON-based SessionDescription that's a 1:1 mapping to SDP
semantically seems like a bad idea to me.  We want something better
than SDP, not just a different syntax for SDP.  Trying to map all of
SDP would be a near-impossible task anyway.


I think you're combining two separate questions:
a.  Should the Browser<->JS API have SessionDescriptions at all, or
should it have just low-level methods?
b.  Should the SessionDescription be representable as SDP or as
something else or both?

So far, we have two camps that combine the two questions:
Pro-SDP camp: methods=createOffer/setLocal/setRemote   and  format=SDP
Anti-SDP camp: methods=low-level methods   and   format=none

I'm suggesting that there might value in a third possibility:
Compromise: methods=createOffer/setLocal/setRemote  and  format=JSON


The Pro-SDP camp will tell the Anti-SDP camp, "don't blow up the
world".  The Anti-SDP camp will tell the Pro-SDP camp, "SDP is a
horrible API surface".  I think they are both right.   And I hope that
an alternative format for a SessionDescription would be a sufficiently
good compromise.


I don't think of it as a fork of SDP, but rather as a much better way
to describe sessions than SDP.  I've personally worked with 6
different kinds of session descriptions (SDP, Jingle, libjingle
internals, and a few different Google internal representations), and
SDP is by far the worst, not just in syntax but in semantics also.  I
think a JSON one could be much better syntax and semantics, without
quite "blowing up the world".

At least, that's my hope.













On Thu, Mar 7, 2013 at 10:45 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Thu, Mar 7, 2013 at 10:33 AM, Peter Thatcher <pthatcher@google.com>
> wrote:
>>
>> A question for all of you in the "please don't make us use SDP as an
>> API forever" crowd (and I include myself): Would it be acceptable to
>> you to have an intermediate step where we keep createOffeer,
>> setRemoteDescription and setLocalDescription as-is, but allow a JSON
>> argument?  It seems to be that such a thing could provide all the same
>> low-level of control as any other setup of methods, but may be much
>> more likely to be accepted by the group as a whole.  And, it would
>> still be a lot more pleasant for application developers, and leave
>> more flexibility for a future where low-level methods might be added.
>>
>> As both an application developer and a browser implementor, I think a
>> good SessionDescription JSON format would be easy to implement,
>> pleasant to use, a small incremental step from what we currently have,
>> and would relieve the standards body of so much fighting over what the
>> SDP should look like.
>>
>> I know it wouldn't be exactly what you're looking for, but I think it
>> would be achievable and much better than what we have.
>
>
> II don't understand how this changes anything meaningful. The point
> of using SDP isn't the crufty line-based encoding, it's being committed
> to the SDP offer/answer semantics. So, when you talk about having
> JSON, you're talking about one of two things:
>
> 1. Having a format which is semantically equivalent to SDP.
> 2. Having a format which is semantically distinct (or perhaps a superset)
> of SDP.
>
> In case 1, I don't see what this bought you, other than programming
> convenience. It's not like it would be difficult to build code to
> mechanically
> dissect the SDP encoding.
>
> In case 2, you have forked SDP, and largely obviated the point of
> using SDP in the first place.
>
> -Ekr
>
>