3.3.5.9.1 Receiving a RopFastTransferSourceGetBuffer ROP Response

The FastTransfer stream on download is read-only and non-seekable, and is usually generated by the server when requested by the client. Once it is obtained, data cannot be requeried, unless the operation is reconfigured from the beginning. Even then, there is no guarantee that the content of the stream will be the same as during the previous attempt.

As streams can be very large, clients SHOULD decode portions of the FastTransfer stream as they arrive in the RopFastTransferSourceGetBuffer ROP response buffers.

Clients that have not performed version detection on the server and have leveraged the server's flexibility to ignore unknown flags in the SynchronizationExtraFlags field of the RopSynchronizationConfigure ROP ([MS-OXCROPS] section 2.2.13.1) MUST parse the FastTransfer stream to detect whether the server honored each of the requested behavior flags. This enables the client to request behavior from an older server that does not support newer behaviors without having to strictly check the version of the server.

If the client receives a value of 0x00000480 in the ReturnValue field, the client SHOULD<50> wait at least the period of time specified in BackoffTime before retrying the ROP. The complete list of error codes is specified in [MS-OXCDATA] section 2.4.

If a cancellation occurs on a download and there is any data left unprocessed from the result of the  RopFastTransferSourceGetBuffer ROP ([MS-OXCROPS] section 2.2.12.4), the client SHOULD NOT update the ICS state by using the RopSynchronizationGetTransferState ROP ([MS-OXCROPS] section 2.2.13.8). This is because the server does not know if the client successfully committed all items. It is possible to miss items if the RopSynchronizationGetTransferState ROP is used at a time when synchronization buffers are only partially processed.