A need for a full refresh request for a subscription has risen in practice a few times.

Problem: In some situations the client application can lose track of the current value of each monitored item. There is currently no mechanism provided for an easy and reliable way to refresh the current values.

The situation may occur:

#1 after the client re-enables the subscription by setting the PublishingMode: the specification does not define whether the current values should be sent for each item with a new notification and not all servers do this

#2 after a connection break that continues so long that the RetransmissionQueue in the server is exhausted, leading to lost notification messages. The client has no way to find out which monitored items are in sync with the server after that

The current options to refresh the items are:
a) recreate the complete subscription: this is too big an operation for such a "small" problem and breaks the continuity of the data
b) read all values for the items: the problem is that the 'read' is done in a "separate channel" and the results may be mixed up with new notifications that arrive at the same time from the subscription, so the client needs to perform extra synchronization to find out the latest values

Solution proposal:

• Add a Refresh method, which would instruct the server to resend the current value for each monitored item in the subscription.
• Also document the desired behavior for setPublishingMode when the subscription is re-enabled: require that a notification of new values are sent to the client. Disabling/Enabling the subscription could then be used to refresh the group. The application developers and users won't just figure this option out very easily, I am afraid, though.