none
[MS-OXOSFLD] - Is the ELEMENT_SENTINEL ElementID ever used? RRS feed

  • Question

  • After considerable scrutiny of the protocol doc governing special folders, I have been able to mostly decompose the binary blob contained in the PR_ADDITIONAL_REN_ENTRYIDS_EX property. However, the blob does not seem to adhere to the specs laid out in the protocol - namely, the ELEMENT_SENTINEL ElementID is not used to terminate the array of PersistElement items.

    Is the ELEMENT_SENTINEL ElementID ever used, or should one simply continue to read PersistElements from the DataElements array until you have exhausted the byte count contained in DataElementsSize? Should the DataElements be regarded as the 'stream' in the line '...and continue processing further PersistElement blocks until an ELEMENT_SENTINEL ElementID or the end of the stream is encountered.' (MS_OXOFLD.pdf, p. 16), and the DataElementsSize the size of the stream?

    I am hoping that I am simply making a mistake in my decomposition, but have been unable to figure out what I am doing wrong. The following is my attempt at decomposing the binary blob.

    Pulled off of the Inbox folder using MFCMapi with an Online-Mode profile.

    Original Binary Blob
    =========================
    0180320001002E0000000000F192AF2CF4253F49BDC28932B9DB89D401001C43399D4E3292448C6A209C24847E170000035A81B400000480320001002E0000000000F192AF2CF4253F49BDC28932B9DB89D401001C43399D4E3292448C6A209C24847E170000035A81B500000280320001002E0000000000F192AF2CF4253F49BDC28932B9DB89D401001C43399D4E3292448C6A209C24847E170000035AE684000000000000

    Decomposed Binary Blob
    =========================
    0180 - PersistID [Little Endian] {RSF_PID_RSS_SUBSCRIPTION}
    3200 - DataElementsSize [Little Endian] {0d50}
    0100 - ElementID [Little Endian] {RSF_ELID_ENTRYID}
    2E00 - ElementDataSize [Little Endian] {0d46}
    00000000F192AF2CF4253F49BDC28932B9DB89D401001C43399D4E3292448C6A209C24847E170000035A81B40000 - ElementData [Little Endian] {RSS Feeds EntryID}
    MISSING - ElementID {ELEMENT_SENTINEL}
    0480 - PersistID [Little Endian] {RSF_PID_TODO_SEARCH}
    3200 - DataElementsSize [Little Endian] {0d50}
    0100 - ElementID [Little Endian] {RSF_ELID_ENTRYID}
    2E00 - ElementDataSize [Little Endian] {0d46}
    00000000F192AF2CF4253F49BDC28932B9DB89D401001C43399D4E3292448C6A209C24847E170000035A81B50000 - ElementData [Little Endian] {TODO Search EntryID}
    MISSING - ElementID {ELEMENT_SENTINEL}
    0280 - PersistID [Little Endian] {RSF_PID_SEND_AND_TRACK}
    3200 - DataElementsSize [Little Endian] {0d50}
    0100 - ElementID [Little Endian] {RSF_ELID_ENTRYID}
    2E00 - ElementDataSize [Little Endian] {0d46}
    00000000F192AF2CF4253F49BDC28932B9DB89D401001C43399D4E3292448C6A209C24847E170000035AE6840000 - ElementData [Little Endian] {Tracked Mail EntryID}
    0000 - ElementID {ELEMENT_SENTINEL - Not included in bytecount of previous DataElementsSize???}
    0000 - PersistID [Little Endian] {PERSIST_SENTINEL}
    Monday, September 29, 2008 3:30 PM

