Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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 5 of 5 – Pages 96 to 133
First   Prev   None

Top   ToC   RFC5546 - Page 96   prevText

4.3. Busy Time Examples

Busy time objects can be used in several ways. First, a CU may request busy time from another CU for a specific range of time. That request can be answered with a busy time "REPLY". Additionally, a CU may simply publish their busy time for a given interval and point other CUs to the published location. The following examples outline both scenarios.

4.3.1. Publish Busy Time

Individual "A" publishes busy time for one week. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VFREEBUSY DTSTAMP:19980101T124100Z ORGANIZER:mailto:a@example.com DTSTART:19980101T124200Z DTEND:19980108T124200Z FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980113T000000Z/19980113T010000Z FREEBUSY:19980115T190000Z/19980115T200000Z FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980116T013000Z/19980116T043000Z END:VFREEBUSY END:VCALENDAR

4.3.2. Request Busy Time

Individual "A" requests busy time from individuals "B" and "C". Individuals "B" and "C" reply with busy time data to individual "A". The following table illustrates the sequence of messages that would be exchanged between these individuals.
Top   ToC   RFC5546 - Page 97
   +---------------------+--------------------+------------------------+
   | Action              | Organizer          | Attendee               |
   +---------------------+--------------------+------------------------+
   | Initiate a busy     | "A" sends REQUEST  |                        |
   | time request        | message to "B" and |                        |
   |                     | "C".               |                        |
   |                     |                    |                        |
   | Reply to the BUSY   |                    | "B" sends a REPLY      |
   | request with BUSY   |                    | message to "A" with    |
   | time data           |                    | busy time data.        |
   +---------------------+--------------------+------------------------+

   "A" sends a "REQUEST" to "B" and "C" for busy time.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REQUEST
      VERSION:2.0
      BEGIN:VFREEBUSY
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      ATTENDEE:mailto:c@example.com
      DTSTAMP:19970613T190000Z
      DTSTART:19970701T080000Z
      DTEND:19970701T200000
      UID:calsrv.example.com-873970198738777@example.com
      END:VFREEBUSY
      END:VCALENDAR

4.3.3. Reply to a Busy Time Request

"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to "A". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:mailto:a@example.com ATTENDEE:mailto:b@example.com DTSTART:19970701T080000Z DTEND:19970701T200000Z UID:calsrv.example.com-873970198738777@example.com FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M DTSTAMP:19970613T190030Z END:VFREEBUSY
Top   ToC   RFC5546 - Page 98
      END:VCALENDAR

   "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.

4.4. Recurring Event and Time Zone Examples

4.4.1. A Recurring Event Spanning Time Zones

This event describes a weekly phone conference. The "Attendees" are each in a different time zone. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTIMEZONE TZID:America-SanJose TZURL:http://example.com/tz/America-SanJose BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED; CUTYPE=INDIVIDUAL:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp DTSTAMP:19970613T190030Z DTSTART;TZID=America-SanJose:19970701T140000 DTEND;TZID=America-SanJose:19970701T150000 RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU RDATE;TZID=America-SanJose:19970910T140000 EXDATE;TZID=America-SanJose:19970909T140000 EXDATE;TZID=America-SanJose:19971028T140000 SUMMARY:Weekly Phone Conference UID:calsrv.example.com-873970198738777@example.com
Top   ToC   RFC5546 - Page 99
      SEQUENCE:0
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

   The first component of this iCalendar object is the time zone
   component.  The "DTSTART" date coincides with the first instance of
   the "RRULE" property.

   The recurring meeting is defined in a particular time zone,
   presumably that of the originator.  The client for each "Attendee"
   has the responsibility of determining the recurrence time in the
   "Attendee's" time zone.

   The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT
   (UTC-7).  "Attendee" B@example.fr is in France, where the local time
   on this date is 9 hours ahead of PDT, or 23:00 CEST (UTC+2).
   "Attendee" C@example.jp is in Japan, where local time is 16 hours
   ahead of PDT, or Wednesday, July 2 at 06:00 JST (UTC+9).  The event
   repeats weekly on Tuesdays (in PST/PDT).  The "RRULE" property
   results in 20 instances.  The last instance falls on Tuesday,
   November 11, 1997 2:00pm PST.  The "RDATE" property adds another
   instance: WED, 10-SEP-1997 2:00 PM PDT.

   There are also two exception dates to the recurrence rule.  The first
   one is:

   o  TUE, 09-SEP-1997 14:00 PDT (UTC-7)

   o  TUE, 09-SEP-1997 23:00 CEST (UTC+2)

   o  WED, 10-SEP-1997 06:00 JST (UTC+9)


   and the second is:

   o  TUE, 28-OCT-1997 14:00 PST (UTC-8)

   o  TUE, 28-OCT-1997 23:00 CET (UTC+1)

   o  WED, 29-OCT-1997 07:00 JST (UTC+9)

4.4.2. Modify a Recurring Instance

In this example, the "Organizer" issues a recurring meeting. Later, the "Organizer" changes an instance of the event by changing the "DTSTART" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request.
Top   ToC   RFC5546 - Page 100
   Original Request:

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:guid-1@example.com
      SEQUENCE:0
      RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      ATTENDEE:mailto:c@example.com
      ATTENDEE:mailto:d@example.com
      DESCRIPTION:IETF-C&S Conference Call
      CLASS:PUBLIC
      SUMMARY:IETF Calendaring Working Group Meeting
      DTSTART:19970601T210000Z
      DTEND:19970601T220000Z
      LOCATION:Conference Call
      DTSTAMP:19970526T083000Z
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

   The event request below is to change the time of a specific instance.
   This changes the July 1st instance to July 3rd.

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:guid-1@example.com
      RECURRENCE-ID:19970701T210000Z
      SEQUENCE:1
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      ATTENDEE:mailto:c@example.com
      ATTENDEE:mailto:d@example.com
      DESCRIPTION:IETF-C&S Conference Call
      CLASS:PUBLIC
      SUMMARY:IETF Calendaring Working Group Meeting
      DTSTART:19970703T210000Z
      DTEND:19970703T220000Z
      LOCATION:Conference Call
