none
[MS-OXCFXICS] Queries on Fast Transfer RRS feed

  • Question

  • This is a bit of a mixed set of questions and comments on MS-OXCFXICS v20010729.

    Q1. For fast transfer that is being conducted as server-client-server, I'd like more information to enable interoperability where one of the servers is Exchange, and the other server is my implementation.

    Q1a. Consider a scenario where the source is Exchange, the client is Outlook, and the destination server is my (not-Exchange) server. If the client sends RopTellVersion to my server, what is the intended effect of RopTellVersion on the destination server? In particular, how do various Version[3] values change the interpretation of the fast transfer stream (as provided by RopFastTransferDestinationPutBuffer)?

    Q1b. Consider a scenario where the source is my ()not-Exchange), the client is Outlook, and the destination server is my (not-Exchange) server. If the client sends RopTellVersion,What is the effect of RopTellVersion on the source server? In particular, how do various Version[3] values change the subsequent format of the fast transfer stream (from RopFastTransferSourceGetBuffer)?

    Q2. What happens if RopTellVersion is sent after the first RopTransferSourceGetBuffer / RopTransferDestinationPutBuffer has been sent on the fast transfer context? Does this have any effect on those transfers? Should an error occur?

    Q3. For RopFastTransferDestinationPutBuffer (Section 2.2.3.1.2.2), is there a preferred value for TransferStatus? Is it safe to always send 0x0000?

    Q4. What are the minimum propertyelements required (for interoperability) to be included in the fast transfer stream for transfer of:

    a. Folder / Folder hierachy

    b. Message / embedded message

    c. Attachment

    Q5. Section 2.2.3.1.2.2. specifies that TransferDataSize must be greater than zero, but does not restrict the maximum size. What is the maximum (from the client side) supported buffer size for RopFastTransferDestinationPutBuffer? [Alternatively, what is the minimum required buffer size for the server implementation].

    Comment 1: Section 2.2 uses the words "non-italicized rows", however it appears that this is only used in 2.2.4, and there are no italicized rows (although there are some rows that contain italicized cells), and some rows don't have the same italicization as equivalent rows in other tables (e.g. compare 2.2.4.3.15 and 2.2.4.3.16). It might be worth another look, and perhaps explain this to Section 2.2.4 introduction.

    Comment 2: Sections 2.2.4.1 and 2.2.4.2 use the words "Camel-cased" and "Pascal-cased" in a way I didn't recognise. I had to search the web and read blog posts to figure it out - it seems to be something from the .NET framework. I would have assumed both fooBar and FooBar are camel-cased name. It might be better to explain what the convention is in terms of upper and lower case characters.

    Monday, October 11, 2010 1:18 AM

Answers

  • Tom.

    This part of the query is resolved, but the description of the transfer format (Q1a/b in my original post) is still outstanding.

    Brad

     


    Brad, as I mentioned in my post on November 5th, I filed a request to have this information added to the document. It should be included in the future.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, December 6, 2010 5:27 PM
    Moderator

