- From: Carsten Bormann <cabo@tzi.org>
- Date: Thu, 14 Jul 2016 00:16:56 +0200
- To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, "draft-montenegro-httpbis-h2ot@tools.ietf.org" <draft-montenegro-httpbis-h2ot@tools.ietf.org>, "t2trg@irtf.org" <t2trg@irtf.org>
(CCing T2TRG, whom I'd ask to have a look at the above document.) Gabriel Montenegro wrote: > One unresolved issue is called out in the security considerations section: one of *the* IoT ciphersuites (TLS_PSK_WITH_AES_128_CCM_8) is disallowed explicitly by HTTP/2: Indeed. HTTP/2 has good mechanism for many applications in the IoT (see below for some more thoughts). However, this mechanism is also loaded with policy, which only really considers the Big Web/Browser Web today. Getting those policies adapted to the little web may be the biggest change that is needed, much less so more (or different) mechanism. Not all of the IoT is in the little web, so it's easy to find examples where generalities do not apply. It may also be more instructive to think both about the 1 W+, $50 (A-class platforms with Linux) IoT vs. the $5 (or $0.50), microcontroller and microwatts IoT. Looking at the three REST transfer protocols, CoAP's niche is among other details based on: -- several orders of magnitude less complexity for basic cases; -- support for UDP, which is both simpler and often more robust; -- notifications about resource changes (RFC 7641 "Observe"). Obviously, for the $50 IoT (more so the $1000 IoT) the first point can be less important. UDP support provides more robustness in networks designed to connect sensors and actuators; in the legacy InterNAT, actually TCP can be more robust (for that reason, we are even defining CoAP-over-TCP as we speak). I'd really like to focus on the third point. CoAP has extended REST with notifications, as it is natural for a resource exposing a sensor value to change. But REST spans all three protocols, and so should such an extension. Well, maybe HTTP/1.1 is too difficult, but HTTP/2 has a lot of mechanisms already in place to facilitate this. Maybe we can find a common model for these that CoAP can then also extend into as appropriate; clearly RFC 7641 "Observe" is just a start. Grüße, Carsten
Received on Wednesday, 13 July 2016 22:17:27 UTC