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

Marc Petit-Huguenin <> Thu, 20 October 2011 00:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BB6121F84DD for <>; Wed, 19 Oct 2011 17:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.19
X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qwbswbsR8Tx5 for <>; Wed, 19 Oct 2011 17:55:35 -0700 (PDT)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id 9C8C111E80B6 for <>; Wed, 19 Oct 2011 17:55:35 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] ( [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "" (verified OK)) by (Postfix) with ESMTPS id A66C420595; Thu, 20 Oct 2011 00:47:35 +0000 (UTC)
Message-ID: <>
Date: Wed, 19 Oct 2011 17:55:30 -0700
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Cullen Jennings <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Jonathan Rosenberg <>, "" <>, "" <>
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Oct 2011 00:55:36 -0000

Hash: SHA1

On 10/19/2011 05:43 PM, Cullen Jennings wrote:
> 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. 

I disagree here.

> 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.

- -- 
Marc Petit-Huguenin
Personal email:
Professional email:
Version: GnuPG v1.4.11 (GNU/Linux)