none
RPC MAPI compression algorithm question RRS feed

  • Question

  • Hi,

    I am trying to troubleshoot the problem with communication between Outlook client and Exchange server. For that reason I am decoding the EcDoRpcExt2 compressed response from the (Exchange 2010) server. I feel uncertain whether I understand correctly the compression algorithm as described in MS-OXCRPC specification. My concern is related to the metadata offset - match length as specified in section 3.1.7.2.2.4 of the v20101026 version of the document. This states that in case of the match length greater than 9, another (3rd) byte is added and if the nibble (any?) of the shared byte is all ones, another (4th) byte is added. My example shows metadata bytes as follows (in hex): ... 00 27 F5 00 ... The F5 byte is clearly 3rd "shared" added byte as the low order bits of the 2nd byte are all ones. But assuming we are using the "5" nibble now for the length extension do we need to count another byte (00) as metadata length extension as there is "F" nibble present in the shared byte and this is all ones, or shall I take this byte (00) as normal data?

    Thanks & regards,

    Antonin    

    Thursday, May 26, 2011 7:50 AM

Answers