Answers

  • Scott,

    In section 2.2.3.1.1 PersistData Block states that

    "PersistBlockType values SHOULD be one of those listed in the following table. If a PersistData block is encountered where the PersistID value is not known to the implementation, the implementation MUST ignore that PersistData block and continue processing until either a PERSIST_SENTINEL PersistID or the end of the stream is encountered."

    PERSIST_SETINEL(0x0000) is optional as you have discovered.

    The format for this binary stream property should follow:

    [WORD, PersistID] [WORD DataElementsSize]
         [WORD, ElementID] [WORD ElementDataSize] [0...n bytes of ElementData]
         [WORD, ElementID] [WORD ElementDataSize] [0...n bytes of ElementData]
         ....
         [WORD, PERSIST_SETINEL] <--- optional terminal value
     ....
     [WORD, PERSIST_SETINEL] <---- optional terminal value

    Maybe adding some clarification noting that this is optional.


    Developer Consultant
    Monday, September 29, 2008 6:20 PM
    Moderator
  • ScottH_001 said:

    Ah, the fun continues.

    Since the documentation on the PidTagAdditionalRenEntryIdsEx property continually has references to reading to the end of the stream, I made the assumption (and I'm sure you have heard the saying about assumptions) that you could open the property using the IMAPIProp::Openproperty method, passing in the IStream interface.

    Bad assumption.

    It turns out, the interface is not supported. So, if you can't pull a stream directly from the property, how the heck are you supposed to get a stream at all - create a binary buffer from the contents of the property and use it to populate a stream object you create yourself? There has got to be a better way, but there is NOTHING in the documentation describing this hoped-for better way.

      Is there anyone who knows how to correctly handle this property?

    Scott, 
     
    For question above using MAPI to interact with this property you should post your question to the Microsoft-sponsored MAPI newsgroup microsoft.public.win32.programmer.messaging.




    Developer Consultant
    Monday, September 29, 2008 6:54 PM
    Moderator

All replies

  • Ah, the fun continues.

    Since the documentation on the PidTagAdditionalRenEntryIdsEx property continually has references to reading to the end of the stream, I made the assumption (and I'm sure you have heard the saying about assumptions) that you could open the property using the IMAPIProp::Openproperty method, passing in the IStream interface.

    Bad assumption.

    It turns out, the interface is not supported. So, if you can't pull a stream directly from the property, how the heck are you supposed to get a stream at all - create a binary buffer from the contents of the property and use it to populate a stream object you create yourself? There has got to be a better way, but there is NOTHING in the documentation describing this hoped-for better way.

    Is there anyone who knows how to correctly handle this property?
    Monday, September 29, 2008 4:05 PM
  • Scott,
    Thanks for your post. We will review this and post a reply once our research is completed.

    Steve Smegner
    Application Development Consulting Group
    Monday, September 29, 2008 6:14 PM
  • Scott,

    In section 2.2.3.1.1 PersistData Block states that

    "PersistBlockType values SHOULD be one of those listed in the following table. If a PersistData block is encountered where the PersistID value is not known to the implementation, the implementation MUST ignore that PersistData block and continue processing until either a PERSIST_SENTINEL PersistID or the end of the stream is encountered."

    PERSIST_SETINEL(0x0000) is optional as you have discovered.

    The format for this binary stream property should follow:

    [WORD, PersistID] [WORD DataElementsSize]
         [WORD, ElementID] [WORD ElementDataSize] [0...n bytes of ElementData]
         [WORD, ElementID] [WORD ElementDataSize] [0...n bytes of ElementData]
         ....
         [WORD, PERSIST_SETINEL] <--- optional terminal value
     ....
     [WORD, PERSIST_SETINEL] <---- optional terminal value

    Maybe adding some clarification noting that this is optional.


    Developer Consultant
    Monday, September 29, 2008 6:20 PM
    Moderator
  • ScottH_001 said:

    Ah, the fun continues.

    Since the documentation on the PidTagAdditionalRenEntryIdsEx property continually has references to reading to the end of the stream, I made the assumption (and I'm sure you have heard the saying about assumptions) that you could open the property using the IMAPIProp::Openproperty method, passing in the IStream interface.

    Bad assumption.

    It turns out, the interface is not supported. So, if you can't pull a stream directly from the property, how the heck are you supposed to get a stream at all - create a binary buffer from the contents of the property and use it to populate a stream object you create yourself? There has got to be a better way, but there is NOTHING in the documentation describing this hoped-for better way.

      Is there anyone who knows how to correctly handle this property?

    Scott, 
     
    For question above using MAPI to interact with this property you should post your question to the Microsoft-sponsored MAPI newsgroup microsoft.public.win32.programmer.messaging.




    Developer Consultant
    Monday, September 29, 2008 6:54 PM
    Moderator