POST for queueing doesn't solve the QoS issue with missed publications

[mjkoster]

If a client subscribes using Observe, there is no handshake on the observe response to indicate that the notification was received by the subscriber. Creating a list of published representations in the broker using POST only covers the case where the broker can't keep up with sending notifications. The notifications are still "best effort".

To solve the QoS issue, we should have the subscriber create a queueing resource on the broker, which is specific to that subscriber, for each subscribed topic for which more than "best effort" QoS is desired. This resource will store published representations until the subscriber can retrieve or accept them.

The subscriber may use GET to return the representation of the queueing resource, receiving a list of links to published representations which may then be fetched using GET. The subscriber would be responsible for removing the representations it has fetched.

This enables sleepy subscribers and subscribers behind NAT firewalls to receive notifications without data loss.

We may also provide a resource that may be observed which returns and removes representations from the queue, in published order, using GET or Observe. Using GET, the broker would return "no data" upon fetches to an empty queue.

A sleepy subscriber could wake up, subscribe, receive notifications, unsubscribe, and sleep again.

We may also provide a means for the subscriber to request a push or "web callback" using PUT or POST to update a resource on the subscriber upon notifications.

We could keep "simple pubsub" as it is, and allow queueing pubsub as an optional feature for enhanced QoS, sleepy subscribers, etc.