Working with meeting responses in Exchange ActiveSync
This post is part of an ongoing series that covers Microsoft Exchange ActiveSync for developers. This post applies to Exchange ActiveSync protocol version 14.1. Where applicable, differences between protocol versions are noted.
The ability to respond to meeting requests is an important aspect of collaboration and communication for Microsoft Exchange users. Responses to meeting requests inform meeting organizers of invitees' attendance status and automatically book the time on attendees' Calendars. This post provides information for developers about working with meeting responses, including the following topics:
- How the Exchange ActiveSync client responds to meeting requests.
- How the Exchange ActiveSync client should interpret responses to meetings organized by the client user.
For information about working with meeting requests, see the blog post Working with Meeting Requests in Exchange ActiveSync.
Note: Other topics related to calendaring with Exchange ActiveSync, such as recurring meetings; delegation; and meeting responses, updates, and cancellations, will be covered in future blog posts.
The following figure shows an overview of the meeting response process and the two key scenarios involved. In this example, Exchange ActiveSync user Bob has received a meeting invitation from the organizer, Alice, on his Exchange ActiveSync client. Bob responds to the meeting request using his Exchange ActiveSync device and Alice can verify his response status using her device.
Figure 1: Meeting response process
This post does not cover adding the meeting request email message to the invitee's Inbox and a creating tentative placeholder item on the invitee's Calendar. For information about the meeting request process, see Working with Meeting Requests in Exchange ActiveSync.
Scenario 1: Invitee uses an Exchange ActiveSync client to respond to a meeting request
In our example, an invitee, Bob, finds a meeting request from Alice waiting in his Inbox, and a placeholder Calendar item tentatively marking the time of the meeting on his Calendar. Bob can choose to accept, tentatively accept, or decline the meeting and send his response to the organizer from either the meeting invitation in his Inbox or the Calendar placeholder item. Bob accepts the meeting request by using the options provided by the meeting request email displayed on his Exchange ActiveSync client. The Exchange server then deletes the meeting request from his Inbox and changes the status of the placeholder Calendar item from tentative to busy. In addition, the Exchange ActiveSync client sends a meeting acceptance notification to the organizer. A copy of this message appears in Bob's Sent Items folder.
The following figure shows the Exchange ActiveSync client meeting response process.
Figure 2: Exchange ActiveSync client meeting response process
Responding to meeting requests involves the following steps:
- The user, in this case Bob, accepts the meeting from his Exchange ActiveSync client by using the options exposed in the meeting request. Upon doing so, the following takes place:
- The server deletes the meeting request email message from his Inbox.
- The server deletes the tentative meeting from his Calendar and adds an accepted meeting in its place.
Note: If Bob's Exchange server is not configured to process incoming meeting requests automatically, a tentative meeting placeholder item does not appear on his Calendar. In this case, the server does not delete any Calendar item, and the MeetingResponse command cannot be sent from the Calendar folder; it can be used on the meeting request in the Inbox only.
- When Bob issues a Sync command on Calendar folder, the tentative meeting is deleted from the Calendar by the Exchange server, and a new accepted meeting is added.
Note: If Bob syncs his Deleted Items folder, a copy of the original meeting item is added to that folder. (This step is not shown in Figure 2 and is not described in this blog post.)
- Bob's client sends an email message to the organizer that indicates his acceptance.
- The server adds a copy of the meeting acceptance email message in Bob's Sent Items folder. If Bob syncs his Sent Items folder, a copy of the notification will appear there.
When the ResponseRequested element is set to 1, the Exchange ActiveSync client allows the user to act on the meeting request from both the Inbox and the Calendar item.
Responding to meeting requests from the Inbox
When the client displays a meeting request message in a user's Inbox, the user has the option to accept, tentatively accept, or decline the meeting invitation. After the user selects a response, the client sends a MeetingResponse command to the server.
MeetingResponse command
The following example shows a MeetingResponse command request.
POST /Microsoft-Server-ActiveSync?Cmd=MeetingResponse&User=Bob&DeviceId=ABCDEF&DeviceType=SmartPhone HTTP/1.1
Content-Type: application/vnd.ms-sync.wbxml
MS-ASProtocolVersion: 14.1
User-Agent: ASOM
Host: mail.contoso.com
<?xml version="1.0" encoding="utf-8"?>
<MeetingResponse xmlns="MeetingResponse:">
<Request>
<UserResponse>1</UserResponse>
<CollectionId>6</CollectionId>
<RequestId>6:17</RequestId>
</Request>
</MeetingResponse>
The RequestId element specifies the server ID of the meeting request in the Inbox collection. The UserResponse element can contain one of the values listed in the following table.
UserResponse element value |
Invitee response |
Server action |
1 |
Accepted |
The server deletes the corresponding Calendar entry and creates a new Calendar entry with the "Accepted" status. |
2 |
Tentative |
The server deletes the corresponding Calendar entry and creates a new Calendar entry with the "TentativelyAccepted" status. |
3 |
Declined |
The server deletes the corresponding Calendar entry. |
Server response to the MeetingResponse command
After the MeetingResponse command has finished, the server automatically deletes the meeting request item from the Inbox. The following example shows the server response.
HTTP/1.1 200 OK
MS-Server-ActiveSync: 14.0
<?xml version="1.0" encoding="utf-8" ?>
<MeetingResponse xmlns="MeetingResponse:">
<Result>
<RequestId>6:17</RequestId>
<Status>1</Status>
<CalendarId>2:25</CalendarId>
</Result>
</MeetingResponse>
The RequestId element specifies the meeting request that the client is responding to. If the meeting invitation is accepted or tentatively accepted, the server adds or updates the corresponding Calendar item and returns the item's server ID in the CalendarId element of the response.
The following table lists the possible values for the Status element.
Status element value |
Server response |
Client action |
1 |
Success |
The request succeeded. |
2 |
InvalidMeetingRequest |
This response indicates that the request is invalid. The client should not retry the request, as it is unlikely to succeed.
The server sends this response if the item sent to the server is not a valid meeting. |
3 |
ErrorOccurredOnMailbox |
This error is returned when client sync state is missing or corrupt on the server. The client can retry once right away, but should retry slowly after that, about once an hour. If the request still fails after an extended period, the client should stop retrying. |
4 |
ErrorOccurredOnExchangeServer |
This error indicates that the meeting request can't be processed. The meeting request may be missing, the meeting may have been canceled, or this may be a delegate meeting to which the user can't respond. If the client retries the request, it is unlikely to succeed. |
Note: The Exchange ActiveSync client should handle the response to the MeetingResponse command in the same way that it handles the status responses to email commands.
When an invitee responds from the Inbox item, the Exchange server deletes the meeting invitation from the Inbox. The invitee can, however, change their response to the meeting request from the Calendar item with new MeetingResponse command. If the user declines the meeting, the server deletes the Calendar item, and it can no longer be used to respond to the meeting request.
The Exchange server automatically deletes the email invitation from the Inbox after the user has responded to the request. When the Exchange ActiveSync client syncs the Deleted Items folder, the deleted item is automatically added to the Deleted Items folder on the client.
Responding to meeting requests from the Calendar folder
Users respond to a meeting request from the Calendar folder in the same way that they respond to the request from the Inbox. The client uses the MeetingResponse command, but in this case, the RequestId element value indicates the Calendar item. This option is only available in Exchange ActiveSync version 14.0 and later versions. Just like when the user responds from the Inbox, the meeting request item in the Inbox is automatically deleted by the server when the user responds from the Calendar item.
Replacing the placeholder Calendar item with a new item
When the user responds to the meeting request, the original tentative Calendar item is deleted. If the user declines the meeting request, the server does not add a new item to the Calendar. If the useraccepts or tentatively accepts the meeting request, the server creates a new Calendar item with the status as indicated by the user. The following example shows the sync process for the Calendar collection, after the user has accepted the meeting request. The original meeting item is deleted, and new item with a status of Accepted is added in its place. The UID element value of the new accepted item is identical to the value of the tentative placeholder item.
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-sync.wbxml
<?xml version="1.0" encoding="utf-8"?>
<Sync >
<Collections>
<Collection>
<SyncKey>1598194209</SyncKey>
<CollectionId>2</CollectionId>
<Status>1</Status>
<Commands>
<Add>
<ServerId>2:25</ServerId>
<ApplicationData>
<calendar:TimeZone>4AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAABAA
IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAACAAIAAA
AAAAAAxP///w==</calendar:TimeZone>
<calendar:DtStamp>20110510T185139Z</calendar:DtStamp>
<calendar:StartTime>20110510T170000Z</calendar:StartTime>
<calendar:Subject>Quarterly Planning</calendar:Subject>
<calendar:UID>A3561BDAAE8E4B30AC255FD3F31A3AD7000000000000000000000
00000000000</calendar:UID>
<calendar:OrganizerName>Alice </calendar:OrganizerName>
<calendar:OrganizerEmail>alice@contoso.com</calendar:OrganizerEmail>
<calendar:Attendees>
<calendar:Attendee>
<calendar:Email>bob@contoso.com</calendar:Email>
<calendar:Name>Bob </calendar:Name>
<calendar:AttendeeType>1</calendar:AttendeeType>
</calendar:Attendee>
</calendar:Attendees>
<calendar:Location>Office</calendar:Location>
<calendar:EndTime>20110510T180000Z</calendar:EndTime>
<airsyncbase:Body>
<airsyncbase:Type>1</airsyncbase:Type>
<airsyncbase:EstimatedDataSize>127</airsyncbase:EstimatedDataSize>
<airsyncbase:Truncated>1</airsyncbase:Truncated>
</airsyncbase:Body>
<calendar:Sensitivity>0</calendar:Sensitivity>
<calendar:BusyStatus>2</calendar:BusyStatus>
<calendar:AllDayEvent>0</calendar:AllDayEvent>
<calendar:Reminder>15</calendar:Reminder>
<calendar:MeetingStatus>3</calendar:MeetingStatus>
<airsyncbase:NativeBodyType>3</airsyncbase:NativeBodyType>
<calendar:ResponseRequested>1</calendar:ResponseRequested>
<calendar:AppointmentReplyTime>20110506T165252Z</AppointmentReplyTime>
<calendar:ResponseType>3</calendar:ResponseType>
</ApplicationData>
</Add>
<Delete>
<ServerId>2:24</ServerId>
</Delete>
</Commands>
</Collection>
</Collections>
</Sync>
The client has to sync the Calendar folder after the user accepts or tentatively accepts a meeting request in order for the new Calendar item to appear on the user's Calendar.
Deleting the Calendar item when the meeting is declined
If the user declines the meeting, the Exchange server automatically deletes the corresponding Calendar item. The client must not delete the Calendar item on behalf of the user.
When a user declines a meeting request, the response does not contain a meetingresponse:CalendarId element because the server deletes the corresponding Calendar item.
Sending response notifications
The client sends a notification to the meeting organizer if the user chooses to send a response. The client uses the SendMail command to send the notification. The client should send the email notification only after the MeetingResponse command finishes successfully; otherwise, the invitee's Calendar and the status information that the invitee reports to the organizer will be in conflict. If the ResponseRequested element is set to 0 (false) on the meeting request, the client does not expose an option to the user to send a response notification to the organizer.
The client indicates its response in the subject of the email message, as well by using an iCalendar reply command, as shown in the following example.
POST /Microsoft-Server-ActiveSync?Cmd=SendMail&User=Bob&DeviceId=ABCDEF&DeviceType=SmartPhone HTTP/1.1
Content-Type: application/vnd.ms-sync.wbxml
MS-ASProtocolVersion: 14.0
Host: mail.contoso.com
<?xml version="1.0" encoding="utf-8" ?>
<SendMail xmlns="ComposeMail:">
<ClientId>13554</ClientId>
<SaveInSentItems/>
<Mime>
Subject: Accepted: Quarterly Planning
From: Bob@contoso.com
Content-Type: multipart/alternative;
boundary=NextPart
To: Alice <Alice@contoso.com>
--NextPart
Content-Type: text/plain;
charset=us-ascii
Sure, I will be there!
--NextPart
Content-Type: text/calendar;
charset=utf-8;
name=meeting.ics;
method=REPLY
Content-Transfer-Encoding: quoted-printable
BEGIN:VCALENDAR…<more iCalendar content follows>
</Mime>
</SendMail>
The following table lists the possible response types.
Response type |
Email /subject |
iCalendar reply method |
Accepted |
Accepted: <meeting request subject> |
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:<organizer> |
TenativelyAccepted |
Tenative: <meeting request subject> |
ATTENDEE;PARTSTAT=TENTATIVE:MAILTO:<organizer> |
Declined |
Declined: <meeting request subject> |
ATTENDEE;PARTSTAT=DECLINED:MAILTO:<organizer>
|
Meeting updates
If the organizer makes updates to the meeting, the Exchange ActiveSync client might receive multiple meeting notification email messages. All mail items that are related to the same meeting have the same GlobalObjId element value (for the email notification) and the same UID element value (for the Calendar item). If the Exchange ActiveSync client receives multiple updates that share the same ID, it is important for the client to enable the user to respond to the most recent item only based on the DtStamp value.
Scenario 2: Organizer uses an Exchange ActiveSync client to verify the meeting response status
After the invitees have responded to the meeting request, the organizer might want to determine the status of the responses. The organizer can view the responses in the Inbox as they arrive from individual invitees. In addition, the Exchange server automatically parses the invitee responses and updates the Calendar item accordingly. The organizer can view the response status on the Calendar item based on updates from the server to the Exchange ActiveSync client.
Syncing meeting responses in the organizer's Inbox
As invitees respond to the meeting request, the organizer's Exchange ActiveSync client runs a Sync command on the Inbox folder to discover the responses, as shown in the following example.
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-sync.wbxml
<?xml version="1.0" encoding="utf-8"?>
<Sync>
<Collections>
<Collection>
<SyncKey>378940377</SyncKey>
<CollectionId>6</CollectionId>
<Status>1</Status>
<Commands>
<Add>
<ServerId>6:22</ServerId>
<ApplicationData>
<email:To>"Alice" <alice@contoso.com></email:To>
<email:From>"Bob" <bob@contoso.com></email:From>
<email:Subject>Accepted: Quarterly Planning</email:Subject>
<email:DateReceived>20110506T165454Z</email:DateReceived>
<email:DisplayTo>Alice </email:DisplayTo>
<email:ThreadTopic>Quarterly Planning</email:ThreadTopic>
<email:Importance>1</email:Importance>
<email:Read>0</email:Read>
<airsyncbase:Body>
<airsyncbase:Type>1</airsyncbase:Type>
<airsyncbase:EstimatedDataSize>0</airsyncbase:EstimatedDataSize>
<airsyncbase:Truncated>1</airsyncbase:Truncated>
</airsyncbase:Body>
<email:MessageClass>IPM.Schedule.Meeting.Resp.Pos</email:MessageClass>
<email:MeetingRequest>
<email:AllDayEvent>0</email:AllDayEvent>
<email:StartTime>20110510T17000000Z</email:StartTime>
<email:DtStamp>20110506T165252Z </email:DtStamp>
<email:EndTime>20110510T180000Z</email:EndTime>
<email:InstanceType>0</email:InstanceType>
<email:Location>Office</email:Location>
<email:Organizer>"Bob " <bob@contoso.com></email:Organizer>
<email:Sensitivity>0</email:Sensitivity>
<email:TimeZone>4AEAACgAVQBUAEMALQAwADgAOgAwADAAKQAgAFAAYQBjAGkAZgBpAGM
AIABUAGkAbQBlACAAKABVAFMAIAAmACAAQwAAAAsAAAABAAIAAAAAAAAAAAAAACgAV
QBUAEMALQAwADgAOgAwADAAKQAgAFAAYQBjAGkAZgBpAGMAIABUAGkAbQBlACAAKABVAF
MAIAAmACAAQwAAAAMAAAACAAIAAAAAAAAAxP///w==</email:TimeZone>
<email:GlobalObjId> BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAATQAAAHZD
YWwtVWlkAQAAAEEzNTYxQkRBQUU4RTRCMzBBQzI1NUZEM0YzMUEzQUQ3MDAwMDAwMDA
wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAA</email:GlobalObjId>
</email:MeetingRequest>
<email:InternetCPID>20127</email:InternetCPID>
<email:Flag />
<email:ContentClass>urn:content-classes:calendarmessage</email:ContentClass>
<airsyncbase:NativeBodyType>1</airsyncbase:NativeBodyType>
<email2:ConversationId>(Uí©E¯*O»F n Ô</email2:ConversationId>
<email2:ConversationIndex>Ì1ë¯��4E</email2:ConversationIndex>
<email:Categories />
</ApplicationData>
</Add>
</Commands>
</Collection>
</Collections>
</Sync>
Note that the ApplicationData container of the response that is synced to the organizer's Inbox contains To and From fields however, the values of these elements are different than the values in the original meeting request. In the response message, the To field indicates the organizer, because the organizer is the recipient of the response, while the From field indicates the invitee.
The MessageClass and Subject elements indicate the invitee's response to the request, as set by the client. The following are the possible values for the MessageClass element:
· IPM.Schedule.Meeting.Resp.Pos
· IPM.Schedule.Meeting.Resp.Tent
· IPM.Schedule.Meeting.Resp.Neg.
Important: The organizer's Exchange ActiveSync client must sync the Calendar folder in order to receive the meeting responses from meeting invitees. The organizer's mailbox uses the Calendar item to reconcile responses to a meeting request with the Calendar event.
Updating the organizer's Calendar item to reflect invitee responses
When the Exchange ActiveSync client syncs the organizer's Calendar folder, the original meeting item is updated to reflect any new or updated invitee responses. The client can then display the invitee status to the organizer. The following example shows a change in an attendee, Bob's, status after he accepts the meeting invitation. Note that the Calendar item shows a value of 3 for the AttendeeStatus element, rather than 0, which was the value when the request was created and before a response was received.
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-sync.wbxml
<?xml version="1.0" encoding="utf-8"?>
<Sync>
<Collections>
<Collection>
<SyncKey>124536913</SyncKey>
<CollectionId>2</CollectionId>
<Status>1</Status>
<Commands>
<Change>
<ServerId>2:9</ServerId>
<ApplicationData>
<calendar:Attendees>
<calendar:Attendee>
<calendar:Email>bob@contoso.com</calendar:Email>
<calendar:Name>Bob </calendar:Name>
<calendar:AttendeeStatus>3</calendar:AttendeeStatus>
<calendar:AttendeeType>1</calendar:AttendeeType>
</calendar:Attendee>
</calendar:Attendees>
</ApplicationData>
</Change>
</Commands>
</Collection>
</Collections>
</Sync>
The following table lists the possible values for the AttendeeStatus element.
AttendeeStatus element value |
Meaning |
0 |
No response |
2 |
Tentative |
3 |
Accept |
4 |
Decline |
5 |
Other |
When the organizer creates the meeting request, the AttendeeStatus element is set to 0 because no invitees have yet responded. As the response notifications arrive, the organizer’s Exchange server interprets the iCalendar content in the response messages and updates the AttendeeStatus value for each attendee accordingly. An AttendeeStatus value of 5 indicates a problem with interpreting the invitee response.
Exchange ActiveSync does not handle responses involving new time proposals. New time proposals appear as tentative or decline responses to the Exchange ActiveSync client. The new time proposal may be indicated in the subject line or the body of the message, depending on the client that the invitee uses to send the proposal.
Note: After an invitee responds to a request, the Exchange server deletes the meeting request from the invitee's mailbox. This helps to ensure that the invitee does not send multiple responses to the same meeting request that might conflict with one another. If the invitee does send multiple responses to the meeting request (for example, by responding from the Calendar item rather than the meeting invitation), the Exchange server automatically updates the organizer's Calendar item to reflect the most recent meeting response status.
Summary
The ability to respond to meeting requests is a critical element of a successful calendaring experience for Exchange ActiveSync client users. When you develop your Exchange ActiveSync client applications, make sure that you handle iCalendar meeting responses correctly. Keep in mind that your applications should not process incoming iCalendar meeting requests on the client; meeting requests should be processed by the Exchange server.
Additional Resources
[MS-ASEMAIL]: ActiveSync Email Class Protocol Specification
[MS-ASCAL]: ActiveSync Calendar Class Protocol Specification
[MS-ASCMD]: ActiveSync Email Command Reference Protocol Specification
[MS-ASDTYPE]: ActiveSync Data Types
[MS-OXGLOS]: Exchange Server Protocols Master Glossary
[MS-OXCICAL]: iCalendar to Appointment Object Conversion Protocol Specification
Post authored by: Katarzyna Puchala, Microsoft Corporation
Comments
- Anonymous
September 14, 2015
Great Post! Thanks for the detailed explanation here. Should we still expect to see the "future blog posts" that will detail recurring meetings; delegation; and meeting responses, updates, and cancellations? I see it has been a considerable amount of time since the original post.