Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5546

iCalendar Transport-Independent Interoperability Protocol (iTIP)

Pages: 133
Proposed Standard
Errata
Obsoletes:  2446
Updates:  5545
Updated by:  6638
Part 4 of 5 – Pages 62 to 95
First   Prev   Next

Top   ToC   RFC5546 - Page 62   prevText

3.5. Methods for VJOURNAL Components

This section defines the property set for the methods that are applicable to the "VJOURNAL" calendar component. The following summarizes the methods that are defined for the "VJOURNAL" calendar component.
Top   ToC   RFC5546 - Page 63
   +---------+---------------------------------------------------------+
   | Method  | Description                                             |
   +---------+---------------------------------------------------------+
   | PUBLISH | Post a journal entry.  Used primarily as a method of    |
   |         | advertising the existence of a journal entry.           |
   |         |                                                         |
   | ADD     | Add one or more instances to an existing journal entry. |
   |         |                                                         |
   | CANCEL  | Cancel one or more instances of an existing journal     |
   |         | entry.                                                  |
   +---------+---------------------------------------------------------+

3.5.1. PUBLISH

The "PUBLISH" method in a "VJOURNAL" calendar component has no associated response. It is simply a posting of an iCalendar object that may be added to a calendar. It MUST have an "Organizer". It MUST NOT have "Attendees". The expected usage is for encapsulating an arbitrary journal entry as an iCalendar object. The "Organizer" MAY subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published journal entry. This method type is an iCalendar object that conforms to the following property constraints: +------------------------------------------------+ | Constraints for a METHOD:PUBLISH of a VJOURNAL | +------------------------------------------------+ +--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | METHOD | 1 | MUST be PUBLISH. | | | | | | VJOURNAL | 1+ | | | DESCRIPTION | 1 | Can be null. | | DTSTAMP | 1 | | | DTSTART | 1 | | | ORGANIZER | 1 | | | UID | 1 | | | ATTACH | 0+ | | | CATEGORIES | 0+ | | | CLASS | 0 or 1 | | | COMMENT | 0+ | | | CONTACT | 0+ | | | CREATED | 0 or 1 | | | EXDATE | 0+ | | | LAST-MODIFIED | 0 or 1 | |
Top   ToC   RFC5546 - Page 64
   |   RDATE            | 0+       |                                   |
   |   RECURRENCE-ID    | 0 or 1   | Only if referring to an instance  |
   |                    |          | of a recurring calendar           |
   |                    |          | component.  Otherwise, it MUST    |
   |                    |          | NOT be present.                   |
   |   RELATED-TO       | 0+       |                                   |
   |   RRULE            | 0 or 1   |                                   |
   |   SEQUENCE         | 0 or 1   | MUST be present if non-zero.  MAY |
   |                    |          | be present if zero.               |
   |   STATUS           | 0 or 1   | MAY be one of                     |
   |                    |          | DRAFT/FINAL/CANCELLED.            |
   |   SUMMARY          | 0 or 1   | Can be null.                      |
   |   URL              | 0 or 1   |                                   |
   |   IANA-PROPERTY    | 0+       |                                   |
   |   X-PROPERTY       | 0+       |                                   |
   |   ATTENDEE         | 0        |                                   |
   |   REQUEST-STATUS   | 0        |                                   |
   |                    |          |                                   |
   |   VALARM           | 0+       |                                   |
   |                    |          |                                   |
   | VTIMEZONE          | 0+       | MUST be present if any date/time  |
   |                    |          | refers to a timezone.             |
   |                    |          |                                   |
   | IANA-COMPONENT     | 0+       |                                   |
   | X-COMPONENT        | 0+       |                                   |
   |                    |          |                                   |
   | VEVENT             | 0        |                                   |
   |                    |          |                                   |
   | VFREEBUSY          | 0        |                                   |
   |                    |          |                                   |
   | VTODO              | 0        |                                   |
   +--------------------+----------+-----------------------------------+

3.5.2. ADD

The "ADD" method allows the "Organizer" to add one or more new instances to an existing "VJOURNAL" using a single iTIP message without having to send the entire "VJOURNAL" with all the existing instance data, as it would have to do if the "REQUEST" method were used. The "UID" must be that of the existing journal entry. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient MAY treat the "ADD" as a "PUBLISH". When handling an "ADD" message, the "Attendee" treats each component in the "ADD" message as if it were referenced via an "RDATE" in the main component. There is no response to the "Organizer".
Top   ToC   RFC5546 - Page 65
   This method type is an iCalendar object that conforms to the
   following property constraints:

              +--------------------------------------------+
              | Constraints for a METHOD:ADD of a VJOURNAL |
              +--------------------------------------------+

   +--------------------+----------+-----------------------------------+
   | Component/Property | Presence | Comment                           |
   +--------------------+----------+-----------------------------------+
   | METHOD             | 1        | MUST be ADD.                      |
   |                    |          |                                   |
   | VJOURNAL           | 1        |                                   |
   |   DESCRIPTION      | 1        | Can be null.                      |
   |   DTSTAMP          | 1        |                                   |
   |   DTSTART          | 1        |                                   |
   |   ORGANIZER        | 1        |                                   |
   |   SEQUENCE         | 1        | MUST be greater than 0.           |
   |   UID              | 1        | MUST match that of the original   |
   |                    |          | journal.                          |
   |   ATTACH           | 0+       |                                   |
   |   CATEGORIES       | 0+       |                                   |
   |   CLASS            | 0 or 1   |                                   |
   |   COMMENT          | 0+       |                                   |
   |   CONTACT          | 0+       |                                   |
   |   CREATED          | 0 or 1   |                                   |
   |   LAST-MODIFIED    | 0 or 1   |                                   |
   |   RELATED-TO       | 0+       |                                   |
   |   STATUS           | 0 or 1   | MAY be one of                     |
   |                    |          | DRAFT/FINAL/CANCELLED.            |
   |   SUMMARY          | 0 or 1   | Can be null.                      |
   |   URL              | 0 or 1   |                                   |
   |   IANA-PROPERTY    | 0+       |                                   |
   |   X-PROPERTY       | 0+       |                                   |
   |   ATTENDEE         | 0        |                                   |
   |   EXDATE           | 0        |                                   |
   |   RECURRENCE-ID    | 0        |                                   |
   |   REQUEST-STATUS   | 0        |                                   |
   |   RDATE            | 0        |                                   |
   |   RRULE            | 0        |                                   |
   |                    |          |                                   |
   |   VALARM           | 0+       |                                   |
   |                    |          |                                   |
   | VTIMEZONE          | 0 or 1   | MUST be present if any date/time  |
   |                    |          | refers to a timezone.             |
   |                    |          |                                   |
   | IANA-COMPONENT     | 0+       |                                   |
   | X-COMPONENT        | 0+       |                                   |
