Dear Mark > OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel > HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over > HTTP again, rather than just using HTTP (which AIUI you already have a mapping > to). The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices. I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit? Best regards Matthias