3.2.5.9.4.6 Receiving a RopSynchronizationImportReadStateChanges ROP Request

When the client sends the server a RopSynchronizationImportReadStateChanges ROP (section 2.2.3.2.4.6) request, the server MUST parse the request, as specified in [MS-OXCROPS] section 2.2.13.3.1 and section 2.2.3.2.4.6 of this specification. The server MUST respond with a RopSynchronizationImportReadStateChanges response, as specified in [MS-OXCROPS] section 2.2.13.3.2 and section 2.2.3.2.4.6 of this specification.

The RopSynchronizationImportReadStateChanges ROP is a batch variant of the RopSetMessageReadFlag ROP ([MS-OXCROPS] section 2.2.6.11), which updates the ICS state as well. The result of changing the read state message by message by using the RopSetMessageReadFlag ROP MUST be identical to changing the read state in bulk by using the RopSynchronizationImportReadStateChanges ROP.

Requests to change the read state of FAI messages MUST be ignored. Upon successful completion of this ROP, the ICS state on the synchronization context MUST be updated by adding the new change number to the MetaTagCnsetRead property (section 2.2.1.1.4).

To minimize the possibility of putting replicas into a desynchronized state and because the protocol does not notify clients as to what part of an operation has succeeded, servers are responsible for making a reasonable prediction as to whether all read state changes will succeed. And, if a read state change will not succeed, the server SHOULD fail the ROP before performing any read state changes, as opposed to partially completing the ROP.