Top   ToC   RFC5546 - Page 66
   |                    |          |                                   |
   | VEVENT             | 0        |                                   |
   |                    |          |                                   |
   | VFREEBUSY          | 0        |                                   |
   |                    |          |                                   |
   | VTODO              | 0        |                                   |
   +--------------------+----------+-----------------------------------+

3.5.3. CANCEL

The "CANCEL" method in a "VJOURNAL" calendar component is used to send a cancellation notice of an existing journal entry. The message is sent by the "Organizer" of a journal entry. For a recurring journal entry, either the whole journal entry or instances of a journal entry may be cancelled. To cancel the complete range of a recurring journal entry, the "UID" property value for the journal entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of the journal entry, the "RECURRENCE-ID" property value for the journal entry MUST be specified in the "CANCEL" method. There are two options for canceling a sequence of instances of a recurring "VJOURNAL" calendar component: a. The "RECURRENCE-ID" property for an instance in the sequence MUST be specified with the "RANGE" property parameter value of "THISANDFUTURE" to indicate cancellation of the specified "VJOURNAL" calendar component and all instances after. b. Individual recurrence instances may be cancelled by specifying multiple "VJOURNAL" components each with a "RECURRENCE-ID" property corresponding to one of the instances to be cancelled. When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be incremented as described in Section 2.1.4. This method type is an iCalendar object that conforms to the following property constraints:
Top   ToC   RFC5546 - Page 67
             +-----------------------------------------------+
             | Constraints for a METHOD:CANCEL of a VJOURNAL |
             +-----------------------------------------------+

   +--------------------+----------+-----------------------------------+
   | Component/Property | Presence | Comment                           |
   +--------------------+----------+-----------------------------------+
   | METHOD             | 1        | MUST be CANCEL.                   |
   |                    |          |                                   |
   | VJOURNAL           | 1+       | All MUST have the same UID.       |
   |   DTSTAMP          | 1        |                                   |
   |   ORGANIZER        | 1        |                                   |
   |   SEQUENCE         | 1        |                                   |
   |   UID              | 1        | MUST be the UID of the original   |
   |                    |          | REQUEST.                          |
   |   ATTACH           | 0+       |                                   |
   |   ATTENDEE         | 0        |                                   |
   |   CATEGORIES       | 0+       |                                   |
   |   CLASS            | 0 or 1   |                                   |
   |   COMMENT          | 0+       |                                   |
   |   CONTACT          | 0+       |                                   |
   |   CREATED          | 0 or 1   |                                   |
   |   DESCRIPTION      | 0 or 1   |                                   |
   |   DTSTART          | 0 or 1   |                                   |
   |   EXDATE           | 0+       |                                   |
   |   LAST-MODIFIED    | 0 or 1   |                                   |
   |   RDATE            | 0+       |                                   |
   |   RECURRENCE-ID    | 0 or 1   | Only if referring to an instance  |
   |                    |          | of a recurring calendar           |
   |                    |          | component.  Otherwise, it MUST    |
   |                    |          | NOT be present.                   |
   |   RELATED-TO       | 0+       |                                   |
   |   RRULE            | 0 or 1   |                                   |
   |   STATUS           | 0 or 1   | MAY be present; MUST be CANCELLED |
   |                    |          | if present.                       |
   |   SUMMARY          | 0 or 1   |                                   |
   |   URL              | 0 or 1   |                                   |
   |   IANA-PROPERTY    | 0+       |                                   |
   |   X-PROPERTY       | 0+       |                                   |
   |   REQUEST-STATUS   | 0        |                                   |
   |                    |          |                                   |
   |   VALARM           | 0        |                                   |
   |                    |          |                                   |
   | VTIMEZONE          | 0+       | MUST be present if any date/time  |
   |                    |          | refers to a timezone.             |
   |                    |          |                                   |
   | IANA-COMPONENT     | 0+       |                                   |
   | X-COMPONENT        | 0+       |                                   |
Top   ToC   RFC5546 - Page 68
   |                    |          |                                   |
   | VEVENT             | 0        |                                   |
   |                    |          |                                   |
   | VFREEBUSY          | 0        |                                   |
   |                    |          |                                   |
   | VTODO              | 0        |                                   |
   +--------------------+----------+-----------------------------------+

3.6. Status Replies