Top   ToC   RFC5546 - Page 101
      DTSTAMP:19970626T093000Z
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.4.3. Cancel an Instance

In this example, the "Organizer" of a recurring event deletes the August 1st instance. BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com RECURRENCE-ID:19970801T210000Z SEQUENCE:2 STATUS:CANCELLED DTSTAMP:19970721T093000Z END:VEVENT END:VCALENDAR

4.4.4. Cancel a Recurring Event

In this example, the "Organizer" wishes to cancel the entire recurring event and any exceptions. BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com DTSTAMP:19970721T103000Z STATUS:CANCELLED SEQUENCE:3 END:VEVENT
Top   ToC   RFC5546 - Page 102
      END:VCALENDAR

4.4.5. Change All Future Instances

This example changes the meeting location from a conference call to Seattle, starting September 1 and extending to all future instances. BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com RECURRENCE-ID;THISANDFUTURE:19970901T210000Z SEQUENCE:3 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DESCRIPTION:IETF-C&S Discussion CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970901T210000Z DTEND:19970901T220000Z LOCATION:Building 32, Microsoft, Seattle, WA DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR

4.4.6. Add a New Instance to a Recurring Event

This example adds a one-time additional instance to the recurring event. "Organizer" adds a second July meeting on the 15th. BEGIN:VCALENDAR METHOD:ADD PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:4 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
Top   ToC   RFC5546 - Page 103
      DESCRIPTION:IETF-C&S Conference Call
      CLASS:PUBLIC
      SUMMARY:IETF Calendaring Working Group Meeting
      DTSTART:19970715T210000Z
      DTEND:19970715T220000Z
      LOCATION:Conference Call
      DTSTAMP:19970629T093000Z
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.4.7. Add a New Series of Instances to a Recurring Event

The scenario for this example involves an ongoing meeting, originally set up to occur every Tuesday. The "Organizer" later decides that the meetings need to be on Tuesdays and Thursdays. The original event: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:0 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z LOCATION:The White Room DTSTAMP:19980301T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR The entire event can be rescheduled using a "REQUEST". This is done by using the "UID" of the event to reschedule and including the modified "RRULE". Note that since this is an entire rescheduling of the event, any instance-specific information will be lost, unless explicitly included with the update "REQUEST". BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN
Top   ToC   RFC5546 - Page 104
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:7
      RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980303T210000Z
      DTEND:19980303T220000Z
      DTSTAMP:19980303T193000Z
      LOCATION:The White Room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.4.8. Refreshing a Recurring Event

The next series of examples illustrate how an "Organizer" would respond to a "REFRESH" submitted by an "Attendee" after a series of instance-specific modifications. To convey all instance-specific changes, the "Organizer" must provide the latest event description and the relevant instances. The first three examples show the history, including the initial "VEVENT" request and subsequent instance changes, and finally the "REFRESH". Original Request: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:0 RDATE:19980304T180000Z RDATE:19980311T180000Z RDATE:19980318T180000Z ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com SUMMARY:Review Accounts DTSTART:19980304T180000Z DTEND:19980304T200000Z DTSTAMP:19980303T193000Z LOCATION:Conference Room A STATUS:CONFIRMED
Top   ToC   RFC5546 - Page 105
      END:VEVENT
      END:VCALENDAR

   Organizer changes 2nd instance location and time:

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:1
      RECURRENCE-ID:19980311T180000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980311T160000Z
      DTEND:19980311T180000Z
      DTSTAMP:19980306T193000Z
      LOCATION:The Small conference room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

   Organizer adds a 4th instance of the meeting using the "ADD" method.

      BEGIN:VCALENDAR
      METHOD:ADD
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:2
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980315T180000Z
      DTEND:19980315T200000Z
      DTSTAMP:19980307T193000Z
      LOCATION:Conference Room A
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR
Top   ToC   RFC5546 - Page 106
   If "B" requests a "REFRESH", "A" responds with the following to
   capture all instance-specific data.  In this case, both the initial
   request and an additional "VEVENT" that specifies the instance-
   specific data are included.  Because these are both of the same type
   (they are both "VEVENTS"), they can be conveyed in the same iCalendar
   object.

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:2
      RDATE:19980304T180000Z
      RDATE:19980311T160000Z
      RDATE:19980315T180000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980304T180000Z
      DTEND:19980304T200000Z
      DTSTAMP:19980303T193000Z
      LOCATION:Conference Room A
      STATUS:CONFIRMED
      END:VEVENT
      BEGIN:VEVENT
      SEQUENCE:2
      UID:123456789@example.com
      RECURRENCE-ID:19980311T160000Z
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980311T160000Z
      DTEND:19980304T180000Z
      DTSTAMP:19980306T193000Z
      LOCATION:The Small conference room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

4.4.9. Counter an Instance of a Recurring Event

