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.

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:

1. 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:
   1. The server deletes the meeting request email message from his Inbox.
   2. 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.

1. 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.)

1. Bob's client sends an email message to the organizer that indicates his acceptance.
2. 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 user accepts 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" &lt;alice@contoso.com&gt;</email:To>

            <email:From>"Bob" &lt;bob@contoso.com&gt;</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 " &lt;bob@contoso.com&gt;</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»&#x12;F               n                 &#x2;Ô</email2:ConversationId>

            <email2:ConversationIndex>Ì&#x10;1ë¯&#x0;&#x0;&#x1A;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.

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.

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

This post is part of an ongoing series that covers Microsoft Exchange ActiveSync for developers. 

In this post, we are using Exchange ActiveSync protocol version 14.1. Where applicable, we note differences between protocol versions.

Meeting requests are important for information workers who use Microsoft Exchange. Meeting requests inform attendees of a meeting, automatically book meeting time on the organizer's and attendees' calendars, provide reminders for meetings, and enable the booking of conference rooms. This post provides information for developers about working with meeting requests, including the following topics:

• How meeting requests are created by using Exchange ActiveSync.
• How invitees' Exchange ActiveSync clients interpret meeting requests.

 

The following figure shows an overview of the meeting request process and the two key scenarios involved. In this example, Exchange ActiveSync user Alice requests a meeting with Bob from her Exchange ActiveSync client. Bob sees the meeting request on his Exchange ActiveSync device.

Figure 1:   Meeting request process

Scenario 1: Organizer creates meeting request by using an Exchange ActiveSync client

A meeting starts out as a meeting request. The meeting organizer requests that attendees agree to participate in the meeting at a specified date, time, and location. Meeting requests are composed of the following two elements:

1.      A calendar item that reflects the proposed meeting on the organizer's and invitees' calendars.

2.      An invitation email sent by the organizer to invitees to notify them of the proposed meeting and solicit their responses.

In order for a user to create meeting requests, an Exchange ActiveSync client must do the following:

• Add a new calendar event to the organizer's calendar that includes the meeting details.

• Send an email to prospective attendees that includes the meeting details and response options.

After the Exchange ActiveSync client sends an email message that includes the meeting invitation, the Exchange server sends the invitation and saves a copy in the Sent Items folder. The following figure shows the client requests and server responses when a user, Alice, creates a meeting request from her Exchange ActiveSync client. The syncing of the Sent Items folder is optional.

 

Figure 2:   Sending a meeting request from an Exchange ActiveSync client

Adding meeting details to the organizer's calendar

Request to create the calendar item

When a user organizes a new meeting on the Exchange ActiveSync client, the client must create a meeting item on the organizer's calendar. The client adds the new calendar item to the Calendar collection. The calendar item contains all the meeting details, including meeting attendees. The following example shows an Exchange ActiveSync Sync command XML request that adds a meeting to Alice's calendar when she organizes a meeting and invites Bob.

 

For a list of and information about the Calendar schema elements for Exchange ActiveSync, see [MS-ASCAL]:  ActiveSync Calendar Class Protocol Specification section 2.2.2.

In the meeting request, the Exchange ActiveSync client must specify the start time and end time of the proposed event; this information is included in the StartTime and EndTime elements. Both dates have to be valid values of the dateTime type, as described in [MS-ASDTYPE]: ActiveSync Data Types section 2.3. All dates must be specified in Coordinated Universal Time (UTC), without any punctuation separators. Optionally, the client can use the DtStamp element to specify when the calendar item was created.

The client should specify the time zone in the request. If the time zone is not specified, the Exchange server uses its current  time zone for the meeting. For more information about the format of the time zone, see [MS-ASDTYPE] section 2.6.4.

Optionally, the client can mark the organizer's calendar by specifying the BusyStatus element. The following are the possible values for the BusyStatus element:

·        0 – Free

·        1 – Tentative

·        2 – Busy

·        3 – Out of office

If the organizer did not explicitly specify his or her attendance status, the client should use a value of 2 for the BusyStatus element to mark the meeting status as busy. If the client does not provide this value, the server uses a busy status by default.

The client should provide a MeetingStatus element for meetings. When the client saves a meeting to the organizer's calendar, it should set the value of this element to 1, which indicates that the item is a meeting.

A meeting must include the Attendees element, which contains a collection of Attendee elements. Each Attendee element must include at least one Email and one Name element; these contain the name and email address of the attendee. Optionally, the Attendee element can include values for the AttendeeStatus and AttendeeType elements. When the meeting is created, the AttendeeStatus element contains a value of 0. This value changes when attendees respond to the meeting request. If present, the AttendeeType element must be set to one of the following values:

·        1 – Required

