Share via

3.2.5.9.4.2 Receiving a RopSynchronizationImportMessageChange ROP Request

  • Article

When the client sends the server a RopSynchronizationImportMessageChange ROP (section 2.2.3.2.4.2) request, the server MUST parse the request, as specified in [MS-OXCROPS] section 2.2.13.2.1 and section 2.2.3.2.4.2 of this specification. The server MUST respond with a RopSynchronizationImportMessageChange ROP response, as specified in [MS-OXCROPS] section 2.2.13.2.2 or 2.2.13.2.3, and in section 2.2.3.2.4.2 of this specification.

When the server receives a RopSynchronizationImportMessageChange ROP request, the server MUST perform conflict detection on the message, as specified in section 3.1.5.6. The server becomes responsible for performing conflict resolution on the RopSaveChangesMessage ROP ([MS-OXCROPS] section 2.2.6.3), as specified in section 3.1.5.6.2.

The server MUST purge all client-settable properties and subobjects of the Message object prior to returning it in the OutputServerObject. Note that any changes to this message made by this ROP or any other ROP that operates on it MUST NOT be persisted until RopSaveChangesMessage ROP is called.

ImportFlag Constraints

If the FailOnConflict flag of the ImportFlag field is set, the server MUST NOT accept conflicting versions of messages.

If the FailOnConflict flag of the ImportFlag field is not set, the server MUST accept conflicting versions of messages.

Servers SHOULD<44> fail the ROP if unknown flags are set.