The "REQUEST-STATUS" property is used to convey status information about a "REPLY", "COUNTER", or "DECLINECOUNTER" iTIP message. The codes listed in the table below SHOULD be used. If the "REQUEST- STATUS" property is not present in one of these iTIP messages, then a status code of "2.0" (success) MUST be assumed. This specification adds a new IANA registry for "REQUEST-STATUS" property values, as defined in Section 7, which includes a new registration template for defining the specific components of the "REQUEST-STATUS" property value. Additional codes MAY be used, provided the process described in Section 8.2.1 of [RFC5545] is used to register them. This specification allows for multiple "REQUEST-STATUS" properties to be returned in iCalendar components in the appropriate iTIP messages. When multiple "REQUEST-STATUS" properties are present, the following restrictions apply: 1. Within any one component, the "top-level" numeric value of the "short return status code" MUST be the same for all "REQUEST- STATUS" properties, i.e., there cannot be a mixture of, e.g., 2.xx and 5.xx codes within a single component. 2. Across all components in the iTIP message, the following applies: A. If any one component would have a 5.xx code, then either all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 5.xx code is not appropriate for those components. B. Otherwise, if any one component would have a 3.xx code, then either all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. C. 2.xx and 4.xx codes can be used in different components, provided that each component follows the restriction in (1) above.
Top   ToC   RFC5546 - Page 69
   The following "REQUEST-STATUS" codes are defined (any "Offending
   Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
   field):

3.6.1. Status Code 2.0

Status Code: 2.0 Status Description: Success. Status Exception Data: None. Description: iTIP operation succeeded.

3.6.2. Status Code 2.1

Status Code: 2.1 Status Description: Success, but fallback taken on one or more property values. Status Exception Data: Property name and value MAY be specified. Description: iTIP operation succeeded with fallback on one or more property values.

3.6.3. Status Code 2.2

Status Code: 2.2 Status Description: Success; invalid property ignored. Status Exception Data: Property name MAY be specified. Description: iTIP operation succeeded but a property was ignored.

3.6.4. Status Code 2.3

Status Code: 2.3 Status Description: Success; invalid property parameter ignored. Status Exception Data: Property parameter name and value MAY be specified. Description: iTIP operation succeeded but a property parameter was ignored because it was invalid.
Top   ToC   RFC5546 - Page 70

3.6.5. Status Code 2.4

Status Code: 2.4 Status Description: Success; unknown, non-standard property ignored. Status Exception Data: Non-standard property name MAY be specified. Description: iTIP operation succeeded but a property parameter was ignored because it was unknown.

3.6.6. Status Code 2.5

Status Code: 2.5 Status Description: Success; unknown, non-standard property value ignored. Status Exception Data: Property and non-standard value MAY be specified. Description: iTIP operation succeeded but a property was ignored because its value was unknown.

3.6.7. Status Code 2.6

Status Code: 2.6 Status Description: Success; invalid calendar component ignored. Status Exception Data: Calendar component sentinel (e.g., BEGIN: ALARM) MAY be specified. Description: iTIP operation succeeded but a component was ignored because it was invalid.

3.6.8. Status Code 2.7

Status Code: 2.7 Status Description: Success; request forwarded to Calendar User. Status Exception Data: Original and forwarded calendar user addresses MAY be specified. Description: iTIP operation succeeded, and the request was forwarded to another Calendar User.
Top   ToC   RFC5546 - Page 71

3.6.9. Status Code 2.8

Status Code: 2.8 Status Description: Success; repeating event ignored. Scheduled as a single component. Status Exception Data: RRULE or RDATE property name and value MAY be specified. Description: iTIP operation succeeded but a repeating event was truncated to a single instance.

3.6.10. Status Code 2.9

Status Code: 2.9 Status Description: Success; truncated end date time to date boundary. Status Exception Data: DTEND property value MAY be specified. Description: iTIP operation succeeded but the end time was truncated to a date boundary.

3.6.11. Status Code 2.10

Status Code: 2.10 Status Description: Success; repeating VTODO ignored. Scheduled as a single VTODO. Status Exception Data: RRULE or RDATE property name and value MAY be specified. Description: iTIP operation succeeded but a repeating to-do was truncated to a single instance.
Top   ToC   RFC5546 - Page 72

3.6.12. Status Code 2.11

Status Code: 2.11 Status Description: Success; unbounded RRULE clipped at some finite number of instances. Status Exception Data: RRULE property name and value MAY be specified. Number of instances MAY also be specified. Description: iTIP operation succeeded but an unbounded repeating object was clipped to a finite number of instances.

3.6.13. Status Code 3.0

Status Code: 3.0 Status Description: Invalid property name. Status Exception Data: Property name MAY be specified. Description: iTIP operation failed because of an invalid property name.

3.6.14. Status Code 3.1

Status Code: 3.1 Status Description: Invalid property value. Status Exception Data: Property name and value MAY be specified. Description: iTIP operation failed because of an invalid property value.

3.6.15. Status Code 3.2

Status Code: 3.2 Status Description: Invalid property parameter. Status Exception Data: Property parameter name and value MAY be specified. Description: iTIP operation failed because of an invalid property parameter.
Top   ToC   RFC5546 - Page 73

3.6.16. Status Code 3.3

Status Code: 3.3 Status Description: Invalid property parameter value. Status Exception Data: Property parameter name and value MAY be specified. Description: iTIP operation failed because of an invalid property parameter value.

3.6.17. Status Code 3.4

Status Code: 3.4 Status Description: Invalid calendar component sequence. Status Exception Data: Calendar component sentinel MAY be specified (e.g., BEGIN:VTIMEZONE). Description: iTIP operation failed because of an invalid component.

3.6.18. Status Code 3.5