·        2 – Optional

·        3 – Resource

Server response to the request to create the calendar item

The Exchange server sends a response to the Exchange ActiveSync client's request. The response indicates the status of the Calendar Sync command operation as well as the status of the individual meeting request. If the item was added correctly (as indicated by a Status element value of 1 in the response for both the item and the collection), the server issues a ServerId element value for the item in lieu of the temporary ClientId element value that the client assigned to it, as shown in the following example.

 

The client has to associate the newly issued ServerId value with this calendar item. For more information about status response values, see [MS-ASCMD]: ActiveSync Command Reference Protocol Specification.

Informing attendees of the meeting details by email notification

The email notification must make it clear to the recipients that its purpose is to inform them of the meeting request. It can also optionally solicit invitee responses to the request, and automatically block the meeting time on prospective attendees' calendars.

Client request to send the meeting email message

Exchange ActiveSync clients use the SendMail command to send MIME-formatted email messages to the server, including calendaring information structured according to a known calendaring format.

The iCalendar format is the most common calendaring format; this format is supported by a variety of clients. The following example shows the Exchange ActiveSync SendMail request that Alice's Exchange ActiveSync client sends.

 

 

The email message contains multiple parts. The message may contain a plain text part, which includes the body text of the meeting request. Several different calendar request formats are available for meeting request messages. Microsoft Exchange supports the iCalendar and TNEF formats. Each of these formats are included in a separate MIME part in the meeting request message. (For more information about MIME, see RFC 2045, RFC 2046, and RFC 2047.) Most clients use the iCalendar format for the meeting request, encoded in base64. Meeting requests have a content type of text/calendar with the method parameter set to “REQUEST”. The following section provides more detail about the iCalendar format.

iCalendar format

The iCalendar format is a file format (extension .ics, .ical) that represents calendaring information such as meeting requests, meeting responses, and free/busy information. For more information about this format, see RFC 2445, RFC 5546, and [MS-OXCICAL]: iCalendar to Appointment Object Conversion Protocol Specification.

This standard enables users of different calendaring systems (including clients and servers) to exchange calendaring information. iCalendar information is transported across the Internet in MIME format. The MIME body that contains the iCalendar information has a content type of text/calendar. The following example shows a typical iCalendar meeting request.

 

Server response to the client request to send the meeting email message

The response to SendMail command has no XML body (Content-Length = 0) if the SendMail command finishes successfully, as shown in the following example.

 

The server first responds to the SendMail request from the organizer's Exchange ActiveSync client, and then tries to send the message to the attendees. For this reason, a positive response to the SendMail request does not guarantee that the message was sent out successfully. The Exchange ActiveSync client can still receive a non-delivery report notification if the mail recipients are not found. For more information about the SendMail status values, see [MS-ASCMD] section 2.2.3.152.13. Non-delivery report responses should be handled in the same way that email responses are handled.

Before the Exchange server sends the email message, it interprets the iCalendar information and structures the message to the attendees to reflect that it is a meeting request.

Saving the meeting notification in Sent Items

After the Exchange ActiveSync client submits the meeting request email to the server, the Exchange server sends the email message to all the invited attendees. In addition, the Exchange server parses the iCalendar information that is embedded in the email. This way, it adds the email message to the Sent Items folder as the appropriate type; that is, a meeting request. The next time the Exchange ActiveSync client syncs the Sent Items folder, the meeting request email message will be added to the Sent Items folder on the client.

Client request to sync the Sent Items folder

The client syncs the Sent Items folder as shown in the following example.

 

Server response to the request to sync the Sent Items folder

The server adds a new item with the MessageClass element set to IPM.Schedule.Meeting.Request, as shown in the following example. This item contains all the meeting details.

 

The meeting request email that is sent to the attendees is of type IPM.Schedule.MeetingRequest and contains a MeetingRequest container. (For more information about the MeetingRequest container, see [MS-ASEMAIL]: ActiveSync E-Mail Class Protocol Specification section 2.2.2.14). This container describes the properties of the meeting. In addition, it now contains the GlobalObjId element value that was assigned to the meeting item by the server.

The GlobalObjId element value identifies the meeting request and allows the client to determine whether it corresponds to an existing object in the Calendar. For more information about the GlobalObjId element, see [MS-ASEMAIL] section 2.2.2.14.15. The UID element value assigned to the calendar item by the Exchange ActiveSync client is included in the GlobalObjId element value that the server returns. The GlobalObjId element value does not change when the meeting is updated. This enables the client to identify which meeting a particular notification corresponds to.

This meeting request message that is added to the organizer's Sent Items folder should not expose any response options to the user because it is in the organizer's mailbox.

