I have a few thoughts on this draft too.
6455-Websockets was a point in time solution for a problem that was solved later and better by HTTP/2 (RFC 7540) with the introduction of parallelism, multiplexing, and non 1:1 bi-directional message capabilities (which 6455 only solves 1/3 of).. 6455 is now considered historical and legacy cruft by many. I don't know of anyone that would think that if 6455 did not exist it should be introduced into today's ecosystem. (we would still want a dev-facing interface doing some of the same things as websockets at a js layer, but it would not be implemented on the wire 6455 style.)
If the motivation of the websockets-coap binding is to deal with bi-directional problems better than HTTP/1, the answer to me seems to be to use HTTP/2 (and maybe an extension of the existing http mapping) rather than building a parallel system of gateways, proxies, and tunnels on top of 6455. It is unfortunate enough (perhaps unavoidable?) that we have a parallel stack of constrained protocols without building a gatewaying system between them rooted in legacy baggage.
The draft as much as acknowledges this with some not totally convincing handwaving (that is not meant pejoratively - I've been known to hand wave :))
Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP.
The aspects of the proposed solution that would seem to pose the largest challenges for constrained devices, (tcp and tls) are also present in wss:// as well - which begs the question of whether this is designing a nominally constrained-device ecosystem actually for not-so-badly-constrained gateways and they should be using our primary security, application, and transport standards directly. This parallel stack has to end somewhere, right?
also, if you stay within the semantics of http, but require 7540 or its successors for reasons of performance, you will pick up quic for free when we get there - which is just a specific instance of the general argument with forking standards.
lastly I think the security considerations (both in that section and elsewhere) could use some work.
The purpose of websockets-6455 is to deploy a mechanism, consistent
with the web security model, for non-privileged _javascript_ to be able
to communicate using communication patterns that do not fit into the
HTTP/1 request/reply pattern well. To be consistent with that security
model a websockets end point needs to opt into doing websockets,
potentially doing a particular sub-protocol, and be expecting this
request to have been triggered by a particular Origin.
The
net effect is to prohibit random _javascript_ from the web from spraying
around arbitrary TCP streams behind every user agent's firewall, or
otherwise generating arbitrary botnets (beyond what is allowed by SOP
anyhow).
The coap-tcp-tls-websockets
forward-proxy model builds an arbitrary gateway from websockets to coap
based on proxy-uri and would seem to run afoul of the security model by
spraying arbitrary coap around instead of arbitrary tcp :).. Reverse
proxy models, being locked down to particular origins, work better.
(and as
a final nit the websocket handshake examples do not have an Origin request
header as required by 6455 for browsers, and I think browsers are in
scope of this document - but thinking and talking about Origin is a key part of when websockets is and is not appropriate.).
-Patrick
On Wed, May 10, 2017 at 12:31 AM, Carsten Bormann <cabo@xxxxxxx> wrote:
> On May 9, 2017, at 23:30, Mark Nottingham <mnot@xxxxxxxx> wrote:
>
> To close this loop -- the change in -08 isn't sufficiently prominent IME; while the general nature of the change is listed in the Abstract, the actual normative text is very hard to find.
Certainly, let’s see what the IESG decides here.
> Given that this is a pretty fundamental change in the operation of a URI scheme, I'd think it at least deserves its own section, if not a separate document.
I don’t agree that this is such a fundamental change here — the /.well-known name space in the URI already was special (by the fact that ws URIs are mapped to http URIs, which do have /.well-known reserved already).
But that doesn’t matter, we should find the best editorial way to document making the well-known URI concept available to WebSocket URIs.
Grüße, Carsten