Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope

Cullen Jennings <fluffy@cisco.com> Thu, 20 October 2011 00:43 UTC

Return-Path: <fluffy@cisco.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 88D7511E80B3 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.846
X-Spam-Level:
X-Spam-Status: No, score=-105.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 f6YCvra98ZTz for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:43:42 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DE19411E80AF for <rtcweb@ietf.org>; Wed, 19 Oct 2011 17:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1641; q=dns/txt; s=iport; t=1319071420; x=1320281020; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Xm3KY4vh1REWPhIxTyTinFODFdnxFCB706w9ilqEQ2w=; b=MlBKwqvOb7Ea0JD5bdPeum7DcJgEIH4CrKFvNsKYSFkmNAYLdAmT6mPK FHCpYUPMEIGGz8uGRDKT4fM4Kd/bDBhwsfceocYRsMnd2KFq0Qwy0aZiP tSz/iBijkHaAHJapAPWtMQvxb4XIvyruhlLIRZ6JlemtlCEIwQboaGzyD k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAH9un06rRDoH/2dsb2JhbABEqQKBBYFuAQEBAQIBEgFmEAtGVwY1h16XfAGeT4c6YQSIAot8hSqMTA
X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9018494"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 20 Oct 2011 00:43:40 +0000
Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0heKP007374; Thu, 20 Oct 2011 00:43:40 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="iso-8859-1"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F4A36@ESESSCMS0356.eemea.ericsson.se>
Date: Wed, 19 Oct 2011 18:43:39 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F4D4B67-7AE0-4C8F-B390-B043FBA82B76@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <CALiegfnGfpWooceicAbLQ35oVDUZC6+d=903qSKkxW952i-8pw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A058522341F416A@ESESSCMS0356.eemea.ericsson.se> <10704DBF-9400-42BA-B9C5-209C338F042E@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4A36@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope
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, 20 Oct 2011 00:43:42 -0000

On Oct 19, 2011, at 6:21 , Christer Holmberg wrote:

> 
> Hi Cullen, 
> 
>>> So, while I support and offer/answer based approach, I 
>>> think we need to get a clearer understanding of the scope.
>> 
>> My view is this is draft is a set of semantics and syntax 
>> that operates over an abstract transport protocol. In most 
>> cases the transport with be web sockets or HTTP based. If 
>> this looks like a reasonable protocol, it would be likely to 
>> influence the W3C API.
> 
> As the ROAP state machine is located in the browser, doesn't that already mean that ROAP must to be supported by the API?


This whole "is this an API or Protocol discussion" leaves me sort of saying "Yes" but I'm not sure it matters much. Any API can be turned into a protocol using a RPC approach. Most protocol lead to a fairly obvious API to describe that protocol. From a category theory point of view, I consider an API the dual of a protocol. I know opinions differ but in general, I view API's and protocols as surprisingly similar. 

ROAP is a protocol that could be used to things like a gateway that converted from ROAP to SIP.  However, it is also a protocol that is designed to work well with an API like one that might be used by W3C for WebRTC. If we go down this ROAP path, I would expect that the the JSON object that gets represented by the string in ROAP would be used to pass in the WebRTC API. The two are closely related - and that is intentional. 

I'm trying to make a protocol that closely fits with what the web browsers want to implement.