Scenario 2: A meeting invitee receives a meeting request on the Exchange ActiveSync client

When an organizer sends a meeting request, the invitees' Exchange ActiveSync client must be able to receive the request, interpret it, and present it to the invitee as a meeting invitation. The meeting request should appear in the invitee's Inbox, and a placeholder Calendar item for the meeting should appear on the invitee's Calendar. The invitee should be able to accept, tentatively accept, or decline the meeting request, either from the meeting invitation or from the Calendar placeholder item, and send his or her response the meeting organizer.

The following figure shows the operations involved in sending a meeting request to an Exchange ActiveSync client. In this example, Bob is the meeting invitee.

Figure 3:   Sending a meeting request to an Exchange ActiveSync client

Adding the meeting request to the invitee's Inbox

When the meeting invitation first arrives in the invitee's mailbox, it is in the form of a meeting request in the Inbox.

Receiving the meeting request

The Exchange ActiveSync client receives the meeting request upon issuing a Sync command request for the invitee's Inbox. We recommend that Exchange ActiveSync clients request body items in HTML format by setting the BodyPreference element to 2. HTML provides rich content formatting that the client can then render. The meeting request is shown in the following example.

 

Server response to the Sync command request

The organizer's Exchange server converts the item's iCalendar information and parses it into a message class of IPM.Schedule.Meeting.Request, which is then synced to the invitee's Inbox, as shown in the following example.

 

The MeetingRequest element is an optional container element. The MeetingRequest element is included when the message is a meeting request and the Exchange ActiveSync client's user is an attendee. The MeetingRequest element is not included in the message content of calendar items in the Calendar folder or in regular email messages. If a message contains the MeetingRequest element, the client can respond to the meeting request by using the MeetingResponse command. For more information about this command, see [MS-ASCMD] section 2.2.2.9.

The GlobalObjId element is a required child element of the MeetingRequest element. GlobalObjId is defined as an element in the Email namespace. Clients that need to determine whether the GlobalObjId  element for a meeting request corresponds to an existing Calendar object in the Calendar folder have to convert the GlobalObjId element value to a UID element value to make the comparison. For information about how this conversion is done, see [MS-ASEMAIL] section 2.2.2.14.15.

MeetingMessageType is a new element that was added in version 14.1 of the Exchange ActiveSync protocol. The MeetingMessageType element further defines the type of the meeting request. For information about this element, see [MS-ASEMAIL] section 2.2.2.14.17.

Client request to sync the Calendar folder

The invitee's (Bob's) Exchange ActiveSync client issues a Sync request for the Calendar folder, similar to the one shown in the following example.

 

Tentative meeting added to invitee's calendar

In Microsoft Exchange Server 2007 (which corresponds to Exchange ActiveSync protocol version 12.0) and later versions, the server parses the meeting request received in the invitee's Inbox and adds a tentative meeting to the invitee's calendar to mark the time of the proposed meeting. This tentative meeting is synced to the client.

Server response to the request to Sync the Calendar folder

Based on the meeting request that the Exchange server received, the server created a meeting item in Bob's Calendar folder with the UID element value previously specified by the organizer. Syncing the Calendar collection adds the meeting to the invitee's calendar.

The calendar item contains a UID element value that the organizer's client had set, which correlates to the meeting request in the Inbox via the GlobalObjId element.

 

The meeting that is added to the invitee's Calendar collection contains all the properties of the calendar item on the organizer's Calendar, as well as the following additional elements:

·        OrganizerName

·        OrganizerEmail

·        ResponseRequested

·        MeetingStatus

·        ResponseType

The value of the ResponseRequested element comes from the PARTSTAT parameter value of "NEEDS-ACTION" in the original iCalendar meeting request.

When the invitee receives the meeting request, the MeetingStatus element is set to 3, which indicates that the meeting was received, and the ResponseType element is set to 5, to indicate that the invitee has not yet responded to the meeting request. After the invitee responds, the server updates these values to reflect the new status. Stay tuned for our next blog post, "Working with meeting responses in Exchange ActiveSync", for more information about meeting responses.

Summary

Creating meeting requests and interpreting them from an Exchange ActiveSync client is critical to ensuring a successful calendaring experience for Exchange ActiveSync client users. It is important to use the correct iCalendar format to create meeting requests and to remember not to try to process incoming iCalendar requests on the client, but instead to allow the Exchange server to process the requests.  

Related Resources

[MS-ASEMAIL]: ActiveSync E-Mail 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

RFC 2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"

RFC 2445, "Internet Calendaring and Scheduling Core Object Specification"

RFC 5546, "iCalendar Transport-Independent Interoperability Protocol (iTIP)"

 

Post authored by: Katarzyna Puchala, Microsoft Corporation