none
EAS MeetingResponse documented in MS-ASCMD appears inconsistent with behavior of Outlook 2013 RRS feed

  • Question

  • When configured for EAS, Outlook 2013 sends a MeetingResponse when the attendee accepts a new meeting request, but not when the attendee accepts an update to an existing meeting request.  The MS-ASCMD, section 3.1.5.5 makes no distinction between new and existing meeting requests when it states that the attendee's "accept" or "decline" should generate a MeetingResponse.
    Tuesday, February 19, 2013 4:15 PM

Answers

  • Hi rkarr,

    The Attendee update Meeting Response Object depends on whether it is a Full Update or Informational Update to the meeting.

    This is mentioned in MS-OXOCAL Section 1.3.1.5 Meeting Update Object (refers to Section 1.3.1.4 Meeting Response Object). However, I have asked for a change in a future version of the documentation to specify the details of all conditions that result in a Full Update vs Informational Update.

    Start Date/Time --> Full
    End Date/Time --> Full
    Recurrence --> Full
    Free/Busy --> Informational
    Location --> Informational
    Subject --> Informational
    Required attendee --> Informational
    Optional attendee --> Informational
    Body, Attachment --> Informational
    Custom properties, Bill information, Companies, Mileage --> Informational
    Response Requested --> Informational
    Allow New Time Proposal --> Informational
    Online Meeting --> Informational
    Removed attendee --> Informational

    I hope this answers your question.

    Regards,

    Mark Miller | Escalation Engineer | Open Protocols Support Team

    Thursday, March 14, 2013 8:26 PM
  • Hi tfu72, do you have a similar issue that you are investigating? MS-ASCMD section 3.1.5.6 states the following in regards to when the client should send a MeetingResponse message back to the server. I don't know if this was in the document 3 years ago, or if it was added later. Please let me know if this answers your question.

     

    When the client displays the meeting request message, if the value of the email2:MeetingMessageType element is 1 or 2, the client SHOULD offer the options of accepting, declining, or tentatively accepting the meeting. If one of these actions is selected, the client sends a MeetingResponse command to the server. For other values of the email2:MeetingMessageType element, the client SHOULD NOT send a MeetingResponse command to the server.


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

    Wednesday, April 6, 2016 5:36 PM
    Moderator

All replies

  • Hello rKarr,

              Thank you for your inquiry about MS-ASCMD protocol. One of the Open specifications team member will contact you shortly.

     

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open Specifications

    Tuesday, February 19, 2013 6:30 PM
    Moderator
  • Hi rkarr,

    I am investigating this issue and will follow up with you soon.

    Regards,

    Mark Miller | Escalation Engineer | Open Protocol Support Team

    Monday, February 25, 2013 9:54 PM
  • Hi rkarr,

    The Attendee update Meeting Response Object depends on whether it is a Full Update or Informational Update to the meeting.

    This is mentioned in MS-OXOCAL Section 1.3.1.5 Meeting Update Object (refers to Section 1.3.1.4 Meeting Response Object). However, I have asked for a change in a future version of the documentation to specify the details of all conditions that result in a Full Update vs Informational Update.

    Start Date/Time --> Full
    End Date/Time --> Full
    Recurrence --> Full
    Free/Busy --> Informational
    Location --> Informational
    Subject --> Informational
    Required attendee --> Informational
    Optional attendee --> Informational
    Body, Attachment --> Informational
    Custom properties, Bill information, Companies, Mileage --> Informational
    Response Requested --> Informational
    Allow New Time Proposal --> Informational
    Online Meeting --> Informational
    Removed attendee --> Informational

    I hope this answers your question.

    Regards,

    Mark Miller | Escalation Engineer | Open Protocols Support Team

    Thursday, March 14, 2013 8:26 PM
  • My scenario is a Date/Time change which is a "Full Upate".  (My apologies for not stating this initially.)  In this scenario, Outlook 2013 requires the attendee to "Accept" a "Full Update" to a meeting.  However, Outlook does not then send the MeetingResponse described in MS-ACMD back over the network to the EAS server, as it does in the case of "Accepting" the initial meeting request.  This causes a problem for mail servers, in that they cannot apply the update to the attendee's meeting. 

    Saturday, March 23, 2013 6:18 PM
  • Hi RJK3, thank you for the additional information. Someone will follow-up with you shortly about this.

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

    Wednesday, April 3, 2013 6:12 PM
    Moderator
  • Hi Josh, is there any feedback on the inquiry of rjk3 from you side?
    Thursday, March 31, 2016 8:48 PM
  • Hi tfu72, do you have a similar issue that you are investigating? MS-ASCMD section 3.1.5.6 states the following in regards to when the client should send a MeetingResponse message back to the server. I don't know if this was in the document 3 years ago, or if it was added later. Please let me know if this answers your question.

     

    When the client displays the meeting request message, if the value of the email2:MeetingMessageType element is 1 or 2, the client SHOULD offer the options of accepting, declining, or tentatively accepting the meeting. If one of these actions is selected, the client sends a MeetingResponse command to the server. For other values of the email2:MeetingMessageType element, the client SHOULD NOT send a MeetingResponse command to the server.


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

    Wednesday, April 6, 2016 5:36 PM
    Moderator