Subject: [Webpush] Comment on charter and HTTP

From: Elio Damaggio <[email-masked]>
Date: Mon, 29 Sep 2014 17:43:43 +0000

Hi,

I read the charter, and, as stated, it includes any "push" protocol for arbitrary devices. Does the charter include low-powered devices, such as embedded systems (think IoT, "Smart things", etc.)?
Thanks,

Elio

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Sep 2014 11:29:34 -0700

On 29 September 2014 10:43, Elio Damaggio <[email-masked]> wrote:
> I read the charter, and, as stated, it includes any “push” protocol for
> arbitrary devices. Does the charter include low-powered devices, such as
> embedded systems (think IoT, “Smart things”, etc.)?

The overall architecture will probably suit, but the protocol might
not.  The immediate goal is to enable this for things with web
browsers, so I'd imagine that some choices will be made that are
suboptimal for IoT devices (or at least, not aggressive enough in the
power/processing cost savings direction).  It's probably not wise to
try to solve for too wide a range of devices; I've seen that go very
poorly.

That doesn't mean that we can't eventually considering widening the
net a little.  But I personally want to ensure that we have a really
good solution for browsers first and foremost.

What I was envisaging with my proposal was that this would serve as a
baseline, from which customized protocols could be bootstrapped.  For
instance, if you are talking to a server, you could hint that you can
talk some as-yet-unspecified, super-power-saving protocol, at which
point the push server switches over to that instead.  Of course, the
protocol also works over COAP with some small modifications, which
might be more practical short term goal.  None of that is in the
charter though.

---

From: Elio Damaggio <[email-masked]>
Date: Tue, 30 Sep 2014 00:58:27 +0000

I agree with you that, as long as the protocol has the right extensibility points, support for extremely low powered devices might be added later.

Given the will of creating a baseline, convergence on the following aspects could be incredibly beneficial:
* application to push server protocol (w.r.t delivery/reliability semantics, unicast-multicast options, security?)
* device to push server protocol extensibility (as for your comment)
* lifecycle of channels (expiration, renewal)

Does the charter include some or all of the above?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 11:30 AM
To: Elio Damaggio
Cc: [email-masked]; [email-masked]
Subject: Re: [Webpush] Comment on charter and HTTP

On 29 September 2014 10:43, Elio Damaggio <[email-masked]> wrote:
> I read the charter, and, as stated, it includes any “push” protocol 
> for arbitrary devices. Does the charter include low-powered devices, 
> such as embedded systems (think IoT, “Smart things”, etc.)?

The overall architecture will probably suit, but the protocol might not.  The immediate goal is to enable this for things with web browsers, so I'd imagine that some choices will be made that are suboptimal for IoT devices (or at least, not aggressive enough in the power/processing cost savings direction).  It's probably not wise to try to solve for too wide a range of devices; I've seen that go very poorly.

That doesn't mean that we can't eventually considering widening the net a little.  But I personally want to ensure that we have a really good solution for browsers first and foremost.

What I was envisaging with my proposal was that this would serve as a baseline, from which customized protocols could be bootstrapped.  For instance, if you are talking to a server, you could hint that you can talk some as-yet-unspecified, super-power-saving protocol, at which point the push server switches over to that instead.  Of course, the protocol also works over COAP with some small modifications, which might be more practical short term goal.  None of that is in the charter though.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Sep 2014 19:49:48 -0700

> Does the charter include some or all of the above?

The charter is intentionally terse.  That gives us flexibility in how
we approach developing solutions on each of those points.  I'm happy
to discuss trade-offs on each.