In this example, one of the "Attendees" counters the "DTSTART" property of the proposed second July meeting.
Top   ToC   RFC5546 - Page 107
      BEGIN:VCALENDAR
      METHOD:COUNTER
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:guid-1@example.com
      RECURRENCE-ID:19970715T210000Z
      SEQUENCE:4
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      ATTENDEE;RSVP=TRUE:mailto:c@example.com
      ATTENDEE;RSVP=TRUE:mailto:d@example.com
      DESCRIPTION:IETF-C&S Conference Call
      CLASS:PUBLIC
      SUMMARY:IETF Calendaring Working Group Meeting
      DTSTART:19970715T220000Z
      DTEND:19970715T230000Z
      LOCATION:Conference Call
      COMMENT:May we bump this by an hour? I have a conflict
      DTSTAMP:19970629T094000Z
      END:VEVENT
      END:VCALENDAR

4.4.10. Error Reply to a Request

The following example illustrates a scenario where a meeting is proposed containing an unsupported property and a bad property. Original Request: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com SEQUENCE:0 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z
Top   ToC   RFC5546 - Page 108
      DTEND:19970601T220000Z
      DTSTAMP:19970602T094000Z
      LOCATION:Conference Call
      STATUS:CONFIRMED
      FOO:BAR
      END:VEVENT
      END:VCALENDAR

   "B" responds to indicate that "RRULE" is not supported and that an
   unrecognized property was encountered.

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REPLY
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      REQUEST-STATUS:3.0;Invalid Property Name;FOO
      UID:guid-1@example.com
      SEQUENCE:0
      DTSTAMP:19970603T094000Z
      END:VEVENT
      END:VCALENDAR

4.5. Group To-Do Examples

Individual "A" creates a group task in which individuals "A", "B", "C", and "D" will participate. Individual "B" confirms acceptance of the task. Individual "C" declines the task. Individual "D" tentatively accepts the task. The following table illustrates the sequence of messages that would be exchanged between these individuals. Individual "A" then issues a "REQUEST" method to obtain the status of the to-do from each participant. The response indicates the individual "Attendee's" completion status. The table below illustrates the message flow.
Top   ToC   RFC5546 - Page 109
   +--------------+------------------------+---------------------------+
   | Action       | Organizer              | Attendee                  |
   +--------------+------------------------+---------------------------+
   | Initiate a   | "A" sends a REQUEST    |                           |
   | to-do        | message to "B", "C",   |                           |
   | request      | and "D".               |                           |
   |              |                        |                           |
   | Accept the   |                        | "B" sends a REPLY message |
   | to-do        |                        | to "A" with its PARTSTAT  |
   | request      |                        | parameter set to          |
   |              |                        | ACCEPTED.                 |
   |              |                        |                           |
   | Decline the  |                        | "C" sends a REPLY message |
   | to-do        |                        | to "A" with its PARTSTAT  |
   | request      |                        | parameter set to          |
   |              |                        | DECLINED.                 |
   |              |                        |                           |
   | Tentatively  |                        | "D" sends a REPLY message |
   | accept the   |                        | to "A" with its PARTSTAT  |
   | to-do        |                        | parameter set to          |
   | request      |                        | TENTATIVE.                |
   |              |                        |                           |
   | Check        | "A" sends a REQUEST    |                           |
   | Attendee     | message to "B" and "D" |                           |
   | completion   | with current           |                           |
   | status       | information.           |                           |
   |              |                        |                           |
   | Attendee     |                        | "B" sends a REPLY message |
   | indicates    |                        | indicating percent        |
   | percent      |                        | complete.                 |
   | complete     |                        |                           |
   |              |                        |                           |
   | Attendee     |                        | "D" sends a REPLY message |
   | indicates    |                        | indicating completion.    |
   | completion   |                        |                           |
   +--------------+------------------------+---------------------------+

4.5.1. A VTODO Request

A sample "REQUEST" for a "VTODO" calendar component that "A" sends to "B", "C", and "D". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com
Top   ToC   RFC5546 - Page 110
      ATTENDEE;ROLE=CHAIR:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      ATTENDEE;RSVP=TRUE:mailto:c@example.com
      ATTENDEE;RSVP=TRUE:mailto:d@example.com
      DTSTART:19970701T170000Z
      DUE:19970722T170000Z
      PRIORITY:1
      SUMMARY:Create the requirements document
      UID:calsrv.example.com-873970198738777-00@example.com
      SEQUENCE:0
      DTSTAMP:19970717T200000Z
      STATUS:NEEDS-ACTION
      END:VTODO
      END:VCALENDAR

4.5.2. A VTODO Reply

"B" accepts the to-do. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com UID:calsrv.example.com-873970198738777-00@example.com COMMENT:I'll send you my input by email SEQUENCE:0 DTSTAMP:19970717T203000Z REQUEST-STATUS:2.0;Success END:VTODO END:VCALENDAR "B" could have declined the "VTODO" or indicated tentative acceptance by setting the "PARTSTAT" property parameter sequence to "DECLINED" or "TENTATIVE", respectively.

4.5.3. A VTODO Request for Updated Status

"A" requests status from all "Attendees". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com
Top   ToC   RFC5546 - Page 111
      ATTENDEE;ROLE=CHAIR:mailto:a@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
      ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
      UID:calsrv.example.com-873970198738777-00@example.com
      SUMMARY:Create the requirements document
      PRIORITY:1
      SEQUENCE:0
      STATUS:IN-PROCESS
      DTSTART:19970701T170000Z
      DTSTAMP:19970717T230000Z
      END:VTODO
      END:VCALENDAR

4.5.4. A Reply: Percent-Complete

A reply indicating the task being worked on and that "B" is 75% complete with "B's" part of the assignment. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com PERCENT-COMPLETE:75 UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z SEQUENCE:0 END:VTODO END:VCALENDAR

4.5.5. A Reply: Completed

A reply indicating that "D" completed "D's" part of the assignment. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z SEQUENCE:0 END:VTODO END:VCALENDAR
Top   ToC   RFC5546 - Page 112

