- From: Cullen Jennings <fluffy@cisco.com>
- Date: Wed, 19 Oct 2011 18:43:39 -0600
- To: Christer Holmberg <christer.holmberg@ericsson.com>
- Cc: Iņaki Baz Castillo <ibc@aliax.net>, Ravindran Parthasarathi <pravindran@sonusnet.com>, Jonathan Rosenberg <jonathan.rosenberg@skype.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.
Received on Thursday, 20 October 2011 00:44:07 UTC