Subject: [Webpush] My conclusion regarding disaggregation

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Apr 2015 17:01:56 -0700

I have concluded that disaggregation is the right approach.  Though
not for any of the reasons raised at the meeting.

The analysis I posted yesterday concluded that perhaps the efficiency
downsides of disaggregation can be mitigated sufficiently if a push
service is careful enough with identifier allocation and compression.
That mostly removed the downsides for me, but didn't really provide
any actual justification for disaggregation.

Since writing that, I've been thinking about the protocol consequences
of splitting the subscription into two resources.

After thinking that through, I concluded that splitting the
subscription in two naturally leads to disaggregation.  And combined,
those two changes have some nice properties and they even enables some
features that we might want to include.

---
With a split subscription, the application server (AS) pushes against
one resource, which triggers a notification at the user agent (UA).

* In the aggregated case, the push service (PS) has to use a single
identifier for all messages pushed to that subscription (either the
public or the private URL associated with that subscription),
otherwise the UA has no way of properly identifying the subscription.

* On the other hand, if we don't have registration, then monitoring
each subscription directly ensures that the client can easily identify
the subscription context.  That allows us to uniquely identify each
message with a URL.

Being able to uniquely identify messages has several benefits:

* Message collapsing is easy: rather than using POST to create a new
message, the contents of a previous message can be replaced with new
content using PUT.

* Message acknowledgment is easier: the UA can acknowledge a message
using a DELETE request on it.  If we do collapsing, then the DELETE
will ideally be conditional (using If-None-Match or
If-Not-Modified-Since), but that's the only real source of
complication.

* Application servers can cancel message delivery by acknowledging
messages that they sent.

* I can also imagine being able to navigate a set of messages using
"next" and "prev" relations, but that's not actually addressing any
use case, so I don't think that we'd specify it.  It's merely nice
from a consistency standpoint.

The only potential pitfall I can see is that if a collapsed message is
updated just prior to an "acknowledgment", the ack will be lost since
the DELETE is conditional.  I think that's OK: that only happens when
the UA is online, so the UA will get the updated message quickly and
can acknowledge the updated message straight away.

Of course, messages will need to be given unguessable URLs for some of
these to work without extra authentication machinery, but that's easy.

---
I've spoken with Brian and Elio about this.  Brian is doing a write-up
of the basic design.  We'll have a merged proposal ready shortly for
discussion (and hopefully adoption).  I've already suggest that this
merged design not include a registration option.