4.5.6. An Updated VTODO Request

"Organizer" "A" resends the "VTODO" calendar component. "A" sets the overall completion for the to-do at 40%. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com DTSTART:19970701T170000Z DUE:19970722T170000Z PRIORITY:1 SUMMARY:Create the requirements document UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:1 DTSTAMP:19970718T100000Z STATUS:IN-PROCESS PERCENT-COMPLETE:40 END:VTODO END:VCALENDAR

4.5.7. Recurring VTODOs

The following examples relate to recurring "VTODO" calendar components.
4.5.7.1. Request for a Recurring VTODO
In this example, "A" sends a recurring "VTODO" calendar component to "B" and "D". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR DTSTART:19980101T100000Z DUE:19980103T100000Z
Top   ToC   RFC5546 - Page 113
      SUMMARY:Send Status Reports to Area Managers
      UID:calsrv.example.com-873970198738777-00@example.com
      SEQUENCE:0
      DTSTAMP:19970717T200000Z
      STATUS:NEEDS-ACTION
      PRIORITY:1
      END:VTODO
      END:VCALENDAR

4.5.7.2. Replying to an Instance of a Recurring VTODO
In this example, "B" updates "A" on a single instance of the "VTODO" calendar component. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com PERCENT-COMPLETE:75 UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z RECURRENCE-ID:19980101T170000Z SEQUENCE:1 END:VTODO END:VCALENDAR

4.6. Journal Examples

The iCalendar object below describes a single journal entry for October 2, 1997. The "RELATED-TO" property references the phone conference event for which minutes were taken. BEGIN:VCALENDAR METHOD:PUBLISH PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VJOURNAL DTSTART:19971002T200000Z DTSTAMP:19970717T233100Z ORGANIZER:mailto:a@example.com SUMMARY:Phone conference minutes DESCRIPTION:The editors meeting was held on October 1, 1997. Details are in the attached document. UID:0981234-1234234-2410@example.com RELATED-TO:0981234-1234234-2402-35@example.com ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
Top   ToC   RFC5546 - Page 114
      END:VJOURNAL
      END:VCALENDAR

4.7. Other Examples

4.7.1. Event Refresh

Refresh the event with a "UID" property value of "guid-1-12345@example.com": BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REFRESH VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com UID:guid-1-12345@example.com DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR

4.7.2. Bad RECURRENCE-ID

Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP message to an "Attendee", there are three cases in which an instance cannot be found. They are: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the iTIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message, then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer
Top   ToC   RFC5546 - Page 115
   version of the component and the "Attendee's" version needs to be
   updated.  Since one or more updates have been missed, the "Attendee"
   SHOULD send a "REFRESH" message to the "Organizer" to get an updated
   version of the event.

   In case (2), something has gone wrong.  Both the "Organizer" and the
   "Attendee" should have the same instances, but the "Attendee" does
   not have the referenced instance.  In this case, the "Attendee"
   SHOULD send a "REFRESH" to the "Organizer" to get an updated version
   of the event.

   In case (3), the limitations of the "Attendee's" CUA makes it
   impossible to match an instance other than the single instance
   scheduled.  In this case, the "Attendee" need not send a "REFRESH" to
   the "Organizer".

   The example below shows a sequence in which an "Attendee" sends a
   "REFRESH" to the "Organizer".

   +-------------------------+--------------------+--------------------+
   | Action                  | Organizer          | Attendee           |
   +-------------------------+--------------------+--------------------+
   | Update an instance      | "A" sends REQUEST  |                    |
   | request                 | message to "B".    |                    |
   |                         |                    |                    |
   | Attendee requests       |                    | "B" sends a        |
   | refresh because         |                    | REFRESH message to |
   | RECURRENCE-ID was not   |                    | "A".               |
   | found                   |                    |                    |
   |                         |                    |                    |
   | Refresh the entire      | "A" sends the      |                    |
   | event                   | latest copy of the |                    |
   |                         | event to "B"       |                    |
   |                         |                    |                    |
   | Attendee handles the    |                    | "B" updates to the |
   | request and updates the |                    | latest copy of the |
   | instance                |                    | meeting.           |
   +-------------------------+--------------------+--------------------+

   Request from "A":

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:example-12345@example.com
      SEQUENCE:3
Top   ToC   RFC5546 - Page 116
      RRULE:FREQ=WEEKLY
      RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      DESCRIPTION:IETF-C&S Conference Call
      SUMMARY:IETF Calendaring Working Group Meeting
      DTSTART:19970801T210000Z
      DTEND:19970801T220000Z
      RECURRENCE-ID:19970809T210000Z
      DTSTAMP:19970726T083000
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

   "B" has the event with "UID" property "example-12345@example.com",
   but "B's" "SEQUENCE" property value is "1" and the event does not
   have an instance at the specified recurrence time.  This means that
   "B" has missed at least one update and needs a new copy of the event.
   "B" requests the latest copy of the event with the following refresh
   message:

      BEGIN:VCALENDAR
      PRODID:-//Example/ExampleCalendarClient//EN
      METHOD:REFRESH
      VERSION:2.0
      BEGIN:VEVENT
      ORGANIZER:mailto:a@example.com
      ATTENDEE:mailto:b@example.com
      UID:example-12345@example.com
      DTSTAMP:19970603T094000
      END:VEVENT
      END:VCALENDAR

5. Application Protocol Fallbacks

5.1. Partial Implementation

Applications that support this specification are not required to support the entire protocol. The following describes how methods and properties SHOULD "fallback" in applications that do not support the complete protocol. If a method or property is not addressed in this section, it may be ignored.
Top   ToC   RFC5546 - Page 117

