Reviewer: Mark Nottingham
Review result: Not Ready
First, a general comment. I have been concerned about the duplication
of effort that COAP represents for some time, and that concern grows
significantly upon reading this draft. COAP is now specifying multiple
"bindings" to underlying application and transport protocols,
re-inventing message framing, congestion control in UDP, etc. The
introduction justifies this development over the reuse of HTTP/2 (and
presumably QUIC, once available) based upon the relative availability
of implementations for constrained devices. Whether that remains true
will only be judged by the market -- unfortunately after all of the
cost of development and standardisation is sunk.
The introduction motivates the layering of COAP over WebSockets to
allow it to be used in a network that only allows external access
through a HTTP proxy. In fact, it is not necessary to use WebSockets
to do so; HTTP CONNECT provides a tunnel in this scenario. WebSockets
is a specialised protocol that allows bidirectional, stream-based
transport from a Web browser -- it is effectively TCP wrapped into the
Web browser's security model, to make doing so safe. Using it for
other purposes (i.e., non-browser use cases) isn't really appropriate.
I'd suggest either removing the WebSockets binding, or changing its
motivation in the Introduction.
Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?
Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs. Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
Will COAP take the same approach for HTTP?
I would suggest a wider discussion of these issues on art@ / uri@.
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use. I'm not
sure how to address this, other than removing the WebSockets binding.
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.