3.2.5.9.4.5 Receiving a RopSynchronizationImportDeletes ROP Request

When the client sends the server a RopSynchronizationImportDeletes ROP (section 2.2.3.2.4.5) request, the server MUST parse the request, as specified in [MS-OXCROPS] section 2.2.13.5.1 and section 2.2.3.2.4.5 of this specification. The server MUST respond with a RopSynchronizationImportDeletes ROP response, as specified in [MS-OXCROPS] section 2.2.13.5.2 and section 2.2.3.2.4.5 of this specification.

The server MUST ignore requests to delete objects that have already been deleted and SHOULD record deletions of objects that never existed in the server replica, in order to prevent the RopSynchronizationImportHierarchyChange (section 2.2.3.2.4.3) or RopSynchronizationImportMessageChange (section 2.2.3.2.4.2) ROPs from restoring them back.

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 deletions will succeed. And, if a deletion will not succeed, the server SHOULD fail the ROP before performing any deletions, as opposed to partially completing the ROP.

Servers SHOULD fail the ROP if unknown ImportDeleteFlags flag bits are set.