5.1.1. Event-Related Fallbacks

+----------------+--------------------------------------------------+ | Method | Fallback | +----------------+--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required if recurrences supported; otherwise, | | | reply with a REQUEST-STATUS "2.8; Success, | | | repeating event ignored. Scheduled as a single | | | component", and schedule as a single component. | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with "Not Supported". | | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs; | | | otherwise, reply with "Not Supported". | +----------------+--------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | Event-Related | Fallback | | Components | | +-----------------+-------------------------------------------------+ | VALARM | Reply with "Not Supported". | | VTIMEZONE | Required if any DateTime value refers to a time | | | zone. | +-----------------+-------------------------------------------------+
Top   ToC   RFC5546 - Page 118
   +-----------------+-------------------------------------------------+
   | Component       | Fallback                                        |
   | Property        |                                                 |
   +-----------------+-------------------------------------------------+
   | ATTACH          | Ignore                                          |
   | ATTENDEE        | Required if METHOD is REQUEST; otherwise,       |
   |                 | ignore.                                         |
   | CATEGORIES      | Ignore                                          |
   | CLASS           | Ignore                                          |
   | COMMENT         | Ignore                                          |
   | COMPLETED       | Ignore                                          |
   | CONTACT         | Ignore                                          |
   | CREATED         | Ignore                                          |
   | DESCRIPTION     | Ignore                                          |
   | DURATION        | Required                                        |
   | DTSTAMP         | Required                                        |
   | DTSTART         | Required                                        |
   | DTEND           | Required                                        |
   | EXDATE          | Ignore                                          |
   | GEO             | Ignore                                          |
   | LAST-MODIFIED   | Ignore                                          |
   | LOCATION        | Required                                        |
   | ORGANIZER       | Required if METHOD is REQUEST; otherwise,       |
   |                 | ignore.                                         |
   | PRIORITY        | Ignore                                          |
   | RELATED-TO      | Ignore                                          |
   | RDATE           | Ignore                                          |
   | RRULE           | Ignore - assume the first instance occurs on    |
   |                 | the DTSTART property.  If implemented,          |
   |                 | VTIMEZONE MUST also be implemented.             |
   | RECURRENCE-ID   | Required if RRULE is implemented; otherwise,    |
   |                 | ignore.                                         |
   | REQUEST-STATUS  | Required                                        |
   | RESOURCES       | Ignore                                          |
   | SEQUENCE        | Required                                        |
   | STATUS          | Ignore                                          |
   | SUMMARY         | Ignore                                          |
   | TRANSP          | Required if FREEBUSY is implemented; otherwise, |
   |                 | ignore.                                         |
   | URL             | Ignore                                          |
   | UID             | Required                                        |
   | X-              | Ignore                                          |
   +-----------------+-------------------------------------------------+
Top   ToC   RFC5546 - Page 119

5.1.2. Free/Busy-Related Fallbacks

+---------+---------------------------------------------------------+ | Method | Fallback | +---------+---------------------------------------------------------+ | PUBLISH | Required if freebusy lookups are supported; otherwise, | | | reply with a REQUEST-STATUS "3.14; Unsupported | | | capability". | | REQUEST | Required if freebusy lookups are supported; otherwise, | | | reply with a REQUEST-STATUS "3.14; Unsupported | | | capability". | | REPLY | Required if freebusy lookups are supported; otherwise, | | | reply with a REQUEST-STATUS "3.14; Unsupported | | | capability". | +---------+---------------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | Component | Fallback | | Property | | +-----------------+-------------------------------------------------+ | ATTENDEE | Required if METHOD is REQUEST; otherwise, | | | ignore. | | COMMENT | Ignore | | CONTACT | Ignore | | DTEND | Required | | DTSTAMP | Required | | DTSTART | Required | | DURATION | Ignore | | FREEBUSY | Required | | ORGANIZER | Required if METHOD is REQUEST; otherwise, | | | ignore. | | REQUEST-STATUS | Ignore | | UID | Required | | URL | Ignore | | X- | Ignore | +-----------------+-------------------------------------------------+
Top   ToC   RFC5546 - Page 120

5.1.3. To-Do-Related Fallbacks

+----------------+--------------------------------------------------+ | Method | Fallback | +----------------+--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required if recurrences supported; otherwise, | | | reply with a REQUEST-STATUS "2.8; Success, | | | repeating event ignored. Scheduled as a single | | | component", and schedule as a single component. | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with "Not Supported". | | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented; | | | otherwise, reply with "Not Supported". | +----------------+--------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | To-Do-Related | Fallback | | Components | | +-----------------+-------------------------------------------------+ | VALARM | Reply with "Not Supported". | | VTIMEZONE | Required if any DateTime value refers to a time | | | zone. | +-----------------+-------------------------------------------------+
Top   ToC   RFC5546 - Page 121
   +------------------+------------------------------------------------+
   | Component        | Fallback                                       |
   | Property         |                                                |
   +------------------+------------------------------------------------+
   | ATTACH           | Ignore                                         |
   | ATTENDEE         | Required if METHOD is REQUEST; otherwise,      |
   |                  | ignore.                                        |
   | CATEGORIES       | Ignore                                         |
   | CLASS            | Ignore                                         |
   | COMMENT          | Ignore                                         |
   | COMPLETED        | Required                                       |
   | CONTACT          | Ignore                                         |
   | CREATED          | Ignore                                         |
   | DESCRIPTION      | Required if METHOD is REQUEST; otherwise,      |
   |                  | ignore.                                        |
   | DUE              | Required                                       |
   | DURATION         | Required                                       |
   | DTSTAMP          | Required                                       |
   | DTSTART          | Required                                       |
   | EXDATE           | Ignore - reply with "Not Supported".           |
   | LAST-MODIFIED    | Ignore                                         |
   | LOCATION         | Ignore                                         |
   | ORGANIZER        | Required if METHOD is REQUEST; otherwise,      |
   |                  | ignore.                                        |
   | PERCENT-COMPLETE | Ignore                                         |
   | PRIORITY         | Required                                       |
   | RECURRENCE-ID    | Required if RRULE is implemented; otherwise,   |
   |                  | ignore.                                        |
   | RELATED-TO       | Ignore                                         |
   | REQUEST-STATUS   | Ignore                                         |
   | RDATE            | Ignore                                         |
   | RRULE            | Ignore - assume the first instance occurs on   |
   |                  | the DTSTART property.  If implemented,         |
   |                  | VTIMEZONE MUST also be implemented.            |
   | RESOURCES        | Ignore                                         |
   | SEQUENCE         | Required                                       |
   | STATUS           | Required                                       |
   | SUMMARY          | Ignore                                         |
   | URL              | Ignore                                         |
   | UID              | Required                                       |
   | X-               | Ignore                                         |
   +------------------+------------------------------------------------+
