RFC 2446
iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
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:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTIMEZONE TZID:America-SanJose TZURL:http://zones.stds_r_us.net/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;TYPE=INDIVIDUAL:A@example.COM ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp DTSTAMP:19970613T190030Z DTSTART;TZID=America-SanJose:19970701T140000 DTEND;TZID=America-SanJose:19970701T150000 RRULE:FREQ=WEEKLY;INTERVAL=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 two components of this iCalendar object are the time zone components. 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. "Attendee" B@example.fr is in France where the local time on this date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00. 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 PDT. The "RDATE" property adds another instance: WED, 10-SEP-1997 2:00 PM PST. There are two exceptions to this recurring appointment. The first one is: TUE, 09-SEP-1997 23:00 GMT TUE, 09-SEP-1997 14:00 PDT WED, 10-SEP-1997 06:00 JST and the second is: TUE, 28-OCT-1997 23:00 GMT TUE, 28-OCT-1997 14:00 PST WED, 29-OCT-1997 06:00 JST 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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com 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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.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 Recurring Event In this example the "Organizer" wishes to cancel the entire recurring event and any exceptions. BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.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 extends to all future instances. BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.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, but does not want to reschedule the entire meeting or lose any of the per-instance information already collected. The original event: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.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 Assume that many other updates happen to this event and that a lot of instance-specific information exists in the recurring series. The "SEQUENCE" property value is 7 for the next update. Now the "Organizer" wants to add Thursdays to the event: BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0
BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:7 RRULE:WKST=SU;BYDAY=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 Usual conference room STATUS:CONFIRMED END:VEVENT END:VCALENDAR Alternatively, if the "Organizer" is not concerned with per-instance updates, 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. BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.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 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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:2 RDATE:19980304T180000Z RDATE:19980311T160000Z RDATE:19980315T180000Z Error! Bookmark not defined. 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 Error! Bookmark not defined. SEQUENCE:2 RECURRENCE-ID:19980311T160000Z Error! Bookmark not defined. ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. ATTENDEE;Error! Bookmark not defined. SUMMARY:Review Accounts DTSTART:19980311T160000Z DTEND:19980304T180000Z DTSTAMP:19980306T193000Z LOCATION:The Small conference room STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4.8 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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.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.9 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:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.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 Response from "B" to indicate that RRULE is not supported and an unrecognized property was encountered BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE:Mailto:B@example.com REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single event;RRULE REQUEST-STATUS:3.0;Invalid Property Name;FOO UID:guid-1@host1.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 to-do | "A" sends a REQUEST | | | request | message to "B", "C",| | | | and "D" | | +--------------------------------------------------------------------+ | Accept the to-do | | "B" sends a "REPLY" | | request | | message to "A" with its | | | | "partstat" paramater | | | | set to "accepted". | +--------------------------------------------------------------------+ | Decline the to-do | | "C" sends a REPLY | | request | | message to "A" with its | | | | "partstat" parameter | | | | set to "declined". | +--------------------------------------------------------------------+ | Tentatively accept | | "D" sends a REPLY | | the to-do request | | message to "A" with its | | | | "partstat" parameter | | | | set to "tentative". | +--------------------------------------------------------------------+ | Check attendee | "A" sends a REQUEST | | | completion status | message to "B" and | | | | "D" with current | | | | information. | | +--------------------------------------------------------------------+ | Attendee indicates | | "B" sends a "REPLY" | | percent complete | | message indicating | | | | percent complete |
+--------------------------------------------------------------------+ | Attendee indicates | | "D" sends a "REPLY" | | completion | | message indicating | | | | 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:-//ACME/DesktopCalendar//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:-//ACME/DesktopCalendar//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 e-mail SEQUENCE:0 DTSTAMP:19970717T203000Z REQUEST-STATUS:2.0;Success
END:VTODO END:VCALENDAR "B" could have declined the TODO 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:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=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:-//ACME/DesktopCalendar//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:-//ACME/DesktopCalendar//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:-//ACME/DesktopCalendar//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;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=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-PROGRESS 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:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR DTSTART:19980101T100000-0700 DUE:19980103T100000-0700 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 Calculating due dates in recurring VTODOs The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. The former is calculated by applying the difference between "DTSTART" and "DUE" properties and applying it to each of the start of each recurring instance. Hence, if the initial "VTODO" calendar component specifies a "DTSTART" property value of "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the interval of one day which is applied to each recurring instance of the "VTODO" calendar component to determine the "DUE" date of the instance. 4.5.7.3 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:-//ACME/DesktopCalendar//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:-//ACME/DesktopCalendar//EN VERSION:2.0 BEGIN:VJOURNAL DTSTART:19971002T200000Z 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 "UID" property value of "guid-1- 12345@host1.com": BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//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@host1.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 a request 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" | | refresh because | | message to "A" | | "RECURRENCE-ID" was| | | | not found | | | +--------------------------------------------------------------------+ | Refresh the entire | "A" sends the | | | Event | latest copy of the | | | | Event to "B" | | +--------------------------------------------------------------------+ | Attendee handles | | "B" updates to the | | the request and | | latest copy of the | | updates the | | meeting. | | instance | | | +--------------------------------------------------------------------+ Request from "A": BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:acme-12345@host1.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 "acme-12345@host1.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:-//RDU Software//NONSGML HandCal//EN METHOD:REFRESH VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE:Mailto:B@example.com UID:acme-12345@host1.com DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR 5 Application Protocol Fallbacks 5.1 Partial Implementation Applications that support this memo 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 CANCEL Required REFRESH Required COUNTER Reply with Not Supported DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise reply with Not Supported iCalendar Property Fallback -------------- ----------------------------------------------------- CALSCALE Ignore; assume GREGORIAN PRODID Ignore METHOD Required as described in the Method list above VERSION Ignore
Event-Related
Components Fallback
-------------- -----------------------------------------------------
VALARM Reply with Not Supported
VTIMEZONE Required if any DateTime value refers to a time zone.
Component
Property Fallback
-------------- -----------------------------------------------------
ATTACH Ignore
ATTENDEE Required if EVENT-REQUEST is not implemented;
otherwise reply with Not Supported
CATEGORIES Ignore
CLASS Ignore
COMMENT Ignore
COMPLETED Ignore
nCONTACT Ignore
CREATED Ignore
DESCRIPTION Required
DURATION Reply with Not Supported
DTSTAMP Required
DTSTART Required
DTEND Required
EXDATE Ignore
EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented.
GEO Ignore
LAST-MODIFIED Ignore
LOCATION Required
ORGANIZER Ignore
PRIORITY Ignore
RELATED-TO Ignore
RDATE Ignore
RRULE Ignore. 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 Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. REQUEST Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. REPLY Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. iCalendar Property Fallback -------------- ----------------------------------------------------- CALSCALE Ignore; assume GREGORIAN. PRODID Ignore METHOD Required as described in the Method list above. VERSION Ignore Component Property Fallback -------------- ----------------------------------------------------- COMMENT Ignore CONTACT Ignore DTEND Required DTSTAMP Required DTSTART Required DURATION Required FREEBUSY Required ORGANIZER 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
CANCEL Required
REFRESH Required
COUNTER Reply with Not Supported
DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise
reply with Not Supported
iCalendar
Property Fallback
-------------- -----------------------------------------------------
CALSCALE Ignore; assume GREGORIAN.
PRODID Ignore
METHOD Required as described in the Method list above.
VERSION Ignore
To-Do-Related
Components Fallback
-------------- -----------------------------------------------------
VALARM Reply with Not Supported
VTIMEZONE Required if any DateTime value refers to a time zone.
Component
Property Fallback
-------------- -----------------------------------------------------
ATTACH Ignore
ATTENDEE Required if REQUEST is not implemented; otherwise
ignore
CATEGORIES Ignore
CLASS Ignore
COMMENT Ignore
COMPLETED Required
CONTACT Ignore
CREATED Ignore
DESCRIPTION Required
DUE Required
DURATION Ignore Reply with Not Supported
DTSTAMP Required
DTSTART Required
EXDATE Ignore Reply with Not Supported
EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented.
LAST-MODIFIED Ignore
LOCATION Ignore
ORGANIZER Ignore
PERCENT-COMPLETE Ignore
PRIORITY Required
RECURRENCE-ID Ignore
RELATED-TO Ignore
REQUEST-STATUS Ignore
RDATE Ignore
RRULE Ignore. 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
Property Fallback
-------------- -----------------------------------------------------
CALSCALE Ignore; assume GREGORIAN.
PRODID Ignore
METHOD Required as described in the Method list above.
VERSION Ignore
Journal-Related
Components Fallback
-------------- -----------------------------------------------------
VTIMEZONE Required if any DateTime value refers to a time zone.
Component
Property Fallback
-------------- -----------------------------------------------------
ATTACH Ignore
ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise
ignore
CATEGORIES Ignore
CLASS Ignore
COMMENT Ignore
CONTACT Ignore
CREATED Ignore
DESCRIPTION Required
DTSTAMP Required
DTSTART Required
EXDATE Ignore
EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented.
LAST-MODIFIED Ignore
ORGANIZER Ignore
RECURRENCE-ID Ignore
RELATED-TO Ignore
RDATE Ignore.
RRULE Ignore. 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 can not be correlated 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 an "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. 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 which 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", "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 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 MAY 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 block all the calendar's free time. 6.1.6 Procedural Alarms The "REQUEST" methods for "VEVENT" and "VTODO" calendar components MAY contain "VALARM" calendar components. The "VALARM" calendar component may be of type "PROCEDURE" and MAY have an attachment containing an executable program. Implementations that incorporate these types of alarms are subject to any virus or malicious attack that may occur as a result of executing the attachment. 6.1.7 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 "Attendee's" 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 is subject to a high probability of attack, iTIP transactions SHOULD be encrypted. This may be accomplished using public key technology, specifically Security Multiparts for MIME
[RFC-1847] in the iTIP transport binding. This helps mitigate the threats of spoofing, eavesdropping and malicious changes in transit. 6.2.1 Use of [RFC-1847] to secure iTIP transactions iTIP transport bindings MUST provide a mechanism based on Security Multiparts for MIME [RFC-1847] to enable authentication of the sender's identity, and 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. Implementations MAY provide controls for users to disable this capability. 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 malicious procedural alarms SHOULD be mitigated by a calendar system that uses this protocol by providing controls that may be used to disallow procedural alarms in iTIP transactions and/or remove all alarms from the object before delivery to the recipient. 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 User" 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.
7 Acknowledgments A hearty thanks to the following individuals who have participated in the drafting, review and discussion of this memo: Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug Royer, Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Alexander Taler, Kevin Tsurutome. 8 Bibliography [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998. [iMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol - iMIP", RFC 2447, November 1998. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
9 Authors' Addresses The following address information is provided in a vCard v3.0, Electronic Business Card, format. The authors of this memo are: BEGIN:VCARD VERSION:3.0 N:Dawson;Frank FN:Frank Dawson ORG:Lotus Development Corporation ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 3502;USA TEL;TYPE=WORK,MSG:+1-919-676-9515 TEL;TYPE=WORK,FAX:+1-919-676-9564 EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com EMAIL;TYPE=INTERNET:fdawson@earthlink.net URL:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD VERSION:3.0 N:Hopson;Ross FN:Ross Hopson ORG:On Technology, Inc. ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 1600;434 Fayetteville St. Mall\, Two Hannover Square;Raleigh;NC;27601 TEL;TYPE=WORK,MSG:+1-919-890-4036 TEL;TYPE=WORK,FAX:+1-919-890-4100 EMAIL;TYPE=INTERNET:rhopson@on.com END:VCARD BEGIN:VCARD VERSION:3.0 N:Mansour;Steve FN:Steve Mansour ORG:Netscape Communications Corporation ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain View;CA;94043;USA TEL;TYPE=WORK,MSG:+1-650-937-2378 TEL;TYPE=WORK,FAX:+1-650-937-2103 EMAIL;TYPE=INTERNET:sman@netscape.com END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Silverberg;Steve
FN:Steve Silverberg
ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;TYPE=WORK,MSG:+1-425-936-9277
TEL;TYPE=WORK,FAX:+1-425-936-8019
EMAIL;INTERNET:stevesil@Microsoft.com
END:VCARD
The iCalendar object is a result of the work of the Internet
Engineering Task Force Calendaring and scheduling Working Group. The
chairman of that working group is:
BEGIN:VCARD
VERSION:3.0
N:Ganguly;Anik
FN:Anik Ganguly
ORG:Open Text Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD
The co-chairman of that working group is:
BEGIN:VCARD
VERSION:3.0
N:Moskowitz;Robert
FN:Robert Moskowitz
NICKNAME:Bob
EMAIL; TYPE=INTERNET:rgm-ietf@htt-consult.com
END:VCARD
10. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.