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

Eric Rescorla <ekr@rtfm.com> Thu, 07 March 2013 18:46 UTC

Return-Path: <ekr@rtfm.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 75C4321F8B1A for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.91
X-Spam-Level:
X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131, 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 VPOtOKBGBVAv for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:46:38 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 960E321F8B18 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 10:46:38 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id 9so482926qea.7 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 10:46:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=bdGgVnnkZpUNxlUHLPNAFIoJJUkAD2867bbEWmWZCuk=; b=A7ZDGlB0BnuKiaKjh1lVb08arImn4y+8wV5Npc9omJeM6ij8cxgqfhPrgy2bbT47cR 11Imgs/WAaRUf/NHp0y2BEp8CfkA9yYuLOoSaQGBAYNPDHGtuXGSfeFsEimBhhoAB4ZT 7gIFtS1iC8xOxwE3Tyz+d2Y9nrlRlvpAUqCx/+zXShxo6P+OM72OIWpd1lHjqDEvzq2G Z0GlGGjaWgG4hyj2JkPtZff1F49YhGUfbezYffotH0q/k9PJSntckku4/e9LpU6K7Q4B uUSM8qnsaCYOQ9kv0V4AxCUsYoz4/pVpFrvLeHRZRmUSoPyHYO9Lw/snW0dA+K2V3CTc 7u+A==
X-Received: by 10.224.33.14 with SMTP id f14mr52436279qad.69.1362681998127; Thu, 07 Mar 2013 10:46:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.27.230 with HTTP; Thu, 7 Mar 2013 10:45:58 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <CAJrXDUHvcsuN6vXs8wku_aUrs-siHdn2wBDOJBgpgDPJySgdSg@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 7 Mar 2013 10:45:58 -0800
Message-ID: <CABcZeBMt7vaMnhcDD0-U7n6Hn-T=sHcGUGEV4=vAs8DVcoi-CQ@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: multipart/alternative; boundary=20cf3074b9a470cb2304d75a20f5
X-Gm-Message-State: ALoCoQnf+lpC1bD1hfVSMQpiXgaaPitGiuZnSU0Z3lyrWrfPa4XCL5PbSAls5Sh8JW07u5VrlShi
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 18:46:39 -0000

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