none
[MS-OXCDATA] SearchMessageModifiedNotification RRS feed

  • Question

  • MS-OXCDATA (v1.03) "Data Structures Protocol Specification", Section 2.6.3.3 "SearchMessageModifiedNotification" contains the following:

    NotificationType (2 bytes): Unsigned 16-bit integer. This value indicates the type of notification and MUST be set to "0xC010" by the server.

    FID (8 bytes): FID structure. The value identifies the folder the message is actually stored in.

    MID (8 bytes): MID structure. The value identifies the message.

    SearchFID (8 bytes): FID structure. The value identifies the search folder the message is in.

    TagCount (2 bytes): Unsigned 16-bit integer. When it has the value "0xFFFF", the Tags field is not present. Otherwise, it indicates how many PropertyTag elements are present in Tags.

    Tags (variable): Array of PropertyTag structures. This field MUST contain TagCount structures. This field gives a list of properties that were initially set or updated on the message.


    However based on some initial investigation, it appears not all of those values are present under all conditions. In particular, SearchFID is not sent by Exchange 2007 SP1.

    Further investigation shows that MS-OXCNOTIF (v1.04) "Core Notifications Protocol Specification", 2.2.1.4.1 RopNotify contains a table that partly matches up with these fields.

    FID in MS-OXCDATA is probably FolderID in MS-OXCNOTIF, and it says:
    "Folder ID of the item triggering the event. This field is available only if the NotificationType value in NotificationFlags is not 0x0100, 0x0200, or 0x0400. "
    From this, I conclude that FID will always be present for the SearchMessageModifiedNotification (0xC010).

    Similarly, MID in MS-OXCDATA is probably MessageID in MS-OXCNOTIF, and it says:
    "Message ID of the item triggering the event. This field is available only if the NotificationType value in NotificationFlags is not 0x0100, 0x0200, or 0x0400, and bit 0x8000 is set in NotificationFlags. "
    From this, I conclude that MID will always be present for the SearchMessageModifiedNotification (0xC010).

    It gets a bit messier at SearchFID. The most likely case looks like ParentFolderID, which says:
    "Folder ID of the parent folder of the item triggering the event. This field is available only if the NotificationType value in NotificationFlags is 0x0004, 0x0008, 0x0020, or 0x0040 and bit 0x4000 and bit 0x8000 are set or bit 0x4000 and bit 0x8000 are not set in NotificationFlags. "
    I'm not sure I'm parsing the sentence correctly, but if a notification type of 0xC010 doesn't ever match this case, then why does SearchFID appear in MS-OXCDATA Section 2.6.3.3?

    The main thing to understand is when those 8 bytes for SearchFID will appear, and when they won't. This is currently breaking our notification handling.

    As a secondary issue, it would help if MS-OXCDATA and MS-OXCNOTIF used the same terminology for each field.

    Brad
    Wednesday, April 15, 2009 4:23 AM

Answers

  • You are correct that there is no SearchFID field and your proposed structure is correct for 0xC010. 


    Developer Consultant
    • Marked as answer by Brad Hards Friday, April 17, 2009 6:27 AM
    Friday, April 17, 2009 4:47 AM
    Moderator

All replies

  • Brad,

    I have emailed the development team in regards to your question and feedback.


    Developer Consultant
    Wednesday, April 15, 2009 4:15 PM
    Moderator
  • Brad, 

    The discussions I had with development is really more of a question around the details in [MS-OXCNOTIF].  [MS-OXCDATA] really only specifies the structure so it does not specify when it is used or how it is used.

     

    The question from what I understand is when does the SearchFID field appear.  There maybe some confusion between the structures in [MS-OXCDATA] and how [MS-OXCNOTIF] specifies what fields are available.

    Do you have a sample of the response buffer that could help give me some more context?


    Developer Consultant
    Wednesday, April 15, 2009 9:40 PM
    Moderator
  • Tom,

    Thanks for following this up.

    MS-OXCDATA is important in that it specifies the order of the fields in the structure, but the meaning of the fields (with different names) is certainly in MS-OXCNOTIF.

    In IDL terms, we currently have:
            /* SearchMessageModifiedNotification: 0xc010 */
            typedef [flag(NDR_NOALIGN)] struct {
                    hyper                                   FID;
                    hyper                                   MID;
                    hyper                                   SearchFID;
                    uint16                                  TagCount;
                    MAPITAGS                          Tags[TagCount];
            } SearchMessageModifiedNotification;

    That doesn't work correctly with E2K7. So we're considering using:
            /* SearchMessageModifiedNotification: 0xc010 */
            typedef [flag(NDR_NOALIGN)] struct {
                    hyper                                   FID;
                    hyper                                   MID;
                    uint16                                  TagCount;
                    MAPITAGS                          Tags[TagCount];
            } SearchMessageModifiedNotification;

    That appears to work. The concern is whether the SearchFID ever appears with NotificationType == 0xc010. If it does, I need to understand the conditions under which it does, so I can encode the handling of this correctly.

    I'll try to get you a packet capture to show what we are seeing.

    Brad
    Wednesday, April 15, 2009 10:18 PM
  • You are correct that there is no SearchFID field and your proposed structure is correct for 0xC010. 


    Developer Consultant
    • Marked as answer by Brad Hards Friday, April 17, 2009 6:27 AM
    Friday, April 17, 2009 4:47 AM
    Moderator
  • Tom,

    Thanks once again.

    Brad
    Friday, April 17, 2009 6:27 AM