Top   ToC   RFC5546 - Page 122

5.1.4. Journal-Related Fallbacks

+---------+---------------------------------------------------------+ | Method | Fallback | +---------+---------------------------------------------------------+ | PUBLISH | Implementations MAY ignore the METHOD type. The | | | REQUEST-STATUS "3.14; Unsupported capability" MUST be | | | returned. | | ADD | Implementations MAY ignore the METHOD type. The | | | REQUEST-STATUS "3.14; Unsupported capability" MUST be | | | returned. | | CANCEL | Implementations MAY ignore the METHOD type. The | | | REQUEST-STATUS "3.14; Unsupported capability" MUST be | | | returned. | +---------+---------------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | Journal-Related | Fallback | | Components | | +-----------------+-------------------------------------------------+ | VTIMEZONE | Required if any DateTime value refers to a time | | | zone. | +-----------------+-------------------------------------------------+
Top   ToC   RFC5546 - Page 123
   +-----------------+-------------------------------------------------+
   | Component       | Fallback                                        |
   | Property        |                                                 |
   +-----------------+-------------------------------------------------+
   | ATTACH          | Ignore                                          |
   | ATTENDEE        | Ignore                                          |
   | CATEGORIES      | Ignore                                          |
   | CLASS           | Ignore                                          |
   | COMMENT         | Ignore                                          |
   | CONTACT         | Ignore                                          |
   | CREATED         | Ignore                                          |
   | DESCRIPTION     | Ignore                                          |
   | DTSTAMP         | Required                                        |
   | DTSTART         | Required                                        |
   | EXDATE          | Ignore                                          |
   | LAST-MODIFIED   | Ignore                                          |
   | ORGANIZER       | Ignore                                          |
   | RECURRENCE-ID   | Required if RRULE is implemented; otherwise,    |
   |                 | ignore.                                         |
   | RELATED-TO      | Ignore                                          |
   | RDATE           | Ignore                                          |
   | RRULE           | Ignore - assume the first instance occurs on    |
   |                 | the DTSTART property.  If implemented,          |
   |                 | VTIMEZONE MUST also be implemented.             |
   | SEQUENCE        | Required                                        |
   | STATUS          | Ignore                                          |
   | SUMMARY         | Required                                        |
   | URL             | Ignore                                          |
   | UID             | Required                                        |
   | X-              | Ignore                                          |
   +-----------------+-------------------------------------------------+

5.2. Latency Issues

With a store-and-forward transport, it is possible for events to arrive out of sequence. That is, a "CANCEL" method may be received prior to receiving the associated "REQUEST" for the calendar component. This section discusses a few of these scenarios.

5.2.1. Cancellation of an Unknown Calendar Component

When a "CANCEL" method is received before the original "REQUEST" method, the calendar will be unable to correlate the "UID" property of the cancellation with an existing calendar component. It is suggested that messages that cannot be correlated and that also contain non-zero sequence numbers be held and not discarded. Implementations MAY age them out if no other messages arrive with the same "UID" property value and a lower sequence number.
Top   ToC   RFC5546 - Page 124

5.2.2. Unexpected Reply from an Unknown Delegate

When an "Attendee" delegates an item to another CU, they MUST send a "REPLY" method to the "Organizer" using the "ATTENDEE" properties to indicate that the request was delegated and to whom. Hence, it is possible for an "Organizer" to receive a "REPLY" from a CU not listed as one of the original "Attendees". The resolution is left to the implementation, but it is expected that the calendaring software will either accept the reply or hold it until the related "REPLY" method is received from the "Delegator". If the version of the "REPLY" method is out of date, the "Organizer" SHOULD treat the message as a "REFRESH" message and update the "Delegate" with the correct version, provided that delegation to that delegate is acceptable.

5.3. Sequence Number

Under some conditions, a CUA may receive requests and replies with the same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a tie-breaker when two items with the same "SEQUENCE" property value are evaluated.

6. Security Considerations

iTIP is an abstract transport protocol that will be bound to a real- time transport, a store-and-forward transport, and perhaps other transports. The transport protocol will be responsible for providing facilities for authentication and encryption using standard Internet mechanisms that are mutually understood between the sender and receiver.

6.1. Security Threats

6.1.1. Spoofing the Organizer

In iTIP, the "Organizer" (or someone working on the "Organizer's" behalf) is the only person authorized to make changes to an existing "VEVENT", "VTODO", or "VJOURNAL" calendar component and republish it or redistribute updates to the "Attendees". An iCalendar object that maliciously changes or cancels an existing "VEVENT", "VTODO", or "VJOURNAL" calendar component may be constructed by someone other than the "Organizer" and republished or sent to the "Attendees".

