This can be addressed by sending a RefreshRequired event. The description for this event should mention the transparent redundancy use case (i.e. after a failover the server sends this event and the client must update its display).

Possibly in an error condition appendix.

The eventIds are used to uniquely identify an event and they must be shared between server or generate in such a manner that they are consistent on all redundant servers. If this is not the case then historical event will be broken, since it will be impossible to match up events on a failover.

In a transparent redundancy system, a client shall not even notice that a server has failed, i.e. a client will have to perform no operations and will not recieve any information other then a server status update that indicate one of the redundant nodes has failed.

In a hot, warm and cold redunancy case it is acceptable to require a client to perform some action (like a Refresh), but if it is required the server should initiate it via a RequestRefreshEventType Event

Updated text and reviewed in meeting

Reviewed in telecon.