Status Code: 3.5 Status Description: Invalid date or time. Status Exception Data: Date/time value(s) MAY be specified. Description: iTIP operation failed because of an invalid date or time property.

3.6.19. Status Code 3.6

Status Code: 3.6 Status Description: Invalid rule. Status Exception Data: RRULE property value MAY be specified. Description: iTIP operation failed because of an invalid rule property.
Top   ToC   RFC5546 - Page 74

3.6.20. Status Code 3.7

Status Code: 3.7 Status Description: Invalid Calendar User. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because of an invalid ATTENDEE property.

3.6.21. Status Code 3.8

Status Code: 3.8 Status Description: No authority. Status Exception Data: METHOD and ATTENDEE property values MAY be specified. Description: iTIP operation failed because an Attendee does not have suitable privileges for the operation.

3.6.22. Status Code 3.9

Status Code: 3.9 Status Description: Unsupported version. Status Exception Data: VERSION property name and value MAY be specified. Description: iTIP operation failed because the calendar data version is not supported.

3.6.23. Status Code 3.10

Status Code: 3.10 Status Description: Request entity too large. Status Exception Data: None. Description: iTIP operation failed because the calendar data was too large.
Top   ToC   RFC5546 - Page 75

3.6.24. Status Code 3.11

Status Code: 3.11 Status Description: Required component or property missing. Status Exception Data: Component or property name MAY be specified. Description: iTIP operation failed because the calendar data did not contain a required property or component.

3.6.25. Status Code 3.12

Status Code: 3.12 Status Description: Unknown component or property found. Status Exception Data: Component or property name MAY be specified. Description: iTIP operation failed because the calendar data contained an unknown property or component.

3.6.26. Status Code 3.13

Status Code: 3.13 Status Description: Unsupported component or property found. Status Exception Data: Component or property name MAY be specified. Description: iTIP operation failed because the calendar data contained an unsupported property or component.

3.6.27. Status Code 3.14

Status Code: 3.14 Status Description: Unsupported capability. Status Exception Data: METHOD or action MAY be specified. Description: iTIP operation failed because the operation is not supported.
Top   ToC   RFC5546 - Page 76

3.6.28. Status Code 4.0

Status Code: 4.0 Status Description: Event conflict. Date/time is busy. Status Exception Data: DTSTART and DTEND property names and values MAY be specified. Description: iTIP operation failed because the event overlaps the date and time of another event.

3.6.29. Status Code 5.0

Status Code: 5.0 Status Description: Request not supported. Status Exception Data: METHOD property value MAY be specified. Description: iTIP operation failed because the operation is not supported.

3.6.30. Status Code 5.1

Status Code: 5.1 Status Description: Service unavailable. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because scheduling is not active.

3.6.31. Status Code 5.2

Status Code: 5.2 Status Description: Invalid calendar service. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because there is no scheduling capability.
Top   ToC   RFC5546 - Page 77

3.6.32. Status Code 5.3

Status Code: 5.3 Status Description: No scheduling support for user. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because scheduling is not enabled for an Attendee.

3.7. Implementation Considerations

3.7.1. Working With Recurrence Instances

iCalendar includes a recurrence grammar to represent recurring events. The benefit of such a grammar is the ability to represent a number of events in a single object. However, while this simplifies creation of a recurring event, meeting instances still need to be referenced. For instance, an "Attendee" may decline the third instance of a recurring Friday event. Similarly, the "Organizer" may change the time or location to a single instance of the recurring event. Since implementations may elect to store recurring events as either a single event object or a collection of discrete, related event objects, the protocol is designed so that each recurring instance may be both referenced and versioned. Hence, implementations that choose to maintain per-instance properties (such as "ATTENDEE" property "PARTSTAT" parameter) may do so. However, the protocol does not require per-instance recognition unless the instance itself must be renegotiated. The scenarios for recurrence instance referencing are listed below. For purposes of simplification, a change to an event refers to a "trigger property." That is, a property that has a substantive effect on the meeting itself, such as start time, location, due date (for "VTODO" calendar components), and possibly description. "Organizer"-initiated actions: o deletes or changes a single instance of a recurring event o makes changes that affect all future instances o makes changes that affect all previous instances o deletes or modifies a previously changed instance
Top   ToC   RFC5546 - Page 78
   "Attendee"-initiated actions:

   o  changes status for a particular recurrence instance

   o  sends a "COUNTER" for a particular recurrence instance

   An instance of a recurring event is assigned a unique identification,
   "RECURRENCE-ID" property, when that instance is renegotiated.
   Negotiation may be necessary when a substantive change to the event
   or to-do has been made (such as changing the start time, end time,
   due date, or location).  The "Organizer" can identify a specific
   recurrence instance using the "RECURRENCE-ID" property.  The property
   value is equal to the date/time of the instance.  If the "Organizer"
   wishes to change the "DTSTART", the original, unmodified "DTSTART"
   value of the instance is used as the value "RECURRENCE-ID" property,
   and the new "DTSTART" and "DTEND" values reflect the change.

3.7.2. Attendee Property Considerations