6.1.2. Spoofing the Attendee

In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component (or someone working on the "Attendee's" behalf) is the only person authorized to update any parameter associated with their "ATTENDEE"
Top   ToC   RFC5546 - Page 125
   property and send it to the "Organizer".  An iCalendar object that
   maliciously changes the "ATTENDEE" parameters may be constructed by
   someone other than the real "Attendee" and sent to the "Organizer".

6.1.3. Unauthorized Replacement of the Organizer

There will be circumstances when "Attendees" of an event or to-do decide, using out-of-band mechanisms, that the "Organizer" must be replaced. When the new "Organizer" sends out the updated "VEVENT" or "VTODO", the "Attendee's" CUA will detect that the "Organizer" has been changed, but it has no way of knowing whether or not the change was mutually agreed upon.

6.1.4. Eavesdropping and Data Integrity

The iCalendar object is constructed with human-readable clear text. Any information contained in an iCalendar object may be read and/or changed by unauthorized persons while the object is in transit.

6.1.5. Flooding a Calendar

Implementations could provide a means to automatically incorporate "REQUEST" methods into a calendar. This presents the opportunity for a calendar to be flooded with requests, which effectively blocks all the calendar's free time.

6.1.6. Unauthorized REFRESH Requests

It is possible for an "Organizer" to receive a "REFRESH" request from someone who is not an "Attendee" of an event or to-do. Only "Attendees" of an event or to-do are authorized to receive replies to "REFRESH" requests. Replying to such requests to anyone who is not an "Attendee" may be a security problem.

6.2. Recommendations

For an application where the information is sensitive or critical and the network is subject to a high probability of attack, iTIP transactions SHOULD be encrypted and authenticated. This helps mitigate the threats of spoofing, eavesdropping, and malicious changes in transit.

6.2.1. Securing iTIP transactions

iTIP transport bindings MUST provide a mechanism to enable authentication of the sender's identity as well as privacy and integrity of the data being transmitted. This allows the receiver of a signed iCalendar object to verify the identity of the sender. This
Top   ToC   RFC5546 - Page 126
   sender may then be correlated to an "ATTENDEE" property in the
   iCalendar object.  If the correlation is made and the sender is
   authorized to make the requested change or update, then the operation
   may proceed.  It also allows the message to be encrypted to prevent
   unauthorized reading of the message contents in transit. iTIP
   transport binding documents describe this process in detail.

6.2.2. Implementation Controls

The threat of unauthorized replacement of the "Organizer" SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that make "Calendar Users" aware of such "Organizer" changes and allowing them to decide whether or not the request should be honored. The threat of flooding a calendar SHOULD be mitigated by a calendar system that uses this protocol by providing controls that may be used to limit the acceptable sources for iTIP transactions, and perhaps the size of messages and volume of traffic, by source. The threat of unauthorized "REFRESH" requests SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that allow "Calendar Users" to decide whether or not the request should be honored. An implementation MAY decide to maintain, for audit or historical purposes, "Calendar Users" who were part of an "Attendee" list and who were subsequently uninvited. Similar controls or alerts should be provided when a "REFRESH" request is received from these "Calendar Users" as well.

6.2.3. Access Controls and Filtering

In many environments, there could be restrictions on who is allowed to schedule with whom and who the allowed delegates are for particular "Calendar Users". iTIP transport bindings SHOULD provide mechanisms for implementing access controls or filtering to ensure iTIP transactions only take place between authorized "Calendar Users". That would include preventing one "Calendar User" from scheduling with another or one "Calendar User" delegating to another.

6.3. Privacy Issues

The "Organizer" might want to keep "Attendees" from knowing which other "Attendees" are participating in an event or to-do. The "Organizer" has the choice of sending single iTIP messages with a full list of "Attendees" or sending iTIP messages to each "Attendee" with only that "Attendee" listed.
Top   ToC   RFC5546 - Page 127

7. IANA Considerations

7.1. Registration Template for REQUEST-STATUS Values

This specification updates [RFC5545] by adding a "REQUEST-STATUS" value registry to the iCalendar Elements registry. A "REQUEST-STATUS" value is defined by completing the following template. Status Code: Hierarchical, numeric return status code, following the rules defined in Section 3.8.8.3 of [RFC5545]. Status Description: Textual status description. A short but clear description of the error. Status Exception Data: Textual exception data. A short but clear description of what might appear in this field. Description: Describe the underlying cause for this status code value.

7.2. Additions to iCalendar METHOD Registry

This document defines the following values for the iCalendar "METHOD" property, using the values template from Section 8.2.6 of [RFC5545]. These should be added to the Methods Registry defined in Section 8.3.12 of [RFC5545]:

7.2.1. METHOD:PUBLISH

Value: PUBLISH Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.

7.2.2. METHOD:REQUEST

Value: REQUEST Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.
Top   ToC   RFC5546 - Page 128

7.2.3. METHOD:REPLY

Value: REPLY Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.

7.2.4. METHOD:ADD

Value: ADD Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.

7.2.5. METHOD:CANCEL

Value: CANCEL Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.

7.2.6. METHOD:REFRESH

Value: REFRESH Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.

7.2.7. METHOD:COUNTER

Value: COUNTER Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property.
Top   ToC   RFC5546 - Page 129
   Examples:  See this RFC.

7.2.8. METHOD:DECLINECOUNTER

Value: DECLINECOUNTER Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC.

7.3. REQUEST-STATUS Value Registry

