Try out our new RRULE tool for creating RRULE compatible strings.

When a scheduling object resource is modified by an "Attendee", the server's behavior depends on the value of the "SCHEDULE-AGENT" iCalendar property parameter on the "ORGANIZER" iCalendar properties:

+----------------+--------------------------------------------------+
| SCHEDULE-AGENT | Action                                           |
+----------------+--------------------------------------------------+
| SERVER         | The server will attempt to process the update    |
| (default)      | using the behavior listed below.                 |
|                |                                                  |
| CLIENT         | The server does no special processing of the     |
|                | resource.  The client is assumed to be handling  |
|                | any "Attendee" replies, etc.                     |
|                |                                                  |
| NONE           | The server does no special processing of the     |
|                | resource.                                        |
+----------------+--------------------------------------------------+

The server will inspect the changes by comparing the new scheduling object resource with the existing scheduling object resource.

If the "Attendee" changes one or more "PARTSTAT" iCalendar property values on any component, or adds an overridden component with a changed "PARTSTAT" property, then the server MUST deliver an iTIP "REPLY" scheduling message to the "Organizer" to indicate the new participation status of the "Attendee". If the "Attendee" adds an "EXDATE" property value to effectively remove a recurrence instance, the server MUST deliver an iTIP "REPLY" scheduling message to the "Organizer" to indicate that the "Attendee" has declined the instance.

"SCHEDULE-STATUS" iCalendar property parameters are added or changed on "ORGANIZER" iCalendar properties in the scheduling object resource being modified as described in Section 7.3, with the value set as described in Section 3.2.9. This will result in the updated calendar object resource differing from the calendar data sent in the HTTP request. As a result, clients MAY reload the calendar data from the server in order to update to the new server-generated state information.

This document was automatically converted to XHTML using an RFC to HTML converter with the original text document at the Internet Engineering Task Force web site at ietf.org .  The original text document should be referred to if there are any errors or discrepancies found in this document.

Need to test your iCalendar feeds?

The iCalendar Validator provides developers and testers a method to validate their iCalendar feeds, which can take data from either a URL, file or text snippet and compare it against the RFC 5545 specification.  We believe we have one of the best iCalendar validation tools available on the internet. More information about the validator can be found here.