Push message update mechanism

[martinthomson]

This is relatively straightforward.

Closes #9.

[brianraymor]

Regarding the "conditional DELETE", then are we specifying that the PS will include an etag with the pushed message that can be used by the UA for its DELETE acknowledgement?

[martinthomson]

The ETag on the push message might be a good signal that acknowledgment was requested.

As for equivalent, I understand and will try to reword somehow. (Being clear, concise and accurate is sometimes hard.)

[martinthomson]

How long is the PS "encouraged" to treat an update as equivalent to creation? It seems like the AS would have to roll the dice and guess on whether to use a POST or a PUT. Seems cleaner to return an error if the resource was deleted.

This was intended primarily to avoid races where the acknowledgment and update arrive at around the same time. I always think of collapse going from "You have (1) new messages" immediately to "You have (2) new messages", which suggests that there isn't much time in between. If there is an acknowledgment, then creating a new message is cleanest. If there isn't (or isn't yet), then you risk a race.

Perhaps we can suggest that you don't collapse if a message has been acknowledged. Then the only time window you have to worry about here is a round trip and change.

[martinthomson]

Note that this is the sort of thing that will inevitably attract a helpful suggestion to remove the complexity. Then we simply recommend that the PUT fail and we incur a round trip.

[ghost]

How does this interact with delivery receipts?

• If the initial POST request includes a Push-Receipt header, but the PUT doesn't, should the push server still send a receipt?
• Conversely, what if the PUT specifies a different Push-Receipt resource? Should the push server send receipts to both resources, or only the most recent one?
• What happens if Push-Receipt is specified, the client receives and acks the original message, and then receives the updated message? Should it ack the update?
• To that end, should app servers be prepared to handle duplicate receipts for the same message?
• If the push server can detect that an update has already been delivered, should it create a new push message resource and respond to the PUT with a 308?

[bbangert]

How does this interact with TTL's?

[martinthomson]

@kitcambridge, sorry for being slow about this, this hasn't had a lot of attention. I think that it is more important than carrying data in acknowledgements however, so...

(All of these need to be integrated into the change, of course.)

If the initial POST request includes a Push-Receipt header, but the PUT doesn't, should the push server still send a receipt?

I would model this as a replacement, in every respect, so the absence of a Push-Receipt in an update would result in no acknowledgment. If an acknowledgement had been received and the resource removed, then the usual considerations regarding that race apply.

Conversely, what if the PUT specifies a different Push-Receipt resource? Should the push server send receipts to both resources, or only the most recent one?

Just the most recent.

What happens if Push-Receipt is specified, the client receives and acks the original message, and then receives the updated message? Should it ack the update?

Yes.

This is the case where the update and the ack pass each other between the push service and the user agent. We should be making acknowledgements conditional, which means that the first ack will have failed, since it hit a different state to what it expected.

To that end, should app servers be prepared to handle duplicate receipts for the same message?

The only case that is a concern here is if we allow application servers to update a message after it has been acknowledged. In that case, the application server will have to deal with the possibility of multiple acknowledgments.

For that, I think that we might want to ask some of the heavier users of push what model best suits their needs.

If the push server can detect that an update has already been delivered, should it create a new push message resource and respond to the PUT with a 308?

Interesting; though I think that ultimately looks like a failure because you can't avoid the client (in this case, our application server), from making a new request.

@bbangert, The TTL is relative, so it would be refreshed by this.

[bbangert]

This example should be updated to include a non-zero TTL. Lacking a TTL means it is effectively 0, which is counter-intuitive to asking for a stored message to be updated.... since TTL 0 means it must be delivered immediately.

[martinthomson]

Good point. Updated. Also rebased.

[martinthomson]

In writing up slides, I realized that we don't recommend the use of etags in acknowledgments. This has a different race condition if you don't use them.

[martinthomson]

Rebased and updated to more directly address the update of TTL and Push-Receipt.

[martinthomson]

Discussed in Yokohama, need a new pull request.