The "ORGANIZER" property is required on published events, to-dos, and journal entries for two reasons. First, only the "Organizer" is allowed to update and redistribute an event or to-do component. It follows that the "ORGANIZER" property MUST be present in the event, to-do, or journal entry component so that the CUA has a basis for authorizing an update. Second, it is prudent to provide a point of contact for anyone who receives a published component, in case of problems. Email addresses that correspond to groups of "Calendar Users" could be specified as a mailto: URI [RFC2368] calendar user address. Sending email to such an address results in email being sent to multiple recipients. Such an address may be used as the value of an "ATTENDEE" property. Thus, it is possible that the recipient of a "REQUEST" does not appear explicitly in the list. It is recommended that the general approach to finding a "Calendar User" in an "Attendee" list be as follows: 1. Search for the "Calendar User" in the "Attendee" list where "CUTYPE=INDIVIDUAL" 2. Failing (1), look for "Attendees" where "CUTYPE=GROUP" or "CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" is a member of one of these groups. If so, the "REPLY" method sent to the "Organizer" MUST contain a new "ATTENDEE" property in which: * the "TYPE" property parameter is set to INDIVIDUAL
Top   ToC   RFC5546 - Page 79
       *  the "MEMBER" property parameter is set to the name of the
          group

   3.  Failing (2), the CUA MAY ignore or accept the request as the
       "Calendar User" wishes.

3.7.3. Extension Tokens

To make iCalendar objects extensible, new component, property, or property parameters can be used. Two types of extensions are defined by [RFC5545]: IANA-registered tokens ("iana-token") and experimental use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY use them in replies. A client MAY save "x-name's" and MAY use them in replies. When delegating or forwarding messages to other CUs, a client SHOULD include "iana-token's" and "x-names's".

4. Examples

4.1. Published Event Examples

In the calendaring and scheduling context, publication refers to the one-way transfer of event information. Consumers of published events simply incorporate the event into a calendar. No reply is expected. Individual "A" publishes an event. Individual "B" reads the event and incorporates it into their calendar. Events are published in several ways, including embedding the event as an object in a web page, emailing the event to a distribution list, or posting the event to a newsgroup. The table below illustrates the sequence of events between the publisher and the consumers of a published event. +----------------+-----------------------+--------------------------+ | Action | Organizer | Receiver | +----------------+-----------------------+--------------------------+ | Publish an | "A" sends or posts a | "B" reads a published | | event | PUBLISH message. | event. | | | | | | Publish an | "A" sends or posts a | "B" reads the updated | | updated event | PUBLISH message. | event. | | | | | | Cancel a | "A" sends or posts a | "B" reads the canceled | | published | CANCEL message. | event publication. | | event | | | +----------------+-----------------------+--------------------------+
Top   ToC   RFC5546 - Page 80

4.1.1. A Minimal Published Event

The iCalendar object below describes a single event that begins on July 1, 1997 at 20:00 UTC. This event contains the minimum set of properties for a "PUBLISH" for a "VEVENT" calendar component. BEGIN:VCALENDAR METHOD:PUBLISH PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTART:19970701T200000Z DTSTAMP:19970611T190000Z SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:0981234-1234234-23@example.com END:VEVENT END:VCALENDAR

4.1.2. Changing a Published Event

The iCalendar object below describes an update to the event described in Section 4.1.1; the time has been changed, an end time has been added, and the sequence number has been adjusted. BEGIN:VCALENDAR METHOD:PUBLISH VERSION:2.0 PRODID:-//Example/ExampleCalendarClient//EN BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTAMP:19970612T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z SEQUENCE:1 UID:0981234-1234234-23@example.com SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES END:VEVENT END:VCALENDAR The "UID" property is used by the client to identify the event. The "SEQUENCE" property indicates that this is a change to the event. The event with a matching "UID" and sequence number 0 is superseded by this event. The "SEQUENCE" property provides a reliable way to distinguish different versions of the same event. Each time an event is published, its sequence number is incremented. If a client receives
Top   ToC   RFC5546 - Page 81
   an event with a sequence number 5 and finds it has the same event
   with sequence number 2, the event SHOULD be updated.  However, if the
   client received an event with sequence number 2 and finds it already
   has sequence number 5 of the same event, the event MUST NOT be
   updated.

4.1.3. Canceling a Published Event

The iCalendar object below cancels the event described in Section 4.1.1. This cancels the event with "SEQUENCE" property of 0, 1, and 2. BEGIN:VCALENDAR METHOD:CANCEL VERSION:2.0 PRODID:-//Example/ExampleCalendarClient//EN BEGIN:VEVENT ORGANIZER:mailto:a@example.com COMMENT:DUKES forfeit the game SEQUENCE:2 UID:0981234-1234234-23@example.com DTSTAMP:19970613T190000Z END:VEVENT END:VCALENDAR

4.1.4. A Rich Published Event

This example describes the same event as in Section 4.1.1, but in much greater detail. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:PUBLISH SCALE:GREGORIAN VERSION:2.0 BEGIN:VTIMEZONE TZID:America-Chicago TZURL:http://example.com/tz/America-Chicago BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 TZNAME:CST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
Top   ToC   RFC5546 - Page 82
      TZOFFSETFROM:-0600
      TZOFFSETTO:-0500
      TZNAME:CDT
      END:DAYLIGHT
      END:VTIMEZONE
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTACH:http://www.example.com/
      CATEGORIES:SPORTS EVENT,ENTERTAINMENT
      CLASS:PRIVATE
      DESCRIPTION:MIDWAY STADIUM\n
       Big time game.  MUST see.\n
       Expected duration:2 hours\n
      DTEND;TZID=America-Chicago:19970701T180000
      DTSTART;TZID=America-Chicago:19970702T160000
      DTSTAMP:19970614T190000Z
      STATUS:CONFIRMED
      LOCATION;VALUE=URI:http://stadium.example.com/
      PRIORITY:2
      RESOURCES:SCOREBOARD
      SEQUENCE:3
      SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
      UID:0981234-1234234-23@example.com
      RELATED-TO:0981234-1234234-14@example.com
      BEGIN:VALARM
      TRIGGER:-PT2H
      ACTION:DISPLAY
      DESCRIPTION:You should be leaving for the game now.
      END:VALARM
      BEGIN:VALARM
      TRIGGER:-PT30M
      ACTION:AUDIO
      END:VALARM
      END:VEVENT
      END:VCALENDAR

   The "RELATED-TO" field contains the "UID" property of a related
   calendar event.  The "SEQUENCE" property 3 indicates that this event
   supersedes versions 0, 1, and 2.
