none
Revision Manifest Root and content streams RRS feed

  • Question

  • MS-FSSHTTPD 2.3 says:

    The revision manifest data element, as specified in [MS-FSSHTTPB] section 2.2.1.12.5, MUST have a Root Extended GUID field set to an extended GUID 5-bit Uint value that represents the primary content stream, as shown in the following table.

    ...

    If other streams are present, additional roots MUST be specified by the protocol client and are opaque to this protocol. For each stream, a single Intermediate Node MUST be specified by using a unique root identifier.

    I wasn't able to figure out what does term "content stream" means exactly, but when looking into conversation between MS Word and genuine Sharepoint server, I noticed that server response for client which opens .docx file first time contains two Revision Manifest Root Declare elements (I couldn't insert screenshot as my account needs verification, but can provide it any time via email or another communication channel). 

    One of those elements points to Intermediate Node Object, as described in spec, but another one points to Leaf Node Object with data I cannot find anywhere in .docx file. So, is there some explanation of content streams and related data structures?


    Wednesday, May 23, 2018 1:00 PM

Answers

  • Hi Kirill, 

    This information is specific to presence and coauthoring. Therefore it is transferred via FSSHTTP* protocols and related to cells during transfer as these are used for coauthoring by the Office clients. 

    Tom

    Tuesday, June 5, 2018 9:34 PM
    Moderator

All replies

  • Hi Kirill,

    Thank you for your question about the meaning of the content stream in MS-FSSHTTPD 2.3. I will work with you to clarify this and get back to you soon with an explanation.


    Best regards,
    Tom Jebo 
    Sr Escalation Engineer
    Microsoft Open Specifications Support

    Wednesday, May 23, 2018 3:30 PM
    Moderator
  • Kirill, 

    Can you please send the screen shot and Fiddler capture if you have it, to dochelp@microsoft.com, referencing the URL for this thread and my name?

    Thanks,

    Tom

    Wednesday, May 23, 2018 3:49 PM
    Moderator
  • Tom, 

    Thanks for quick response, I have emailed information you requested.

    Wednesday, May 23, 2018 4:05 PM
  • Thank you Kirill. I've received it and will investigate. 

    Tom

    Thursday, May 24, 2018 1:24 AM
    Moderator
  • Hi

    I looked deeper into that unknown data element, it deflated as following XML:

    <CoAuthoringLocks xmlns="http://schemas.microsoft.com/word/2009/7/coauthoring"><DeletedLocks xmlns=""><LockId Val="0B237A33" TimeStamp="2018-04-17T14:33:18Z"/><LockId Val="3AC27A64" TimeStamp="2018-04-17T14:40:00Z"/><LockId Val="29B9F3A6" TimeStamp="2018-04-17T14:32:20Z"/></DeletedLocks></CoAuthoringLocks>

    It's quite strange to see some locks info as part of file content data package. Is there some additional spec that describes this? Also XML schema mentioned in data above seems doesn't exist.

    edit: it's probably MS-WORDLFF specification ( https://msdn.microsoft.com/en-us/library/dd911015(v=office.12).aspx ) however question about "content stream" still stands.
    Monday, June 4, 2018 3:15 PM
  • Hi Kirill, 

    Yes, as you've already found, these "content streams" can be but are not limited to secondary metadata like the one listed in [MS-WORDLFF]. As [MS-FSSHTTPD] 2.3 states, these secondary streams are to be considered opaque to the protocol (FSSHTTPB and D) and specific to the applications using them.

    Tom

    Monday, June 4, 2018 6:22 PM
    Moderator
  • Hi

    Actually I would like to know if this MS-WORDLFF specific data is transferred from MS Word client via MS-FSSHTTPD or there is another way? I ask because MS Word behaves different with Fiddler on and off.

    Monday, June 4, 2018 7:04 PM
  • Hi Kirill, 

    This information is specific to presence and coauthoring. Therefore it is transferred via FSSHTTP* protocols and related to cells during transfer as these are used for coauthoring by the Office clients. 

    Tom

    Tuesday, June 5, 2018 9:34 PM
    Moderator