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

[Bill Silverajan <[e-mail]>]

Hello,

On 12/04/17 07:04, Carsten Bormann wrote:
> On Apr 12, 2017, at 04:42, Mark Nottingham <[e-mail]> 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