New "REQUEST-STATUS" values can be registered using the process described in Section 8.2.1 of [RFC5545]. The following table is to be used to initialize the "REQUEST-STATUS" value registry.
Top   ToC   RFC5546 - Page 130
           +-------------+---------+--------------------------+
           | Status Code | Status  | Reference                |
           +-------------+---------+--------------------------+
           | 2.0         | Current | RFC 5546, Section 3.6.1  |
           | 2.1         | Current | RFC 5546, Section 3.6.2  |
           | 2.2         | Current | RFC 5546, Section 3.6.3  |
           | 2.3         | Current | RFC 5546, Section 3.6.4  |
           | 2.4         | Current | RFC 5546, Section 3.6.5  |
           | 2.5         | Current | RFC 5546, Section 3.6.6  |
           | 2.6         | Current | RFC 5546, Section 3.6.7  |
           | 2.7         | Current | RFC 5546, Section 3.6.8  |
           | 2.8         | Current | RFC 5546, Section 3.6.9  |
           | 2.9         | Current | RFC 5546, Section 3.6.10 |
           | 2.10        | Current | RFC 5546, Section 3.6.11 |
           | 2.11        | Current | RFC 5546, Section 3.6.12 |
           | 3.0         | Current | RFC 5546, Section 3.6.13 |
           | 3.1         | Current | RFC 5546, Section 3.6.14 |
           | 3.2         | Current | RFC 5546, Section 3.6.15 |
           | 3.3         | Current | RFC 5546, Section 3.6.16 |
           | 3.4         | Current | RFC 5546, Section 3.6.17 |
           | 3.5         | Current | RFC 5546, Section 3.6.18 |
           | 3.6         | Current | RFC 5546, Section 3.6.19 |
           | 3.7         | Current | RFC 5546, Section 3.6.20 |
           | 3.8         | Current | RFC 5546, Section 3.6.21 |
           | 3.9         | Current | RFC 5546, Section 3.6.22 |
           | 3.10        | Current | RFC 5546, Section 3.6.23 |
           | 3.11        | Current | RFC 5546, Section 3.6.24 |
           | 3.12        | Current | RFC 5546, Section 3.6.25 |
           | 3.13        | Current | RFC 5546, Section 3.6.26 |
           | 3.14        | Current | RFC 5546, Section 3.6.27 |
           | 4.0         | Current | RFC 5546, Section 3.6.28 |
           | 5.0         | Current | RFC 5546, Section 3.6.29 |
           | 5.1         | Current | RFC 5546, Section 3.6.30 |
           | 5.2         | Current | RFC 5546, Section 3.6.31 |
           | 5.3         | Current | RFC 5546, Section 3.6.32 |
           +-------------+---------+--------------------------+

8. Acknowledgments

This is an update to the original iTIP document authored by S. Silverberg, S. Mansour, F. Dawson, and R. Hopson. This revision is the product of the Calsify IETF Working Group, and several participants have made important contributions to this specification, including Oliver Block, Bernard Desruisseaux, Mike Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg II, Robert Ransdell, and Caleb Richardson.
Top   ToC   RFC5546 - Page 131

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.

9.2. Informative References

[iMIP] Melnikov, A., Ed., "iCalendar Message-Based Interoperability Protocol (iMIP)", Work in Progress, October 2009.
Top   ToC   RFC5546 - Page 132

Appendix A. Differences from RFC 2446

A.1. Changed Restrictions

This specification now defines an allowed combination of "REQUEST- STATUS" codes when multiple iCalendar components are included in an iTIP message. This specification now restricts "RECURRENCE-ID" to only a single occurrence in any one iCalendar component in an iTIP message, as required by [RFC5545]. Changed the "RECURRENCE-ID" entry in the component restriction table to "0 or 1" from "0+", to fall in line with [RFC5545]. Changed the "FREEBUSY" entry in the "VFREEBUSY", "PUBLISH", and "REPLY" restriction tables to "0+" from "1+", to fall in line with [RFC5545]. Changed the "FREEBUSY" description in the "VFREEBUSY" and "REPLY" restriction tables to indicate that different "FBTYPE" ranges MUST NOT overlap. Changed the "TZNAME" entry in the "VTIMEZONE" restriction table to "0+" from "0 or 1", to fall in line with [RFC5545]. Changed the "COMMENT" entry in the component restriction tables to "0+" from "0 or 1", to fall in line with [RFC5545]. Added the "ATTENDEE" entry in the "VALARM" restriction table to match the email alarm type in [RFC5545]. Changed the "CATEGORIES" entry in the component restriction tables to "0+" from "0 or 1", to fall in line with [RFC5545]. Changed the "RESOURCES" entry in the component restriction tables to "0+" from "0 or 1", to fall in line with [RFC5545]. Changed the "CONTACT" entry in the "VFREEBUSY" restriction table to "0 or 1" from "0+", to fall in line with [RFC5545]. Changed the "UID" entry in the "VFREEBUSY" and "PUBLISH" restriction tables to "1" from "0", to fall in line with [RFC5545]. Added the "COMPLETED" entry in the "VTODO" restriction tables to fall in line with [RFC5545].
Top   ToC   RFC5546 - Page 133
   Added the "REQUEST-STATUS" entry in the "VJOURNAL" restriction tables
   to fall in line with [RFC5545].

A.2. Deprecated Features

The "EXRULE" property was removed in [RFC5545] and references to that have been removed in this document too. The "PROCEDURE" value for the "ACTION" property was removed in [RFC5545] and references to that have been removed in this document too. The "THISANDPRIOR" option for the "RANGE" parameter was removed in [RFC5545] and references to that have been removed in this document too.

Author's Address

Cyrus Daboo (editor) Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/