Scheduling object resources on the server might change frequently as "Attendees" change their participation status, triggering updates to the "Organizer", and refreshes of other "Attendees'" copies of the scheduling object resource. This can lead to an "inconsequential" change to a calendar user's data -- one that does not directly impact the user's own participation status. When this occurs, clients have to reload calendar data and reconcile with changes being made by calendar users. To avoid the need for this, the server can instead merge calendar data changes from a client with changes made as a result of a scheduling operation carried out by some other calendar user.
This specification introduces a new WebDAV resource property CALDAV: schedule-tag with a corresponding response header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request header to allow client changes to be appropriately merged with server changes in the case where the changes on the server were the result of an "inconsequential" scheduling message update (one that simply updates the status information of "Attendees" due to a reply from another "Attendee").
Servers MUST automatically resolve conflicts with "inconsequential" changes done to scheduling object resources when the "If-Schedule- Tag-Match" request header is specified. The If-Schedule-Tag-Match request header applies only to the Request-URI, and not to the destination of a COPY or MOVE.
A response to any successful GET or PUT request targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule- tag WebDAV property of the resource.
A response to any successful COPY or MOVE request that specifies a Destination request header targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the destination resource.
Clients SHOULD use the If-Schedule-Tag-Match header on requests that update scheduling object resources, instead of HTTP ETag-based precondition tests (e.g., If-Match). Normal ETag-based precondition tests are used in all other cases, e.g., for synchronization.
The value of the CALDAV:schedule-tag property changes according to these rules:
o For an "Organizer's" copy of a scheduling object resource:
1. The server MUST NOT change the CALDAV:schedule-tag property value when the scheduling object resource is updated as the result of automatically processing a scheduling message reply from an "Attendee". For instance, when an "Attendee" replies to the "Organizer", the CALDAV:schedule-tag property is unchanged after the "Organizer's" scheduling object resource has been automatically updated by the server with the "Attendee's" new participation status.
2. The server MUST change the CALDAV:schedule-tag property value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY, or MOVE).
o For an "Attendee's" copy of a scheduling object resource:
1. The server MUST change the CALDAV:schedule-tag property value when the scheduling object resource is changed as the result of processing a scheduling message update from an "Organizer" that contains changes other than just the participation status of "Attendees".
2. The server MUST NOT change the CALDAV:schedule-tag property value when the scheduling object resource is changed as the result of processing a scheduling message update from an "Organizer" that only specifies changes in the participation status of "Attendees". For instance, when "Attendee" "A" replies to "Organizer" "O", and "Attendee" "B" receives a scheduling message update from "Organizer" "O" with the new participation status of "Attendee" "A", the CALDAV:schedule- tag property of "Attendee" "B"'s scheduling object resource would remain the same.
3. The server MUST change the CALDAV:schedule-tag property value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY, or MOVE).