Top   ToC   RFC5546 - Page 83

4.1.5. Anniversaries or Events Attached to Entire Days

This example demonstrates the use of the "VALUE" parameter to tie a "VEVENT" to a day rather than a specific time. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:PUBLISH VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTAMP:19970614T190000Z UID:0981234-1234234-23@example.com DTSTART;VALUE=DATE:19970714 RRULE:FREQ=YEARLY;INTERVAL=1 SUMMARY: Bastille Day END:VEVENT END:VCALENDAR

4.2. Group Event Examples

Group events are distinguished from published events in that they have "Attendees" and there is interaction between the "Attendees" and the "Organizer" with respect to the event. Individual "A" requests a meeting between individuals "A", "B", "C", and "D". Individual "B" confirms attendance to the meeting. Individual "C" declines attendance. Individual "D" tentatively confirms attendance. The following table illustrates the message flow between these individuals. "A", the CU scheduling the meeting, is referenced as the "Organizer".
Top   ToC   RFC5546 - Page 84
   +--------------+-----------------------+----------------------------+
   | Action       | "Organizer"           | Attendee                   |
   +--------------+-----------------------+----------------------------+
   | Initiate a   | "A" sends a REQUEST   |                            |
   | meeting      | message to "B", "C",  |                            |
   | request      | and "D".              |                            |
   |              |                       |                            |
   | Accept the   |                       | "B" sends a REPLY message  |
   | meeting      |                       | to "A" with its ATTENDEE   |
   | request      |                       | PARTSTAT parameter set to  |
   |              |                       | ACCEPTED.                  |
   |              |                       |                            |
   | Decline the  |                       | "C" sends a REPLY message  |
   | meeting      |                       | to "A" with its ATTENDEE   |
   | request      |                       | PARTSTAT parameter set to  |
   |              |                       | DECLINED.                  |
   |              |                       |                            |
   | Tentatively  |                       | "D" sends a REPLY message  |
   | accept the   |                       | to "A" with its ATTENDEE   |
   | meeting      |                       | PARTSTAT parameter set to  |
   | request      |                       | TENTATIVE.                 |
   |              |                       |                            |
   | Confirm      | "A" sends a REQUEST   |                            |
   | meeting      | message to "B" and    |                            |
   | status with  | "D" with updated      |                            |
   | Attendees    | information.          |                            |
   +--------------+-----------------------+----------------------------+

4.2.1. A Group Event Request

A sample meeting request is sent from "A" to "B", "C", and "D". "E" is also sent a copy of the request but is not expected to attend and need not reply. "E" illustrates how CUAs might implement an "FYI"- type feature. Note the use of the "ROLE" parameter. The default value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not be enumerated. In this case, we are using the value "NON- PARTICIPANT" to indicate "E" is a non-attending CU. The parameter is not needed on other "Attendees" since "PARTICIPANT" is the default value. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com
Top   ToC   RFC5546 - Page 85
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
      ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com
      ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
      DTSTAMP:19970611T190000Z
      DTSTART:19970701T200000Z
      DTEND:19970701T2100000Z
      SUMMARY:Conference
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.2.2. Reply to a Group Event Request

"Attendee" "B" accepts the meeting. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com ORGANIZER:mailto:a@example.com UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970612T190000Z END:VEVENT END:VCALENDAR "B" could have declined the meeting or indicated tentative acceptance by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in successful transactions.

4.2.3. Update an Event

The event is moved to a different time. The combination of the "UID" property (unchanged) and the "SEQUENCE" (bumped to 1) properties indicate the update. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT
Top   ToC   RFC5546 - Page 86
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
      ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
       CUTYPE=ROOM:mailto:conf@example.com
      ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
      DTSTART:19970701T180000Z
      DTEND:19970701T190000Z
      SUMMARY:Phone Conference
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:1
      DTSTAMP:19970613T190000Z
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.2.4. Countering an Event Proposal

"A" sends a "REQUEST" to "B" and "C". "B" makes a counter proposal to "A" to change the time and location. "A" sends the following "REQUEST": BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com DTSTART:19970701T190000Z DTEND:19970701T200000Z SUMMARY:Discuss the Merits of the election results LOCATION:Green Conference Room UID:calsrv.example.com-873970198738777a@example.com SEQUENCE:0 DTSTAMP:19970611T190000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
Top   ToC   RFC5546 - Page 87
   "B" sends "COUNTER" to "A", requesting changes to time and place.
   "B" uses the "COMMENT" property to communicate a rationale for the
   change.  Note that the "SEQUENCE" property is not incremented on a
   "COUNTER".

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:COUNTER
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
      DTSTART:19970701T160000Z
      DTEND:19970701T170000Z
      DTSTAMP:19970612T190000Z
      SUMMARY:Discuss the Merits of the election results
      LOCATION:Blue Conference Room
      COMMENT:This time works much better and I think the big conference
       room is too big
      UID:calsrv.example.com-873970198738777a@example.com
      SEQUENCE:0
      END:VEVENT
      END:VCALENDAR

   "A" accepts the changes from "B".  To accept a counter proposal, the
   "Organizer" sends a new event "REQUEST" with an incremented sequence
   number.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REQUEST
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
      DTSTAMP:19970613T190000Z
      DTSTART:19970701T160000Z
      DTEND:19970701T170000Z
      SUMMARY:Discuss the Merits of the election results - changed to
       meet B's schedule
      LOCATION:Blue Conference Room
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:1
      STATUS:CONFIRMED
