3.1.4.7.4.2 Updating the Meeting Object

  • Article

To update a Meeting object, a client first searches for a Calendar object that matches the Meeting Update object, as specified in section 3.1.5.1, and verifies the following (taking the appropriate actions as specified):

  • If the Meeting Update object represents an exception, and the recurring series is found in the Calendar folder but the exception was previously deleted from the recurring series, then the client re-creates the exception, as specified in section 3.1.4.6.2 (unless the cpsRevivedException bit of the PidLidServerProcessingActions property (section 2.2.5.5) of the Meeting Request object is set and the value of the PidLidServerProcessed property (section 2.2.5.4) is set to TRUE, in which case the client MAY<59> skip re-creation of the exception). After re-creating the exception, the client can set the cpsRevivedException bit of the PidLidServerProcessingActions property of the Meeting Request object to TRUE.

  • If the Meeting object is not found in the Calendar folder, as specified in section 3.1.5.1, then the client SHOULD change the value of the PidLidMeetingType property (section 2.2.6.5) on the Meeting Update object to mtgRequest (0x00000001) and then follow the steps for receiving a new Meeting Request object, as specified in section 3.1.4.7.2.

  • If the user is the organizer of the meeting, the client does not update the Calendar object with the information from the Meeting Update object.

  • If the Meeting Update object is out-of-date, as specified in section 3.1.5.2, the client SHOULD change the value of the PidLidMeetingType property on the Meeting Update object to mtgOutofDate (0x00080000) and does not update the Meeting object. Similarly, if the Meeting Update object is not newer than the Meeting object, as specified in section 3.1.5.3, the client does not update the Meeting object.

After verifying that the Meeting object is eligible for update, the client SHOULD<60> do the following:

  • Copy the value of the PidLidLocation property (section 2.2.1.4) from the Meeting object to the PidLidOldLocation property (section 2.2.6.7) on the Meeting Request object.

  • Copy the value of the PidLidAppointmentStartWhole property (section 2.2.1.5) from the Meeting object to the PidLidOldWhenStartWhole property (section 2.2.6.8) on the Meeting Request object.

  • Copy the value of the PidLidAppointmentEndWhole property (section 2.2.1.6) from the Meeting object to the PidLidOldWhenEndWhole property (section 2.2.6.9) on the Meeting Request object.

    The client MAY<61> skip these actions if the cpsCopiedOldProperties bit of the PidLidServerProcessingActions property of the Meeting Update object is set and the PidLidServerProcessed property is set to TRUE.

    After completing these actions the client can set the cpsCopiedOldProperties bit of the PidLidServerProcessingActions property of the Meeting Update object.

Next, the client copies all the properties specified in section 2.2.1 from the Meeting Update object onto the Meeting object. The client also adds all required properties specified in section 2.2.4; however, the client SHOULD comply with the following exceptions:

  • If the value of the PidTagSensitivity property ([MS-OXCMSG] section 2.2.1.13) on the Meeting object is set to private, it SHOULD<62> remain so, even if this is not the value of the property on the Meeting Update object.

  • The downlevel text SHOULD be removed from the body as specified in section 2.2.6.12.

If the user has not yet responded to the original Meeting Request object, as reflected in the value of the PidLidResponseStatus property (section 2.2.1.11) on the Meeting object, the client MUST set the value of the PidLidMeetingType property on the Meeting Update object to mtgFull (0x00010000) and the value of the PidTagIconIndex property (section 2.2.1.49) on the Meeting Update object to "Meeting request/full update" (0x00000404) if these properties have any other values.

If the Meeting Update object does not include a significant change, as specified in section 3.1.4.7.3.1, and the attendee had already responded to the original Meeting Request object, the client SHOULD NOT<63> change the value of the PidLidResponseStatus property on the Meeting object. Regardless of whether the attendee had previously responded, if the Meeting Update object represents an update with a significant change, the client sets the following properties on the Meeting object so that it looks as if the attendee has not yet responded:

  • The value of the PidLidResponseStatus property to "respNotResponded" (0x00000005).

  • The value of the PidLidBusyStatus property (section 2.2.1.2) to "olTentative" (0x00000001), unless the value of the PidLidIntendedBusyStatus property (section 2.2.6.4) is "olFree" (0x00000000), in which case it is set to "olFree".

The client follows the same steps to Auto Respond to a Meeting Update object as is specified for a Meeting Request object in section 3.1.4.7.2.3.

Finally, after updating the Meeting object, the client:

  • SHOULD set the value of the PidTagProcessed property (section 2.2.5.7) to TRUE, unless the object is in a public folder, in which case this property is not set.

  • Can set the PidLidServerProcessed property on the Meeting Request object to TRUE. If the Meeting Request object's PidLidServerProcessed property is set, the client either MUST also set the cpsUpdatedCalItem bit of the PidLidServerProcessingActions property on the Meeting Request object or MUST leave both properties unset.