Subject: Re: [Webpush] Receipts (was comments on latest draft-thomson-webpush-protocol-00)

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Jul 2015 11:06:11 -0700

On 13 July 2015 at 10:40, Costin Manolache <[email-masked]> wrote:
>> -Sec 6.2: Receiving Push Message Receipts
>>
>> If an application server has sent substantial quantities of notifications,
>> all with push receipts, and has failed to take any action to clear its
>> receipt queue, what should be done to indicate to the App-Server that it
>> isn't allowed to send any more until it clears out its receipt queue?
>>
>> It feels like there should be some way to indicate this, as its possible
>> the App-Server is malfunctioning rather than is being a bad actor.
>>
>
> Very good question.
>
> AppServer  may also get disconnected ( for example a restart or upgrade or
> network issue ) for some time, and it would miss
> any receipt for messages previously sent.
>
> I think a push server supporting receipts will need to have some persistence
> or some mechanism to indicate that delivery receipts
> may have been dropped. GCM persists the receipts and handles re-delivery.

My analysis of this was that we have two choices:

 - assume that the application server can handle receipts as they
arrive (I hadn't thought of using max concurrent streams as a form of
back pressure)
 - provide full reliability for acknowledgments in the same way as messages

It seems that this is in support of the latter.

On the latter, the only conclusion I came to was that the
acknowledgment had to be held up to the time where a message would
expire.  That is, if the push service promises to hold a message for a
day, and a message is delivered part-way through that day, then the
receipt would be held until the remainder of the day elapses.
Anything shorter means that the promise the push server makes is not
kept.