Share via

3.3.5.8.10 Sending a RopSynchronizationImportDeletes ROP Request

  • Article

Clients SHOULD update the ICS state of the chosen synchronization scope by removing internal identifiers of deleted objects from its MetaTagIdsetGiven property (section 2.2.1.1.1). Otherwise, the client will receive deletion notifications for these messages during the next ICS download.

Clients SHOULD expect this ROP to fail if deletion of any of the objects passed in the request buffer fails, except for the common cases specified in section 2.2.3.2.4.5. The possibility of a failure is higher when the user has lower privileges to a mailbox—this is especially a consideration for delegate and public folder access. It is recommended that clients that use this ROP have a strategy to retry this operation, which can be a combination of the following steps:

  1. Retry the ROP with the same arguments on a new synchronization upload context.

  2. Retry the ROP, passing one ID at a time.

  3. Retry the ROP by using online mode ROPs, such as RopDeleteFolder and RopDeleteMessages, as specified in [MS-OXCFOLD] section 2.2.1.3 and 2.2.1.11, respectively.

  4. Perform the ICS download, resolving server changes against their own pending synchronization upload context.

  5. Skip an object and undo the operation in the local replica.