tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5546

 
 
 

iCalendar Transport-Independent Interoperability Protocol (iTIP)

Part 5 of 5, p. 96 to 133
Prev RFC Part

 


prevText      Top      Up      ToC       Page 96 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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/