Acknowledging TTL=0 messages

[martinthomson]

The primary advantage of TTL=0 is that there is no storage involved. That makes acknowledgment hard to do. Can we say that TTL=0 means that no acknowledgments will be delivered?

This doesn't need to affect the DELETE from the user agent.

[brianraymor]

Is a NACK returned if the message is not delivered?

Is seems a bit strange to privilege 0, what about TTL=1?

[martinthomson]

It might seem odd, but 0 is a special number here. A TTL of zero indicates that the message is ephemeral and it should be discarded if it can't be delivered right away. A TTL of 1 on the other hand needs to be persisted for a second, which - I will concede - is close enough that it might be effectively ephemeral.

[brianraymor]

Elio and I are fine with the special case, but still have the question - Is a NACK returned if the message is not delivered?

The intent is to still add address #17 in 00?

[martinthomson]

Push-Receipt is a sufficient signal from the application server to the push service for this. The only real cost is that the user agent needs to remain alive for a round trip time in order to receive a TCP acknowledgment for its DELETE, since that is mandatory.

A push service could just remove message resources if there was no acknowledgement requested. DELETE on a resource that is already gone just works (it's naturally idempotent). This means that no signal is required, the server will simply remove the message resource as it is delivered and the only cost is a tiny bit more live-radio time. The server can signal that the DELETE was unnecessary (410/404 status code).

I'm going to close this and follow up with another issue regarding giving the push service a little more latitude in how it manages acknowledgements. Ideally, we would like to see there being no need for reliability on acknowledgments. The only way an acknowledgment would interact with storage is by deleting it.