3.1.5 Message Processing Events and Sequencing Rules

With the exception of the RopProgress ROP ([MS-OXCROPS] section 2.2.8.13), all of the ROPs specified in section 2 of this specification are sent by the client and processed by the server. The client SHOULD process the ROP response buffer associated with each message it sends.

If the client set the WantAsynchronous field to nonzero in the ROP request buffer of any of the following ROPs, the server can respond with a RopProgress ROP response.

  • RopCopyTo ([MS-OXCROPS] section 2.2.8.12)

  • RopCopyProperties ([MS-OXCROPS] section 2.2.8.11)

  • RopSetReadFlags ([MS-OXCROPS] section 2.2.6.10)

  • RopMoveCopyMessages ([MS-OXCROPS] section 2.2.4.6)

  • RopMoveFolder ([MS-OXCROPS] section 2.2.4.7)

  • RopCopyFolder ([MS-OXCROPS] section 2.2.4.8)

  • RopHardDeleteMessagesAndSubfolders ([MS-OXCROPS] section 2.2.4.10)

  • RopEmptyFolder ([MS-OXCROPS] section 2.2.4.9)

  • RopDeleteMessages ([MS-OXCROPS] section 2.2.4.11)

  • RopHardDeleteMessages ([MS-OXCROPS] section 2.2.4.12)

The server can notify the client of its current progress by responding with a RopProgress ROP response buffer. When the client receives a RopProgress response, it can use the values of the CompletedTaskCount and TotalTaskCount fields to provide progress information to the user. The client can request additional status or abort the operation by sending additional RopProgress ROP requests. In response to the client's RopProgress ROP request, the server MUST respond with either the response to the original ROP or another RopProgress ROP response. If the client sends a ROP other than RopProgress to the server with the same logon before the asynchronous operation is complete, the server MUST abort the asynchronous operation and respond to the new ROP.

Show: