none
[MS-OXOCAL] AppointmentRecurrencePattern format and Outlook 2013/Exchange 2013 RRS feed

  • Question

  • Hi,

    According to MS-OXOCAL 2.2.1.44.1 and §2.2.1.44.5, an appointment weekly recurrence pattern should be an array of 82 bytes, but Outlook 2013 creates a binary stream of 84 bytes.

    Is there any explanation from this ?

    Regards,


    Désiré GOVIN Refresh IT Solutions

    Thursday, September 11, 2014 8:34 AM

Answers

  • Hello Désiré,

    I have not been able to reproduce what you're seeing from Outlook 2013 in my own testing. Here is the PidLidAppointmentRecur structure as processed by RPX when I create an appointment with a weekly recurrence:

    0x80750102  <Unknown>                             PtypBinary       80 Byte(s)
    	0000: 04 30 04 30 0B 20 01 00 00 00 C0 21 00 00 01 00 - .0.0. .....!....
    	0010: 00 00 00 00 00 00 08 00 00 00 23 20 00 00 0A 00 - ..........# ....
    	0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 - ...............(
    	0030: F8 0C DF 80 E9 5A 06 30 00 00 09 30 00 00 58 02 - .....Z.0...0..X.
    	0040: 00 00 76 02 00 00 00 00 00 00 00 00 00 00 00 00 - ..v.............
    

    This is 80 bytes as expected from the specification. Can you please provide a trace that demonstrates the extra bytes being sent?

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Wednesday, September 17, 2014 7:08 PM

All replies

  • Désiré,

    Thank you for your question.

    An engineer from the Protocols team will contact you soon


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, September 11, 2014 5:39 PM
    Moderator
  • Hello Désiré,

    I will be working on this question with you. I am currently researching the behavior and will follow up with an update for you soon. Thank you for your patience.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Thursday, September 11, 2014 6:09 PM
  • Hello Désiré,

    In my reading of the documentation in §2.2.1.44.1, §2.2.1.44.1.4, and §2.2.1.44.5, I'm calculating that the structure size for a weekly recurrence will be a minimum of 80 bytes. There are several optional elements that could result in a larger result. Would it be possible for you to provide a trace of what you're seeing? You can email it to my attention at dochelp at microsoft dot com if necessary.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Monday, September 15, 2014 5:26 PM
  • Hi,

    Here is an example of a weekly recurrence (no exceptions) binary generated with Outlook 2013 (HEX format):

    043004300B2001000000C021000001000000000000003E0000002220000007000000000000000000000000000000A01CFA0CA049FA0C063000000930000094020000B20200000000000000000000000000000000

    And here is a recurrence generated with my code following the documentation :

    043004300B2001000000C021000001000000000000003E0000002220000007000000000000000000000000000000A01CFA0C00000000063000000930000094020000B2020000000000000000000000000000

    The differences (in bold) are due to an invalid recurrence end date, so don't take care of it.

    Regards,


    Désiré GOVIN Refresh IT Solutions

    Tuesday, September 16, 2014 8:26 AM
  • Hello Désiré,

    Neither of these seem to match the documented size. Outlook appears to be tacking on 4 extra bytes, and yours appears to be adding 2 additional. In your code, are you perhaps treating the ExceptionCount field of AppointmentRecurrencePattern as 4 bytes instead of 2?

    I don't have an explanation for what you're seeing with Outlook. I'll try to replicate the behavior on my end and investigate further from there. If you have a packet capture containing these examples that you can send to dochelp at Microsoft dot com, that would also be very helpful.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Tuesday, September 16, 2014 6:44 PM
  • Hi,

    you're right I've sent you a binary stream from one of my test by setting Exception count with 4 bytes...

    But it does not explain the extra bytes set by Outlook.

    Best regards,


    Désiré GOVIN Refresh IT Solutions

    Wednesday, September 17, 2014 7:35 AM
  • Hello Désiré,

    I have not been able to reproduce what you're seeing from Outlook 2013 in my own testing. Here is the PidLidAppointmentRecur structure as processed by RPX when I create an appointment with a weekly recurrence:

    0x80750102  <Unknown>                             PtypBinary       80 Byte(s)
    	0000: 04 30 04 30 0B 20 01 00 00 00 C0 21 00 00 01 00 - .0.0. .....!....
    	0010: 00 00 00 00 00 00 08 00 00 00 23 20 00 00 0A 00 - ..........# ....
    	0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 - ...............(
    	0030: F8 0C DF 80 E9 5A 06 30 00 00 09 30 00 00 58 02 - .....Z.0...0..X.
    	0040: 00 00 76 02 00 00 00 00 00 00 00 00 00 00 00 00 - ..v.............
    

    This is 80 bytes as expected from the specification. Can you please provide a trace that demonstrates the extra bytes being sent?

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Wednesday, September 17, 2014 7:08 PM
  • Hello Désiré,

    Have you had a chance to gather a trace of this for me? I can't do anything further without that data.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Monday, September 29, 2014 8:22 PM
  • Hello Désiré,

    Please let me know if you still need assistance with this. I'll assume this is resolved if I don't hear from you by early next week.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Friday, October 3, 2014 10:43 PM
  • Hello,

    it seems that I have misread the binary extracted from Outlook.

    I have re-run my tests and all is correct as you noticed.

    Thanks for your help,

    Regards


    Désiré GOVIN Refresh IT Solutions

    Monday, October 6, 2014 7:51 AM
  • Hello Désiré,

    I'm glad to hear that this is resolved. Thank you for letting us know.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Monday, October 6, 2014 3:03 PM