RFC 5546
iCalendar Transport-Independent Interoperability Protocol (iTIP)
Pages: 133
Proposed Standard
→ Errata
Obsoletes: 2446
Updates: 5545
Updated by: 6638
Proposed Standard
→ Errata
Obsoletes: 2446
Updates: 5545
Updated by: 6638
Part 5 of 5 – Pages 96 to 133
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:VCALENDAR4.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.
+---------------------+--------------------+------------------------+
| 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
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
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.
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
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
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
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
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
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
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.
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
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.
+--------------+------------------------+---------------------------+ | 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
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
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
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:VCALENDAR4.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
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
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
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
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.
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. | +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ | 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 | +-----------------+-------------------------------------------------+
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 | +-----------------+-------------------------------------------------+
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. | +-----------------+-------------------------------------------------+
+------------------+------------------------------------------------+ | 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 | +------------------+------------------------------------------------+
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. | +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ | 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.
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"
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
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.
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.
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.
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.
+-------------+---------+--------------------------+
| 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.
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.
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].
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/