none
[MS-OXOCAL] ExceptionInfo structure AppointmentColor field RRS feed

  • Question

  • In [MS-OXOCAL] Revision 11.0 dated 04/30/2014, in section 2.2.1.44.2, the ExceptionInfo structure is desribed.

    In the description of the OverrideFlags field, a bit is defined for ARO_APPTCOLOR:

    ARO_APPTCOLOR
    0x0100
    Reserved for future use and MUST NOT be set.

    Further down in the section, it describes the AppointmentColor field as:

    AppointmentColor (4 bytes): This field is reserved and MUST NOT be read from or written to.

    When I first read this, I took it to mean that the field is always part of the ExceptionInfo structure, and the data in the field should not be used.  In otherwords, reader programs should skip over the 4 bytes for this field.

    However, I suspect that this filed is only present if the ARO_APPTCOLOR bit in OverrideFlags is set (and according to the description of OverrideFlags, this bit should not be set at the current time).

    I think the specification would be more clear if the description for AppointmentColor were as follows:

    AppointmentColor* (4bytes): this field is reserved and MUST NOT be read or written to. *This field is present only when the ARO_APPTCOLOR flag is set in the OverrideFlags field.


    • Edited by fpavelski Friday, July 11, 2014 2:40 PM
    Friday, July 11, 2014 2:39 PM

Answers

  • Hi fpavelski, I have verified that the description of the ARO_APPTCOLOR flag and the AppointmentColor field is incorrect. If the ARO_APPTCOLOR flag is not set the AppointmentColor field will NOT be present in the stream. Thank you for bringing this to our attention. I have filed a request to have the descriptions corrected.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Wednesday, July 23, 2014 8:25 PM
    Moderator

