Unilateral unsubscription notifications (was Re: Pending websub issues)

Hi all,

Thanks for the summary, Julien. I wanted to clarify a little what I have
been thinking re #16. <https://github.com/w3c/websub/issues/16>

The idea started with me thinking, "Hmm, a hub can terminate a
subscription unilaterally in some cases. It'd be nice to be told if that
happens."

... and then it occurred to me it's useful for other things too.

Basically, being told that "after this point, you won't get any more
notifications, for this reason" seems pretty useful to me.

The stateless subscribers is just one of the additional use-cases I
thought of; it's not the primary consideration I had in mind.

Julien's point about the idea of stateless continuation encoding in
callback URLs being against security recommendations I think is wrong.
There is nothing about the termination-notification idea *or* the
stateless-subscriber idea that forbids changing URL patterns. Any
encoding of the necessary information will do.

In particular, I'm certainly not proposing replacing randomness in the
URL with encoded state. There's plenty of other positions in a
capability URL to encode state in, no need to encode anything in the
unguessable component.

  http://example.com/callback/v1/[ENCODEDSTATE]/[UNGUESSABLE-UUID]

or use path parameters, or query parameters, etc etc etc.

Each URL is, in a sense, *already* a continuation, specifying *some*
conversational context. There's a sliding spectrum of the amount of the
context explicitly carried in the URL. "Stateless subscribers" is just
one (fairly extremal) point on that spectrum.

Anyway, just wanted to make it clear that the original goal was to be
told when a subscription is terminated, because there can be many
reasons why a subscription might be terminated, not just lease expiry.

Cheers,
  Tony

Received on Tuesday, 14 March 2017 17:12:16 UTC