If you force the client to ask for republish, this will cause other issue with long lasting disconnection.
1) The server has no obligation to keep unacknowledge item forever, so you can miss the oldest items
2) Some historians do not accept inserting data older than the current one, so if the client needs to ask for Republish, he will need creative fifo to stack items he just receives, then ask for republish of "untransmitted items", wait for them (other entries may arrive during that time), place these items in order and finally send all items in the right order to the historian.

One possible solution is to force the server to assume that, after a disconnection, the "unacknowledge" items as been lost so they need to be retransmitted in the right order. The only issue is if the SourceTimestamp is not transmitted, the client will not be able to identify which data as already been received. Following this rule, the client may use the timestamp to identify already received items, which is quite simple.

We agreed that the worst case in a reconnect scenario the client may not detect a missting message for 2X the keep alive interval (instead of the normal one). Also the client may want to temporarily set a shorter keep alive interval after a reconnect to remedy this. To do this an SDK that does auto reconnect needs to notify the client that a reconnect occured. This scenario should be described in the spec.

Also we need to make this normative change to Clause 5.13.1.1 (changed one interval to three intervals)

i) Subscriptions maintain a retransmission queue of sent NotificationMessages. NotificationMessages are retained in this queue until they are acknowledged or until they have been in the queue for a minimum of three keep-alive intervals. Clients are required to acknowledge NotificationMessages as they are received.

UA WG meeting March 16

• Change minimum resend queue to "min publish request queue size" or to "three times keep-alive interval"
• Explain problem and possible clien side solutions in Republish

Updated the minimum requirement for the retransmition queue of sent NotificationMessages from one to three keep-alive intervals but allowed the server to restrict the size of the queue to two times the minimum number of Publish requests per Session.
Added a description of the issues and strategies regarding reconnect and Republish.

Change is part of the draft version "OPC UA Part 4 - Services Draft 1.02.03 Body.doc"

Reviewed in telco on March 23, 2011
The final changes are included in the document revision OPC UA Part 4 - Services 1.02.04 Draft.doc

This change was not reviewed yet.

Need to enhance reconnect description in Republish.

Proposed change:
Recommend to call Republish until an error is returned for the next expected sequence numbers before calling Publish after reconnect.

Added new chapter 6.4 Re-establishing connections.
Moved the description about Republish and reconnect handling to this section.

Changed in document version OPC UA Part 4 - Services 1.02.06 Draft.doc

Discussed at F2F

Need to add sentance indicating what to do if repiblish misses something and also that a profile may change the minimum count

Updated Text:

Added text to 5.13.1 Subscription model -> 5.13.1.1 -> (i)
The minimum size of the retransmition queue may be changed by a Profile in Part 7.

Added text to 6.4 Re-establishing connections
If the Client detects lost sequence numbers in the Publish and is not able to get the lost NotificationMessages through Republish, the Client should read the values of all data MonitoredItems to make sure he has the latest values for all MonitoredItems.

Changed in document version OPC UA Part 4 - Services 1.02.11 Draft.doc

Reviewed and agreed to changes in telecon.