Requirement: Add Optional Acknowledgement for Event Subscription/Unsubscription success

[RobWin]

Description: Currently, when a Thing client (consumer) subscribes or unsubscribes to events from a Thing Server, the client typically has to wait until an error occurs or the first event is received before it can proceed with other actions that are dependent on the success or failure of the subscription/unsubscription.

This can be problematic for clients that require immediate feedback on the status of the subscription/unsubscription, as waiting for an event or an error might introduce unnecessary delays in their workflows.

Proposal: To improve this, it would be helpful if the protocol allows the consumer to define whether it expects an acknowledgment (ACK) from the Thing Server indicating whether the subscription or unsubscription was successful. This would enable the client to proceed with further steps without having to wait for the first event or potential error.

Suggested Changes:

1. Introduce a new field in the subscribeEvent/unsubscriveEvent message where the client can specify whether an immediate acknowledgment (ACK) is desired.
2. The Thing Server, upon receiving this request, will respond with an ACK if the operation was successful or with an error message if it failed.

Benefits:

• Improved Workflow: Clients can immediately proceed with subsequent actions without unnecessary delays.
• Clearer Communication: Acknowledgments will provide explicit feedback on the success or failure of the subscription/unsubscription request.

[hspaay]

+1 some way to know if subscribe/observe was successful.

[benfrancis]

I'd suggest that if this is defined then it should just be a mandatory response from a Thing when subscribing to an event rather than be configurable by the Consumer, to avoid the complexity of additional conditional logic.

If event subscriptions are acknowledged then there should probably also be acknowledgements of other asynchronous operations. Specifically, observing a property and invoking an action:

• When observing a property I had wondered whether upon successful observation the Thing should immediately send a propertyReading message with an initial value, without waiting for the property to change first. That has the dual benefit of confirming the property observation was successful, and informing the Consumer of the initial property value without requiring a separate readProperty message.
• When invoking an action, the Thing could immediately send an actionStatus message with a status of "pending", since the action request ID is needed by the Consumer for queryAction messages anyway.

To follow this same pattern it would be tempting to re-use the event message type to acknowledge an event subscription, but I worry that would be confusing. It might therefore make sense to introduce a separate eventSubscription message which confirms an event subscription (and unsubscription).

E.g.

{
  "thingID": "https://mythingserver.com/things/mylamp1",
  "messageType": "eventSubscription",
  "event": "overheated",
  "status": "subscribed",
  "requestID": "123e4567-e89b-12d3-a456-426655",
  "timestamp": "2021-11-10T11:43:20.135Z",
}

{
  "thingID": "https://mythingserver.com/things/mylamp1",
  "messageType": "eventSubscription",
  "event": "overheated",
  "status": "unsubscribed",
  "requestID": "123e4567-e89b-12d3-a456-426655",
  "timestamp": "2021-11-10T11:43:20.135Z",
}

Note that there is a requestID to correlate a subscribe/unsubscribe request with a response (to help avoid race conditions), but no subscriptionID. That means the Thing doesn't need to worry about managing multiple subscriptions to the same event from the same Consumer, it is either subscribed to the event or it isn't. Multiple subscribeEvent messages with the same event name do not create multiple subscriptions*.

---

* Which does raise the question of what happens if a subscribeAllEvents message is followed by an unsubscribeEvent message, but that's probably a separate issue.

[RobWin]

I'd suggest that if this is defined then it should just be a mandatory response from a Thing when subscribing to an event rather than be configurable by the Consumer, to avoid the complexity of additional conditional logic.

Yes, makes sense.

If event subscriptions are acknowledged then there should probably also be acknowledgements of other asynchronous operations.

Yes, agree

When observing a property I had wondered whether upon successful observation the Thing should immediately send a propertyReading message with an initial value, without waiting for the property to change first. That has the dual benefit of confirming the property observation was successful, and informing the Consumer of the initial property value without requiring a separate readProperty message.

Yes, I’ve implemented it this way. The propertyReading message serves as both an acknowledgment that the observation request was successful and a means to provide the initial property value. The message includes a correlationId that matches the messageId of the observeProperty message for clear association.

When invoking an action, the Thing could immediately send an actionStatus message with a status of "pending", since the action request ID is needed by the Consumer for queryAction messages anyway.

Yes, I’ve implemented it this way. Sending an immediate actionStatus message with a status of "pending" is especially useful for managing long-running actions and tracking their state. This approach allows the action to send multiple actionStatus updates until it is marked as completed or an error occurs. Each message includes the request’s messageId as a correlationId for clear association.

[RobWin]

To follow this same pattern it would be tempting to re-use the event message type to acknowledge an event subscription, but I worry that would be confusing.

I would also like to avoid to use the event message as an acknowledge.
I would also prefer to introduce a new message type to describe the state of the subscription.

Note that there is a requestID to correlate a subscribe/unsubscribe request with a response (to help avoid race conditions), but no subscriptionID. That means the Thing doesn't need to worry about managing multiple subscriptions to the same event from the same Consumer, it is either subscribed to the event or it isn't. Multiple subscribeEvent messages with the same event name do not create multiple subscriptions*.

Yes, I agree. Multiple subscriptions to the same event over a single WebSocket connection should not be allowed. However, I also use the messageId of the observeProperty request message as a correlationId (subscription id) and attach it to event messages, enabling the client to dispatch them to specific flows or reactive streams. The event name alone is insufficient for dispatching, as a client might unsubscribe and resubscribe to the same event. Using messageId as some sort of subscriptionId allows for the creation of dedicated streams for event messages, which can be closed or canceled appropriately.