Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On 12/04/17 07:04, Carsten Bormann wrote:
On Apr 12, 2017, at 04:42, Mark Nottingham <mnot@xxxxxxxx> wrote:
So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.
Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one.

I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case.  (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.)

Carsten's right. The primary use case which motivated us to undertake the work were for browser access, and for sandboxed web applications that want to use CoAP-based communication to a end-point, but are restricted from using system-level APIs such as TCP or UDP socket libraries. Matthias (in a forked version of this message thread) also mentioned where we saw benefits in allowing CoAP over Websockets to reach constrained devices.

While the work was progressing however, we did become aware of minor use cases where using CoAP over Websockets can provide an advantage: Reaching constrained nodes residing in domains where end users may lack the authority to configure middleboxes to allow new services over TCP/UDP. This is commonplace in particularly restrictive and firewalled networks that otherwise allow traditional messaging, email and web-based services. However, I need to emphasise this is a minor use case.

Best regards,
Bill





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]