Re: [push-api] Describe process for subscription updates (#132)

So @johnmellor proposes an event with a different name, I think.  That is, `pushsubscriptiongoing_or_gone`, perhaps (underscores added so that it didn't say "go in gorgon", which I found confusing).

I think that @johnmellor's proposal is more in the spirit of what we've learned regarding robustness.  That is, that we let the application know as soon as possible when something is wrong, or might soon be.  Then we have:

1. subscription is gone: application can try to subscribe again, though this might fail; there is a narrow window of outage where messages won't be delivered or even stored

2. subscription is going: application can try to subscribe again; if this succeeds, then there is no outage

The key here is that the action is the same.  It is good to have most applications apply a consistent action for the same event.  While `getSubscription` will reveal which of these states apply, is there any value in having a boolean flag?

Note that there is a small risk of misconception about this event.  It might be perceived as an "offline" event.  We can't trigger this event when we are offline, because offline is a normal part of the process.  We need some sort of signal that the subscription is busted and we likely only get that while online.  Text that explains this might help too.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/132#issuecomment-189836268