All replies

  • Hi Brad,

     

    Thank you for your post.  Someone from the Protocols team will follow-up with you.

     

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Monday, October 11, 2010 5:27 PM
    Moderator
  • Brad, I will be researching a few of your questions. There may be responses from other Engineers as well.

     

    Regarding question 1, there are tables in MS-OXCRPC Section 3.1.9.2 and Section 3.1.9.3 that describe the differences between the client and server behavior for different Version[3] values. I believe that should answer your question. Please let me know if it does not.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, October 14, 2010 2:59 PM
    Moderator
  • Josh,

    That doesn't deal with the differences in the FastTransfer stream format that can potentially occur when you have the ForUpload flag set in the SendOptions field of RopFastTransferSource*.

    I've posted a more detailed description to dochelp mail, since I think this one is going to be quite messy.

    Brad

    Friday, October 15, 2010 4:31 AM
  • Brad, in regards to question 4, the answers are spread throughout the document. Section 2.2 states that…

     

    Section 2.2.1 through section 2.2.4.4 use property list restriction tables in the following format to describe restrictions on arrays of property values:

     

    As an example, if we look at section 2.2.4.3.6, you can see in the table that the PidTagFolderId, PidTagDisplayName, and PidTagComment properties are required for the folderContent element and all others are optional.

     

    You will need to look at each element individually to see what is required, prohibited, optional, and what conditional requirements exist.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Friday, October 15, 2010 4:14 PM
    Moderator
  • Brad, in regards to Comment 1, I see what you mean about the inconsistent use of italicization across the propList tables in section 2.2.4. I will file a request to have those tables reviewed and updated.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Friday, October 15, 2010 7:05 PM
    Moderator
  • Brad, regarding question 2, sending RopTellVersion after the first RopFastTransferSourceGetBuffer / RopFastTransferDestinationPutBuffer has been sent on the fast transfer context is a violation of the protocol, which means that the behavior falls outside of the scope of the protocol and is undefined. In pre-Exchange 2010 you might get stream behavior that changes mid-stream which isn’t a good idea.

     

    I've submitted a request to have the documented updated to make this clear.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, October 25, 2010 4:06 PM
    Moderator
  • Josh,

    Thanks for this.

    Brad

    Monday, October 25, 2010 7:50 PM
  • Brad,

    regarding Comment #2: Sections 2.2.4.1 and 2.2.4.2 use the words "Camel-cased" and "Pascal-cased"...

    I've verified that camel-cased is mixed, for example fooBar and pascal-cased is similar but with the first letter always capitalized like FooBar.  We will be adding a glossary entry for each and including a link to http://msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx where the two forms are described. 

    And regarding Q5: Section 2.2.3.1.2.2. specifies that TransferDataSize must be greater than zero, but does not restrict the maximum size. ...

    The maximum value of TransferDataSizes is the maximum amount of data the client can place into the ROP request buffer where the request is valid.  The server will accept the largest size possible as long as the request is formatted properly.

     

    And finally, regarding Q3:

    Q3. For RopFastTransferDestinationPutBuffer (Section 2.2.3.1.2.2), is there a preferred value for TransferStatus? Is it safe to always send 0x0000?

    Since section 2.2.3.1.2.2 states that the field MUST be ignore:

     

    “TransferStatus (2 bytes): A 16-bit enumeration. Clients MUST ignore the value of this field.”

     

    Then it doesn’t matter what value is in this field.  0x0000 is acceptable. 

     

    Do these answer your questions?

     

    Best regards,

    Tom Jebo

    Escalation Engineer

    Microsoft Open Specifications

     

    Thursday, October 28, 2010 4:42 PM
  • Tom,

    Thanks for the response. That resolves Q3 and Comment 2.

    I'd like to take another look at the response for Q5. I think there is something missing (perhaps a definition or reference for "largest size possible"), but I'd like to think this through a bit first.


    Brad

    Friday, October 29, 2010 11:12 AM
  • Ok Brad, I've just pinged the doc writer to see if we can get a more precise definition. 

    Tom

    Friday, October 29, 2010 3:30 PM
  • Brad,

    Here’s a more precise definition:

    The rgbIn request buffer size of EcDoRpcExt2 has a maximum size of 32775 bytes.  8 bytes is the RPC_HEADER_EXT which leaves 32767 bytes for ROP payload.  The ROP payload must contain the 2 byte ROP length field prefix and the Server Object Handle table as a postfix in the buffer.  The minimum Server Object Handle table would contain a single Server Object Handle which is 4 bytes.  This means there is 6 bytes of minimum overhead which means the maximum size for the ROP would be 32761.  The ROP itself has some overhead of 4 bytes, so the absolute maximum for TransferDataSize is 32757.

    We will not add this detail to MS-OXCFXICS because a) all of this would be derived from understanding the EcDoRpcExt2() method and b) if any of the dependent values were to change, the maximum value of TransferDataSize would also need to be updated in this document.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Thursday, November 4, 2010 6:59 PM
  • Tom,

    Thanks for this. I think it would be sufficient to say that the maximum size is limited by the available space in the underlying transport (i.e. EcDoRpcExt2).

    Brad

     

    Friday, November 5, 2010 1:27 AM
  • Brad, regarding question 1, you are correct. Additional documentation is necessary to be able to parse the fast transfer stream in a scenario where one of the servers is a 3rd party implementation of the Exchange Server protocols. A request has been filed to have that information added to the MS-OXCFXICS document and should be included in a future release.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Friday, November 5, 2010 7:08 PM
    Moderator
  • Brad,

    I'll submit the request to have a short sentence to this effect added to the TransferDataSize description.

    Tom

    • Marked as answer by Tom Jebo MSFT Wednesday, December 1, 2010 6:52 PM
    • Unmarked as answer by Brad Hards Wednesday, December 1, 2010 7:47 PM
    Thursday, November 11, 2010 8:13 PM
  • Tom.

    This part of the query is resolved, but the description of the transfer format (Q1a/b in my original post) is still outstanding.

    Brad

     

    Wednesday, December 1, 2010 7:49 PM
  • Tom.

    This part of the query is resolved, but the description of the transfer format (Q1a/b in my original post) is still outstanding.

    Brad

     


    Brad, as I mentioned in my post on November 5th, I filed a request to have this information added to the document. It should be included in the future.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, December 6, 2010 5:27 PM
    Moderator