Top   ToC   RFC5546 - Page 88
      END:VEVENT
      END:VCALENDAR

   Instead, "A" rejects "B's" counter proposal.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:DECLINECOUNTER
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      COMMENT:Sorry, I cannot change this meeting time
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      DTSTAMP:19970614T190000Z
      END:VEVENT
      END:VCALENDAR

4.2.5. Delegating an Event

When delegating an event request to another "Calendar User", the "Delegator" must both update the "Organizer" with a "REPLY" and send a request to the "Delegate". There is currently no protocol limitation to delegation depth. It is possible for the original delegate to delegate the meeting to someone else, and so on. When a request is delegated from one CUA to another, there are a number of responsibilities required of the "Delegator". The "Delegator" MUST: o Send a "REPLY" to the "Organizer" with the following updates: A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter is set to "DELEGATED" and the "DELEGATED-TO" parameter is set to the address of the "Delegate". B. Add an additional "ATTENDEE" property for the "Delegate" with the "DELEGATED-FROM" property parameter set to the "Delegator". C. Indicate whether they want to continue to receive updates when the "Organizer" sends out updated versions of the event. Setting the "RSVP" property parameter to "TRUE" will cause the updates to be sent; setting it to "FALSE" causes no further updates to be sent. Note that in either case, if the "Delegate" declines the invitation, the "Delegator" will be notified.
Top   ToC   RFC5546 - Page 89
   o  The "Delegator" MUST also send a copy of the original "REQUEST"
      method to the "Delegate", with changes (A) and (B), as detailed
      above applied.

   If the "Delegate" declines the meeting, the "Organizer" MUST send an
   update "REQUEST" to the "Delegator" so that the "Delegator" may elect
   to delegate the "REQUEST" to another CUA.

   +----------------+-----------------+--------------------------------+
   | Action         | "Organizer"     | Attendee                       |
   +----------------+-----------------+--------------------------------+
   | Initiate a     | "A" sends a     |                                |
   | meeting        | REQUEST message |                                |
   | request        | to "B" and "C". |                                |
   |                |                 |                                |
   | Delegate: "C"  |                 | "C" sends a REPLY to "A" with  |
   | delegates to   |                 | the ATTENDEE PARTSTAT          |
   | "E"            |                 | parameter set to DELEGATED and |
   |                |                 | with a new ATTENDEE property   |
   |                |                 | for "E".  "E's" ATTENDEE       |
   |                |                 | DELEGATED-FROM parameter is    |
   |                |                 | set to "C".  "C's" ATTENDEE    |
   |                |                 | DELEGATED-TO parameter is set  |
   |                |                 | to "E".  "C" sends REQUEST     |
   |                |                 | message to "E" with the        |
   |                |                 | original meeting request       |
   |                |                 | information.  The PARTSTAT     |
   |                |                 | property parameter for "C" is  |
   |                |                 | set to DELEGATED and the       |
   |                |                 | DELEGATED-TO parameter is set  |
   |                |                 | to the address of "E".  An     |
   |                |                 | ATTENDEE property is added for |
   |                |                 | "E" and the DELEGATED-FROM     |
   |                |                 | parameter is set to the        |
   |                |                 | address of "C".                |
   |                |                 |                                |
   | Confirm        |                 | "E" sends REPLY message to     |
   | meeting        |                 | "A", and optionally to "C",    |
   | attendance     |                 | with its PARTSTAT property     |
   |                |                 | parameter set to ACCEPTED.     |
   |                |                 |                                |
   | Optional:      | "A" sends       |                                |
   | Redistribute   | REQUEST message |                                |
   | meeting to     | to "B", "C",    |                                |
   | Attendees      | and "E".        |                                |
   +----------------+-----------------+--------------------------------+
Top   ToC   RFC5546 - Page 90
   "C" responds to the "Organizer".

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REPLY
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
       TO="mailto:e@example.com":mailto:c@example.com
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      REQUEST-STATUS:2.0;Success
      DTSTAMP:19970611T190000Z
      END:VEVENT
      END:VCALENDAR

   "Attendee" "C" delegates presence at the meeting to "E".

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REQUEST
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
       TO="mailto:e@example.com":mailto:c@example.com
      ATTENDEE;RSVP=TRUE;
       DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
      DTSTART:19970701T180000Z
      DTEND:19970701T200000Z
      SUMMARY:Phone Conference
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      STATUS:CONFIRMED
      DTSTAMP:19970611T190000Z
      END:VEVENT
      END:VCALENDAR

4.2.6. Delegate Accepts the Meeting

To accept a delegated meeting, the delegate, "E", sends the following message to "A" and "C". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0
Top   ToC   RFC5546 - Page 91
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
       FROM="mailto:c@example.com":mailto:e@example.com
      ATTENDEE;PARTSTAT=DELEGATED;
       DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      REQUEST-STATUS:2.0;Success
      DTSTAMP:19970614T190000Z
      END:VEVENT
      END:VCALENDAR

4.2.7. Delegate Declines the Meeting

