Subject: [core] CoAP over WebSockets version -00 published

From: <[email-masked]>
Date: Mon, 15 Jul 2013 19:15:13 +0000

Hi all,

We have published draft-savolainen-core-coap-websockets-00 (http://www.ietf.org/internet-drafts/draft-savolainen-core-coap-websockets-00.txt) that describes how to retrieve and update CoAP resources using CoAP requests and responses over the WebSocket Protocol.

Please see the draft for details - we discuss there, for example, the scenarios where we envision this to be useful, and technical details required for handshaking WebSocket connection for CoAP and for actually transporting CoAP messages within WebSocket framing. Of course not forgetting "coap+ws" URI scheme for identifying both the WebSocket endpoint and CoAP resource within that endpoint.

All comments welcome.

Best regards,

	Teemu

---

From: Floris Van den Abeele <[email-masked]>
Date: Tue, 16 Jul 2013 10:59:54 +0200

Considering websockets as an other transport protocol for CoAP seems to 
be a valid approach. Personally I hadn't considered the <webbrowser 
running a CoAP server> use-case yet, but it looks interesting.

One remark I have is that - in the CoAP proxy use-case - the WS Client 
can't inform the CoAP proxy which message type (NON/CON) it should use 
to contact the CoAP UDP Server. When talking CoAP over UDP on both ends 
of the proxy I would imagine that a proxy would just re-use the CoAP 
message-type of the incoming request? This remark isn't specific to the 
WebSockets transport though, it applies to all transports that provide 
reliability. Do the authors (or the list) know of any guidelines for 
this remark (or should we help define these)?

Finally, out of curiosity do the i-d authors have any running code 
implementing this draft?

Cheers,
Floris

Op ma 15 jul 2013 21:15:13 CEST, [email-masked] schreef:
>
> Hi all,
>
> We have published draft-savolainen-core-coap-websockets-00 
> (http://www.ietf.org/internet-drafts/draft-savolainen-core-coap-websockets-00.txt) 
> that describes how to retrieve and update CoAP resources using CoAP 
> requests and responses over the WebSocket Protocol.
>
> Please see the draft for details - we discuss there, for example, the 
> scenarios where we envision this to be useful, and technical details 
> required for handshaking WebSocket connection for CoAP and for 
> actually transporting CoAP messages within WebSocket framing. Of 
> course not forgetting "coap+ws" URI scheme for identifying both the 
> WebSocket endpoint and CoAP resource within that endpoint.
>
> All comments welcome.
>
> Best regards,
>
> Teemu
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: <[email-masked]>
Date: Mon, 29 Jul 2013 11:20:38 +0000

>Finally, out of curiosity do the i-d authors have any running code implementing this draft?

We now have a quick implementation running: javascript code running in a web browser that is able to send CoAP requests over WebSocket to a server, which has node.js code able to reply with CoAP responses over WebSocket :)

Teemu

---

From: Zach Shelby <[email-masked]>
Date: Mon, 29 Jul 2013 13:43:52 +0200

Teemu,

Just seeing the title of this made my eyes hurt - and reading the draft, my eyes don't hurt any less. WebSockets may turn out to be one of the most mis-used protocols the IETF has produced lately, and this doesn't make that any better. 

First, I really can't figure out the use case for this. I mean, I could figure out a use case for doing bi-directional REST between a browser and web server using CoAP over WebSockets as otherwise the payload inside is in practice proprietary (which was the whole point). But that has nothing to do with constrained devices or networks, so we probably shouldn't be solving that problem here. 

What you really want to do here is CoAP over TCP, and we are already doing this for limited use cases in deployments. Why do CoAP over WebSockets over TCP, plus the associated handshake overhead? Also the URI mapping is a messy complication.

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Rick Bullotta <[email-masked]>
Date: Mon, 29 Jul 2013 12:09:17 +0000

Aren't people/browsers/HTTP consumers part of the "internet of things"?  One primary reason why this is valuable = it enables the protocol to be consumable from a browser, allowing low-latency notifications/events to be pushed to the consumer with minimal routing, firewall or proxy issues.  The same transport could also be used for a binary or textual encoding of a protocol (which makes debugging significantly easier if implemented properly).  Traditional REST over HTTP doesn't work for this.  HTTP callbacks and long polling are messy hacks.  For that matter, I'd love to see a standardized JSON (or other human readable) representation of the COAP protocol.  Not every user wants to be hacking hex codes and bits debugging M2M/IoT apps.  Also, once the WS upgrade is negotiated (which is of course once per connection, which are generally long-lived), the framing overhead is very minimal.

Any protocol's ultimate applicability (and adoption) needs to consider more than just the technical merits.  It needs to consider the consumers and users and the breadth and variety of possible applications.  To me, it would seem that a higher level binding (e.g. WS/JSON) that automatically maps/routes to a lower level binding (TCP/COAP binary) would make a lot of sense.  Along with a really high level binding via an HTTP REST API.  That would empower a broad audience of providers and consumers to leverage it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Monday, July 29, 2013 7:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [core] CoAP over WebSockets version -00 published

Teemu,

Zach

---

From: Zach Shelby <[email-masked]>
Date: Mon, 29 Jul 2013 14:26:52 +0200

Rick,

Now when we talk about a high-level WS/JSON binding for web server/proxy to browser communication, that starts to make more sense. But again, that really isn't in the scope of constrained device communication, that is a browser/UI issue. That also does not require CoAP over WS, it requires a mapping from CoAP over TCP to WebSockets running something appropriate (e.g. JSON) for the application. 

Zach

---

From: Likepeng <[email-masked]>
Date: Mon, 29 Jul 2013 12:31:22 +0000

>That also does not require CoAP over WS.

+1. CoAP over WS is not suitable for constained devices.

Kepeng
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Zach Shelby [[email-masked]]
发送时间: 2013年7月29日 20:26
到: Rick Bullotta
Cc: [email-masked]
主题: Re: [core] CoAP over WebSockets version -00 published

Rick,

Zach

---

From: <[email-masked]>
Date: Tue, 30 Jul 2013 08:07:51 +0000

Zach, Rick,

We have also thought about JSON representation of CoAP messages as a possibility for browser/web server (that is acting as CoAP proxy) communications, but not written down anything on the topic at least yet. 

Did I understood you Zach right yesterday in that we should clarify in the draft that the intended use-case is a distributed CoAP application running in both web browser and web server. And this application is preferring CoAP communication all the way rather than going through HTTP/CoAP translation (e.g. to allow new CoAP options with minimal to no changes to proxy). 

Best regards,

Teemu

-----Original Message-----
From: ext Zach Shelby [mailto:[email-masked]] 
Sent: 29. heinäkuuta 2013 14.27
To: Rick Bullotta
Cc: Savolainen Teemu (Nokia-NRC/Tampere); [email-masked]
Subject: Re: [core] CoAP over WebSockets version -00 published

Rick,

Zach

---

From: chrysn <[email-masked]>
Date: Tue, 30 Jul 2013 14:05:17 +0200

On Mon, Jul 29, 2013 at 02:26:52PM +0200, Zach Shelby wrote:
> Now when we talk about a high-level WS/JSON binding for web
> server/proxy to browser communication, that starts to make more sense.
> But again, that really isn't in the scope of constrained device
> communication, that is a browser/UI issue.

a websocket transport for coap is as much in the scope of constrained
device communication as is the coap http mapping.

> That also does not require CoAP over WS, it requires a mapping from
> CoAP over TCP to WebSockets running something appropriate (e.g. JSON)
> for the application. 

coap over tcp would not cover the imo most important application of
this: web applications can not directly access tcp, while they can open
websocket connections.

i've experimented with coap over websockets; the most important use case
for it from my point of view is complementing a coap-http proxy to
expose those features of coap that can't be mapped to http directly
(observations in my use case, and multicast).

On Mon, 29 Jul 2013 12:09:17 +0000, Rick Bullotta wrote:
> To me, it would seem that a higher level binding (e.g. WS/JSON) that
> automatically maps/routes to a lower level binding (TCP/COAP binary)
> would make a lot of sense. Along with a really high level binding via
> an HTTP REST API. That would empower a broad audience of providers and
> consumers to leverage it.

concerning high level bindings, i suggest to get matthias kovatsch
involved (cc'ing in case you're not on the list). his copper
implementation might be leading the way to a dom-level coap api (i'm
thinking CoAPRequest a la XMLHttpRequest), and until browsers can offer
that natively (which i doubt will be widespread), coap over websockets
could be the proxy tunnel a fallback js library could utilize.

best regards
chrysn

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

---

From: Zach Shelby <[email-masked]>
Date: Tue, 30 Jul 2013 14:35:53 +0200

Hi,

Yes, I agree you could use CoAP over WebSockets for a Browser to communicate with a CoAP-WebSocket proxy. As long as we're clear CoAP over WebSockets is not a sane way to communicate with constrained devices end-to-end. Could we title this CoAP-WebSocket proxying instead? 

But instead of a duck-tape solution just because HTML5 doesn't expose UDP or TCP support, why don't we lobby the HTML5 folks and major browsers to add CoAP (over UDP or TCP, or even WebSockets) API. 

Zach

---

From: chrysn <[email-masked]>
Date: Tue, 30 Jul 2013 15:10:41 +0200

On Tue, Jul 30, 2013 at 02:35:53PM +0200, Zach Shelby wrote:
> But instead of a duck-tape solution just because HTML5 doesn't expose
> UDP or TCP support, why don't we lobby the HTML5 folks and major
> browsers to add CoAP (over UDP or TCP, or even WebSockets) API. 

the issue here is security. web sites are usually allowed to cause the
client to fetch other resources, and whoever operates a web service
inside a LAN should be aware of that, and of how the browser finds out
whether it may do something or not.

for exposing coap via udp in the browser, we'd have to work out
something similar to cors for http. (but similar to how coap moved the
http link header into a distinct resource, i'd say the same should be
done with the cors headers -- a la

    </led/1>;if="core.a";cors.allow-methods="get"

though given the devices we work with, it needs to be simple. a
</cors>;ct=40;cors.see-also providing the same information might be
reasonable in many cases.)

if we have both an api and a security model, i assume there is a chance
to get that into browsers (matthias might have more information there),
but even then, that'll take years to become widespread, and i doubt
it'll achieve the coverage needed for end users.

having an extension to the http proxying that makes all of coap
available (like would a core-ws-mapping based on core-coap-websockets)
would serve both as an early usable solution as well as as a fallback
path that can be provided by a proxy; plus, we can take our time to
develop the api atop of that (or, in parallel, based on copper).

best regards
chrysn

-- 
A beginning is the time for taking the most delicate care that the
balances are correct.
  -- Princess Irulan, Manual of Muad'Dib

---

From: Rick Bullotta <[email-masked]>
Date: Tue, 30 Jul 2013 16:01:41 +0000

Never happen.  At least not in a ubiquitous or timely way.  No technical reasons, just practical ones.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Tuesday, July 30, 2013 8:36 AM
To: chrysn
Cc: [email-masked]
Subject: Re: [core] CoAP over WebSockets version -00 published

Hi,

Zach

On Jul 30, 2013, at 2:05 PM, chrysn <[email-masked]> wrote:

> this: web applications can not directly access tcp, while they can 
> open websocket connections.
> 
> 
> i've experimented with coap over websockets; the most important use 
> case for it from my point of view is complementing a coap-http proxy 
> to expose those features of coap that can't be mapped to http directly 
>> an HTTP REST API. That would empower a broad audience of providers 
>> and consumers to leverage it.
> 
> thinking CoAPRequest a la XMLHttpRequest), and until browsers can 
> offer that natively (which i doubt will be widespread), coap over 
> websockets could be the proxy tunnel a fallback js library could utilize.
> 
> best regards
> chrysn
> 
> --