All replies

  • Hi fpavelski,

    Thank you for your question. A member of the Protocol Documentation support team will respond to you soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Friday, July 11, 2014 6:57 PM
  • Hi fpavelski, I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Friday, July 11, 2014 8:08 PM
    Moderator
  • Hi fpavelski, the descriptions of the flags in the OverrideFlags field state whether or not other fields will be present or not. Those fields reinforce this by stating which flag indicates their presence.

    As you've noticed, the ARO_APPTCOLOR flag does not mention that it indicates the presence of the AppointmentColor field. Nor does the description of the AppointmentColor field mention whether or not is will be present based on the ARO_APPTCOLOR flag.

    The documentation seems pretty clear on this. Do you have an example that contradicts what is documented?

    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Monday, July 14, 2014 9:09 PM
    Moderator
  • Thanks Josh for responding.

    I will pull together an example stream of data as soon as possible.

    However, as a point of clarification... would you say that the 4 bytes used for the AppointmentColor are always included within an ExceptionInfo structure?

    If the answer is "yes, they are always there".. then perhaps I have a bug in my code.

    If the answer is "no, they are never there".. then the spec seems a little confusing.

    If the answer is "sometimes they are, and sometimes they are not".. then how does one determine this?

    For my work, the value of the AppointmentColor field is not important.  But I do need to know whether the bytes for that field are in the ExceptionInfo structure or not.

    Monday, July 14, 2014 10:58 PM
  • Hello Josh,

    Here is an example stream of data retrieved from the PidLidAppointmentRecur property.

    043004300A200000000000000000A0050000000000002220000005000000000000000100000060BAF60C0100000060BAF60C60BAF60CE0D0F60C0630000009300000FC0300001A04000001005CBEF60C7ABEF60C5CBEF60C09005E005D004E4557205355424A454354204461696C7920526570656174696E67204D656574696E6720776974682035206F6363757272656E6365732E204F6E6520696E7374616E636520686173206120646966666572656E74207375626A6563742E00000000000000000400000000000000000000005CBEF60C7ABEF60C5CBEF60C5D004E004500570020005300550042004A0045004300540020004400610069006C007900200052006500700065006100740069006E00670020004D0065006500740069006E006700200077006900740068002000350020006F006300630075007200720065006E006300650073002E0020004F006E006500200069006E007300740061006E0063006500200068006100730020006100200064006900660066006500720065006E00740020007300750062006A006500630074002E000000000000000000

    I'm using mfcmapi.exe to obtain the above data.

    Below is the "Smart View" of the data.

    The SmartView does not indicate the presence of the AppointmentColor field.

    Recurrence Pattern: 
    ReaderVersion: 0x3004
    WriterVersion: 0x3004
    RecurFrequency: 0x200A = IDC_RCEV_PAT_ORB_DAILY
    PatternType: 0x0000 = rptMinute
    CalendarType: 0x0000 = CAL_DEFAULT
    FirstDateTime: 0x00000000 = 0
    Period: 0x000005A0 = 1440
    SlidingFlag: 0x00000000
    EndType: 0x00002022 = IDC_RCEV_PAT_ERB_AFTERNOCCUR
    OccurrenceCount: 0x00000005 = 5
    FirstDOW: 0x00000000 = Sunday
    DeletedInstanceCount: 0x00000001 = 1
    DeletedInstanceDates[0]: 0x0CF6BA60 = 12:00:00.000 AM 7/14/2014
    ModifiedInstanceCount: 0x00000001 = 1
    ModifiedInstanceDates[0]: 0x0CF6BA60 = 12:00:00.000 AM 7/14/2014
    StartDate: 0x0CF6BA60 = 217496160 = 12:00:00.000 AM 7/14/2014
    EndDate: 0x0CF6D0E0 = 217501920 = 12:00:00.000 AM 7/18/2014
    Appointment Recurrence Pattern: 
    ReaderVersion2: 0x00003006
    WriterVersion2: 0x00003009
    StartTimeOffset: 0x000003FC = 1020 = 05:00:00.000 PM 1/1/1601
    EndTimeOffset: 0x0000041A = 1050 = 05:30:00.000 PM 1/1/1601
    ExceptionCount: 0x0001
    ExceptionInfo[0].StartDateTime: 0x0CF6BE5C = 05:00:00.000 PM 7/14/2014
    ExceptionInfo[0].EndDateTime: 0x0CF6BE7A = 05:30:00.000 PM 7/14/2014
    ExceptionInfo[0].OriginalStartDate: 0x0CF6BE5C = 05:00:00.000 PM 7/14/2014
    ExceptionInfo[0].OverrideFlags: 0x0009 = ARO_SUBJECT | ARO_REMINDER
    ExceptionInfo[0].SubjectLength: 0x005E = 94
    ExceptionInfo[0].SubjectLength2: 0x005D = 93
    ExceptionInfo[0].Subject: "NEW SUBJECT Daily Repeating Meeting with 5 occurrences. One instance has a different subject."
    ExceptionInfo[0].ReminderSet: 0x00000000
    ReservedBlock1Size: 0x00000000
    ExtendedException[0].ChangeHighlight.ChangeHighlightSize: 0x00000004
    ExtendedException[0].ChangeHighlight.ChangeHighlightValue: 0x00000000 = 0x0
    ExtendedException[0].ReservedBlockEE1Size: 0x00000000
    ExtendedException[0].StartDateTime: 0x0CF6BE5C = 05:00:00.000 PM 7/14/2014
    ExtendedException[0].EndDateTime: 0x0CF6BE7A = 05:30:00.000 PM 7/14/2014
    ExtendedException[0].OriginalStartDate: 0x0CF6BE5C = 05:00:00.000 PM 7/14/2014
    ExtendedException[0].WideCharSubjectLength: 0x0000005D = 93
    ExtendedException[0].WideCharSubject: "NEW SUBJECT Daily Repeating Meeting with 5 occurrences. One instance has a different subject."
    ExtendedException[0].ReservedBlockEE1Size: 0x00000000
    ReservedBlock2Size: 0x00000000

    Monday, July 14, 2014 11:14 PM
  • Hi fpavelski, thank you for providing an example. I have reviewed it and I definitely see something where either there is an issue with the documentation or the output from MFC MAPI.  I will continue to look into this and let you know when I have more information.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Tuesday, July 15, 2014 6:35 PM
    Moderator
  • Hi fpavelski, I have verified that the description of the ARO_APPTCOLOR flag and the AppointmentColor field is incorrect. If the ARO_APPTCOLOR flag is not set the AppointmentColor field will NOT be present in the stream. Thank you for bringing this to our attention. I have filed a request to have the descriptions corrected.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Wednesday, July 23, 2014 8:25 PM
    Moderator
  • Thanks Josh for responding.

    Monday, July 28, 2014 4:24 PM