In this example, the "Delegate" declines the meeting request and sets the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" parameter of the "Delegate" set to "DECLINED". This lets the "Delegator" know that the "Delegate" has declined and provides an opportunity to the "Delegator" to either accept the request or delegate it to another CU. "E" responds to "A" and "C". Note the use of the "COMMENT" property "E" uses to indicate why the delegation was declined. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=DELEGATED; DELEGATED-TO="mailto:e@example.com":mailto:c@example.com ATTENDEE;PARTSTAT=DECLINED; DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com COMMENT:Sorry, I will be out of town at that time. UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970614T190000Z END:VEVENT END:VCALENDAR "A" resends the "REQUEST" method to "C". "A" may also wish to express the fact that the item was delegated in the "COMMENT" property.
Top   ToC   RFC5546 - Page 92
      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REQUEST
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;PARTSTAT=DECLINED;
       DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
      ATTENDEE;RSVP=TRUE:mailto:c@example.com
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:0
      SUMMARY:Phone Conference
      DTSTART:19970701T180000Z
      DTEND:19970701T200000Z
      DTSTAMP:19970614T200000Z
      COMMENT:DELEGATE (ATTENDEE mailto:e@example.com) DECLINED YOUR
       INVITATION
      END:VEVENT
      END:VCALENDAR

4.2.8. Forwarding an Event Request

The protocol does not prevent an "Attendee" from "forwarding" a "VEVENT" calendar component to other "Calendar Users". Forwarding differs from delegation in that the forwarded "Calendar User" (often referred to as a "Party Crasher") does not replace the forwarding "Calendar User". Implementations are not required to add the "Party Crasher" to the "Attendee" list, and hence there is no guarantee that a "Party Crasher" will receive additional updates to the event. The forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the "Attendee" list. The "Organizer" MAY add the forwarded "Calendar User" to the "Attendee" list.

4.2.9. Cancel a Group Event

Individual "A" requests a meeting between individuals "A", "B", "C", and "D". Individual "B" declines attendance to the meeting. Individual "A" decides to cancel the meeting. The following table illustrates the sequence of messages that would be exchanged between these individuals. Messages related to a previously canceled event ("SEQUENCE" property value is less than the "SEQUENCE" property value of the "CANCEL" message) MUST be ignored.
Top   ToC   RFC5546 - Page 93
   +-------------+---------------------+-------------------------------+
   | Action      | Organizer           | Attendee                      |
   +-------------+---------------------+-------------------------------+
   | Initiate a  | "A" sends a REQUEST |                               |
   | meeting     | message to "B",     |                               |
   | request     | "C", and "D".       |                               |
   |             |                     |                               |
   | Decline the |                     | "B" sends a REPLY message to  |
   | meeting     |                     | "A" with its PARTSTAT         |
   | request     |                     | parameter set to DECLINED.    |
   |             |                     |                               |
   | Cancel the  | "A" sends a CANCEL  |                               |
   | meeting     | message to "B",     |                               |
   |             | "C", and "D".       |                               |
   +-------------+---------------------+-------------------------------+

   This example shows how "A" cancels the event.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:CANCEL
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com
      ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
      ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
      COMMENT:Mr. B cannot attend.  It's raining.  Lets cancel.
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:1
      STATUS:CANCELLED
      DTSTAMP:19970613T190000Z
      END:VEVENT
      END:VCALENDAR

4.2.10. Removing Attendees

"A" wants to remove "B" from a meeting. This is done by sending a "CANCEL" to "B" and removing "B" from the "Attendee" list in the master copy of the event.
Top   ToC   RFC5546 - Page 94
   +--------------------+-----------------------------------+----------+
   | Action             | Organizer                         | Attendee |
   +--------------------+-----------------------------------+----------+
   | Remove "B" as an   | "A" sends a CANCEL message to     |          |
   | Attendee           | "B".                              |          |
   |                    |                                   |          |
   | Update the master  | "A" optionally sends the updated  |          |
   | copy of the event  | event to the remaining Attendees. |          |
   +--------------------+-----------------------------------+----------+

   The original meeting includes "A", "B", "C", and "D".  The example
   below shows the "CANCEL" that "A" sends to "B".  Note that in the
   example below, the "STATUS" property is omitted.  This is used when
   the meeting itself is cancelled and not when the intent is to remove
   an "Attendee" from the event.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:CANCEL
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      COMMENT:You're off the hook for this meeting
      UID:calsrv.example.com-873970198738777@example.com
      DTSTAMP:19970613T193000Z
      SEQUENCE:1
      END:VEVENT
      END:VCALENDAR

   The updated master copy of the event is shown below.  The "Organizer"
   MAY resend the updated event to the remaining "Attendees".  Note that
   "B" has been removed.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REQUEST
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
      ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
      ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com
      ATTENDEE;ROLE=NON-PARTICIPANT;
       RSVP=FALSE:mailto:e@example.com
      DTSTAMP:19970611T190000Z
      DTSTART:19970701T200000Z
Top   ToC   RFC5546 - Page 95
      DTEND:19970701T203000Z
      SUMMARY:Phone Conference
      UID:calsrv.example.com-873970198738777@example.com
      SEQUENCE:2
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.2.11. Replacing the Organizer

The scenario for this example begins with "A" as the "Organizer" for a recurring meeting with "B", "C", and "D". "A" receives a new job offer in another country and drops out of touch. "A" left no forwarding address or way to be reached. Using out-of-band communication, the other "Attendees" eventually learn what has happened and reach an agreement that "B" should become the new "Organizer" for the meeting. To do this, "B" sends out a new version of the event and the other "Attendees" agree to accept "B" as the new "Organizer". "B" also removes "A" from the event. When the "Organizer" is replaced, the "SEQUENCE" property value MUST be incremented. This is the message "B" sends to "C" and "D". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:b@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T203000Z RRULE:FREQ=WEEKLY SUMMARY:Phone Conference UID:123456@example.com SEQUENCE:1 STATUS:CONFIRMED END:VEVENT END:VCALENDAR


(next page on part 5)

Next Section