Network Working Group F. Dawson, Lotus INTERNET-DRAFT R. Hopson, ON Technologies S. Mansour, Netscape Expires in six months from July 18, 1997 S. Silverberg, Microsoft iCalendar Transport-Independent Interoperability Protocol (iTIP) Part Two: Scheduling To-Dos Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Abstract This set of documents, collectively called the iCalendar Transport- independent Interoperability Protocol, or iTIP, defines a transport- independent message protocol to allow for searching for busy time and the scheduling of events, journals, or journal entries on different calendaring and scheduling systems. These documents are based on earlier work documented in the iCalendar format. Because iCalendar delt mainly with the format of calendaring information and said so little about the method for conveying scheduling semantics, these documents add scheduling semantics to the base calendaring functionality defined in iCalendar. The initial document specifies the messages for allowing searching for free or busy time information and for scheduling events. The second document defines the messages for scheduling to-dos, or action items. The third document defines the messages for scheduling journal entries. This document set is intended to convey calendaring and scheduling semantics between different applications, independent of transport. This document is also being offered as a specification for demonstrating industry-wide, calendaring and scheduling interoperability. The protocol defined by this document is applicable for conveying calendaring and scheduling information across any reliable transport. This format is useful for both client-to-server communication, server-to-server communication, and client-to-client, peer communication (e.g., PDA synchronization with a PIM). Dawson/Hopson/Mansour/Silverberg 1 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 The breadth of this document is limited to exchanging only the to-do type of calendar information. It does not address issues related to events or journal entries. Instead, the document outlines a model for calendar exchange that defines both static and dynamic to-do objects. Static to-do objects are used to transmit to-dos from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic to-do objects are a superset of static to-do objects and will gracefully degrade to their static counterparts for clients that only support static to-do objects. Dawson/Hopson/Mansour/Silverberg 2 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 Table of Contents: 1. INTRODUCTION........................................................5 1.1 ITIP SCHEDULING TRANSACTIONS.....................................5 2. PROTOCOL MODELS.....................................................6 2.1 APPLICATION PROTOCOL.............................................6 2.1.1 Scheduling Transaction State..................................7 2.2 ADVANCED CALENDARING CONCEPTS....................................8 2.3 CALENDAR ROLES...................................................9 3. APPLICATION PROTOCOL ELEMENTS.......................................9 3.1 ITIP MESSAGE CONFORMANCE........................................10 3.1.1 Restrictions on DTSTART and DUE..............................11 3.2 SUMMARY OF APPLICATION PROTOCOL ELEMENTS........................11 3.2.1 TODO-PUBLISH.................................................11 3.2.2 TODO-REQUEST.................................................14 3.2.3 TODO-REPLY...................................................18 3.2.4 TODO-CANCEL..................................................20 3.2.5 Rescheduling or Changing a To-do.............................22 3.2.6 TODO-RESEND..................................................26 3.3 REQUEST STATUS CODES............................................29 4. EXAMPLES...........................................................31 4.1 PUBLISHED TO-DOS................................................31 4.1.1 A Minimal Published To-Do....................................32 4.1.2 Changing A Published To-Do...................................32 4.1.3 Canceling A Published To-Do..................................33 4.1.4 A Rich Published To-Do.......................................33 4.2 GROUP TO-DO EXAMPLES............................................35 4.2.1 A To-Do Request..............................................36 4.2.2 A To-Do Reply................................................36 4.2.3 Update A To-do...............................................37 4.3 RECURRING TO-DO AND TIME ZONE EXAMPLES..........................37 4.3.1 A Recurring To-do That Spans Timezones.......................37 4.3.2 Creating an Exception to a Recurring To-Do..................39 4.3.3 Modify Exception.............................................40 4.3.4 Cancel an Exception..........................................40 4.3.5 Cancel Recurring To-Do.......................................41 4.3.6 Decline A Previously Accepted Exception......................41 5. APPLICATION PROTOCOL FALLBACKS.....................................42 5.1 ICALENDAR PROFILE TYPES.........................................42 5.2 CALENDAR COMPONENTS.............................................42 5.3 CALENDAR PROPERTIES.............................................43 5.4 COMPONENT PROPERTIES............................................43 5.5 LATENCY ISSUES..................................................45 5.5.1 Cancelation of an Unknown To-do..............................45 5.6 SEQUENCE NUMBER.................................................45 6. SECURITY CONSIDERATIONS............................................45 Dawson/Hopson/Mansour/Silverberg 3 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 7. ACKNOWLEDGMENTS....................................................46 8. BIBLIOGRAPHY.......................................................46 9. AUTHORS ADDRESSES..................................................47 Dawson/Hopson/Mansour/Silverberg 4 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 1. Introduction The purpose of this document set is to define the format of iCalendar objects and how the iCalendar objects are conveyed between Calendar User Agents (CUA) and Calendar Services (CS). This involves the definition of a protocol that uses the iCalendar Object as the basis for a collection of messages that are transmitted from one calendaring system to another. The protocol is transport independent but can be bound to either a real-time transport or a store-and- forward transport such as e-mail. This set of documents is based on the calendaring and scheduling model specified in [ICSM]. The first document in the set specifies the messages for allowing searching for free or busy time information and for scheduling events. This the second document, defines the messages for scheduling to-dos, or action items. The third document defines the messages for scheduling journal entries. Implemented as a whole, this document set will allow different calendaring and scheduling domains to interoperate; allowing for the seach for available free or busy time information and scheduling events, to-dos, or daily journal entries. 1.1 iTIP Scheduling Transactions The profiles described in section 3 (Application Protocol Elements) may be considered usage profiles of the [ICAL] and is designed specifically for the exchange of calendaring information between scheduling applications. To-do Publication Publish a to-do; Change a published to-do; Cancel a published to-do. Group To-dos Request that a to-do be assigned to one or more recipients; Reply to an existing to-do request to accept, decline, or indicate completion of the to-do request; Allow the organizer of a to-do to cancel the to-do; Allow the organizer of a to-do to replace the original to-do definition, as when a to-do description is clarified or the attendee assignment information is updated; Allow an attendee to request a resend of the current description for an existing request. Recurring To-dos and Timezones Dawson/Hopson/Mansour/Silverberg 5 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 Support scheduling a to-do between individuals in different time zones; Support for time zones; Support for DST rules; Create a recurring to-do request with exception dates 2. Protocol Models The protocol model for this part of iTIP is intended to be the same as that described in iTIP Part 1. It is repeated here for clarity when reading this document alone. There are two distinct protocols that comprise iTIP: an Application Protocol and a Transport Protocol. The Application Protocol defines the content of the iCalendar objects sent between a sender and a receiver in order to accomplish the various iTIP scheduling transactions (section 1.1). The Transport protocol defines how the iCalendar objects are sent between the sender and receiver. This document focuses on the Application Protocol. Some considerations for Transport Protocol documents are listed in Appendix A of [ITIP-1]. +----------+ +----------+ | | iTIP | | | Sender |<-------------------->| Receiver | | | | | +----------+ +----------+ There are several variations of this diagram in which the Sender and Receiver take on various roles of CUA or CS. These variants are detailed in the Model document [ICMS] The architecture of iTIP is depicted in the diagram below. An application written to this specification may utilize either the binding for the store-and-forward transport, the real time transport, or both. The iTIP could also be bound to other transports. If a capability is not available on a particular transport binding, iTIP provides a mechanism for indicating so. +------------------------------------------+ | iCalendar | +------------------------------------------+ | iTIP | +------------------------------------------+ |Real-time | Store and Fwd | Other | |Transport | Transport | Transports... | +------------------------------------------+ 2.1 Application Protocol The model for the application protocol is originator-based (organizer or owner roles for a request). That is, the originator of a request sends it out to one or more invitees. The invitees reply back to the Dawson/Hopson/Mansour/Silverberg 6 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 originator. The originator maintains the status of the event. Only the originator can modify or cancel the request. The data sources for the protocol are the Calendar Users as defined in [ICMS]. Examples of these users are the originator (i.e., organizer or owner) and attendees of an iCalendar to-do. The data objects are the iCalendar objects that are exchanged between Calendar Users. 2.1.1 Scheduling Transaction State The state of the to-do scheduling transaction is described by the STATUS and ATTENDEE properties in the to-do calendar component. If there are no attendees in the calendar component, then this implies the publish - state STATUS. The state of a to-do request changes from the time it is initially assigned, to when the attendees reply to the request, to when each of the attendees complete the to-do. When an originator sends out the to-do request, it's state with respect to the attendees is NEEDS ACTION. If the attendee accepts the assignment, then the status is changed to ACCEPTED. If the attendee rejects the assignment, then the status is changed to DECLINED. When the attendee completes the to-do, then the status is changed to COMPLETED. These changes in the attendee status for the to-do are effected by the attendee sending the originator a TODO-REPLY message with their updated status. The general status of the to-do is reflected by the STATUS property. The to-do STATUS property is controlled by the originator. There is no default status. Initially, the originator should either set the status to TENTATIVE or CONFIRMED. The originator can also set the status to CANCELLED by sending a TODO-CANCEL message to the attendees. The status is set to COMPLETED when all the attendees for the to-do request have indicated their completion of the assignment by sending the originator a TODO-REPLY message with their status set to COMPLETED. The states of the protocol are contained in the iCalendar object. Due to the individual nature of a scheduling transaction, the state may be different for each Calendar User. The diagram below describes the various state changes. Dawson/Hopson/Mansour/Silverberg 7 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 +===========================+========================== | Owner / Originator | Attendee / Recipient | +===========================+=========================+ | TODO-PUBLISH -----------------------------------> | | State=CONFIRMED | +=====================================================+ | TODO-REQUEST -----------------------------------> | | State=CONFIRMED | TENTATIVE | | Attendee Status=NEEDS ACTION | | | | <------------------------------------- TODO-REPLY | | State=As specified in the TODO-REQUEST message | | Attendee Status=ACCEPTED | DECLINED | COMPLETED | +=====================================================+ | TODO-CANCEL -----------------------------------> | | State=CANCELLED | | Attendee Status=As specified in the TODO-REPLY | +=====================================================+ | TODO-REQUEST -----------------------------------> | | (A rescheduled or redefined to-do request) | | State=CONFIRMED | TENTATIVE | | Attendee Status=As defined in previous TODO- | | REPLY message for this to-do | +=====================================================+ | <-------------------------------------TODO-RESEND | | State=As specified in the TODO-REQUEST message | | Attendee Status=As specified in the TODO-REPLY | +=====================================================+ 2.2 Advanced Calendaring Concepts The calendaring and scheduling capability defined by this document is based on the exchange of messages between the organizer of a to-do and one or more Calendar User Agents (CUA). The message protocol emulates a "request" and "reply" form of communications. However, there is a class of actions that are non-interactive and are more consistent with publishing. These include the publishing of static to-dos. The message format is designed to be used with either a MIME electronic messaging transport, real time protocols, and other Internet and non-Internet transports. This message-based protocol is based on "request" messages sent from an originator and conveyed to one or more recipients. A recipient of a "request" message may "reply" to the request, in order to update their status and may also return transaction/request status information. The protocol also supports the ability for the originator of a to-do to change or cancel the original request. The elements of the protocol also include the notion of user roles. Dawson/Hopson/Mansour/Silverberg 8 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 2.3 Calendar Roles Roles are a behavior or set of activities performed by particular groups of users or agents at a particular time given the state of the application. This specification describes 3 roles that determine a range of actions and responsibilities specific to each role. When scheduling a to-do with one or more individuals, there are 3 roles: OWNER, ORGANIZER and ATTENDEE. The OWNER is generally the originator of the to-do request. The OWNER sends the to-do request and receives responses from the ATTENDEES. The OWNER is the effective owner of the to-do. There are scenarios where the OWNER has an agent or associate who acts on the OWNER's behalf, as is the case when your an assistant makes assignments for you. In this scenario the ORGANIZER and the OWNER are different individuals yet the ORGANIZER is still responsible for sending and receiving the requests and managing the calendar entities for this to-do. Role Description Organi The organizer is the calendar user that sends zer and manages the to-do --- meaning responses are directed at the organizer. In most cases the organizer is also the owner, but in cases where the owner has the organizer act on it's behalf, the organizer becomes a proxy for the owner. The organizer in this case would place the to-do on the calendar of the owner. Owner The owner generally controls direct manipulation of the to-do. The owner can make unilateral changes to the to-do while the attendees can reply back to the owner. The owner is usually the organizer, but in some cases an agent or associate will act on behalf of the owner and organize the to-do and assignment logistics. Attend Attendees are those recipients who are ees assigned the group to-do. When an attendee responds to the request, the attendee's status property is set to either accept, decline, tentative, or completed 3. Application Protocol Elements Messages are the on-the-wire MIME entities that contain calendaring information. The particular type of [ICAL] message is referred to as the profile type. Each profile type is identified by a profile property specified as part of the Text/Calendar content type. The Dawson/Hopson/Mansour/Silverberg 9 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 following describes the various [ICAL] profile types supported in this specification. Profile Type Description TODO-PUBLISH Post notification of a to-do. Used primarily as a method of advertising the existence of a to-do. The ATTENDEES property is not included and no interaction is expected. TODO-REQUEST Make a to-do assignment. This is an explicit assignment of a to-do to one or more attendees. To-do requests are also used to update or change an existing to- do description. Clients that cannot handle TODO-REQUEST messages can degrade the to-do to view it as a TODO-PUBLISH. TODO-REPLY Reply to a to-do request. This includes "ACCEPT", "TENTATIVE", "DECLINE" and "COMPLETED". TODO-CANCEL Cancel an existing to-do request. Uses the UID to identify the to-do to be canceled. TODO-RESEND Resend an existing to-do request. Uses the UID to identify the to-do to be resend. Each profile type has an associated collection of properties and methods. Some properties are required and others are optional. This specification is also designed with the notion that some calendaring clients will be capable of reading and posting to-dos (where posting means to local calendar). Therefore, profiles such as TODO-REQUEST will contain an exact superset of the TODO-PUBLISH property set such that a client that supported TODO-PUBLISH could still read a TODO- REQUEST. 3.1 ITIP Message Conformance An implementation conforming to iTIP must enforce the conventions described in the sections below. These conventions have been made to improve interoperability. As a side benefit, they tend to simplify implementation. Dawson/Hopson/Mansour/Silverberg 10 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 3.1.1 Restrictions on DTSTART and DUE The DTSTART property must always be specified. This specifies the date/time that the to-do is to first be displayed. The DUE property may be specified. This specifies the date/time that the to-do is assigned to be completed. If the DUE property is missing, then the implicit due date/time for the to-do is to be set to the current date, until the to-do is completed. A to-do request containing DUE without a DTSTART is not allowed. The DTSTART and the DUE properties may have the same value. If the due date/time is known, the DUE property should be specified. The DURATION property cannot be specified in conjunction with DTSTART. 3.2 Summary of Application Protocol Elements This section outlines the complete property set for each profile type, indicating the required (designated by the word REQUIRED), optional (designed by the words NOT REQUIRED) and excluded (designated by the word EXCLUDED) properties. 3.2.1 TODO-PUBLISH The TODO-PUBLISH is somewhat unique in this document in that it has no response scheduling message associated with it. Instead, it is simply a to-do that can be added by a calendar user agent to a calendar as a static to-do entry. There is no defined response to the originator of a TODO-PUBLISH message. It's expected usage is for publication of to-dos such as those that might be published on a website or Internet calendar. The TODO-PUBLISH is simply a MIME encapsulated file that can be referenced and opened by the appropriate handler for a TEXT/CALENDAR MIME content type and EVENT- PUBLISH profile type. TODO-PUBLISH Calendar Properties COMMENT Not Required GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required, "TODO-PUBLISH" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties COMMENT Not Required Dawson/Hopson/Mansour/Silverberg 11 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 CREATED Not Required DAYLIGHT Not Required DTSTART Required DTSTART Not Required RDATE Not Required, Either RDATE or RRULE may be specified, but not both. RRULE Not Required, Either RDATE or RRULE may be specified, but not both. TZNAME Not Required TZOFFSET Required TZTRANS Not Required UID Required Event Component Properties To-do component is excluded from this message type. To-do Component Properties ATTACH Not Required, "VALUE=URL" only. ATTENDEE Not Required CATEGORIES Not Required CLASS Not Required COMMENT Not Required CREATED Not Required COMPLETED Not Required DESCRIPTION Required, Value may be NULL text. DUE Not Required DURATION Excluded DTEND Excluded Dawson/Hopson/Mansour/Silverberg 12 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 DTSTAMP Required DTSTART Required EXDATE Not Required EXRULE Not Required LAST-MODIFIED Not Required LOCATION Not Required PRIORITY Not Required RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required. RRULE Not Required. RESOURCES Not Required RESPONSE-SEQUENCE Excluded SEQUENCE Required, if not zero. STATUS Not Required. SUMMARY Not Required. May be NULL text. TRANSP Excluded URL Not Required UID Required Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties ATTACH Not Required CATEGORIES Required, If an alarm is specified COMMENT Not Required CREATED Not Required Dawson/Hopson/Mansour/Silverberg 13 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 DESCRIPTION Not Required DTSTART Required, If an alarm is specified DURATION Required, If an alarm is specified LAST-MODIFIED Not Required RELATED-TO Not Required REPEAT Required, If an alarm is specified SUMMARY Not Required URL Not Required Freebusy Properties Freebusy component is excluded from this message type. Non-standard Properties X-token Not Required, but recipient may choose to ignore those non- standard properties, specified as Not Required. 3.2.2 TODO-REQUEST The TODO-REQUEST is used to both describe a to-do and assign the to- do to one or more attendees. When a TODO-REQUEST is received by a user it should be responded to with a TODO-REPLY. TODO-REQUEST Calendar Properties COMMENT Not Required GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"TODO-REQUEST" Dawson/Hopson/Mansour/Silverberg 14 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties COMMENT Not Required CREATED Not Required DAYLIGHT Not Required DTSTART Required DTEND Not Required RDATE Not Required, Either RDATE or RRULE may be specified, but not both. RRULE Not Required, Either RDATE or RRULE may be specified, but not both. TZNAME Not Required TZOFFSET Required TZTRANS Not Required Event Component Properties To-do component is excluded from this message type. To-do Component Properties ATTACH Not Required, "VALUE=URL" only. ATTENDEE Required, Value is an RFC822 mailbox address for C&S capability. STATUS parameter is either absent or has value "NEEDS ACTION". CATEGORIES Not Required CLASS Not Required COMMENT Not Required CREATED Not Required COMPLETED Not Required Dawson/Hopson/Mansour/Silverberg 15 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 DESCRIPTION Required, Value may be NULL text. DUE Not Required DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Required EXDATE Not Required. EXRULE Not Required. LAST-MODIFIED Not Required LOCATION Not Required PRIORITY Not Required RELATED-TO Not Required REQUEST-REPLY Excluded RDATE Not Required. RRULE Not Required. RESOURCES Not Required RESPONSE-SEQUENCE Excluded SEQUENCE Required, If not zero. STATUS Not Required, Value only one of TENTATIVE | ACCEPTED | CANCELLED. This property is used by the originator to indicate the consensus for the to-do, not a status on any of the attendees. SUMMARY Not Required, May be NULL text. TRANSP Excluded URL Not Required Dawson/Hopson/Mansour/Silverberg 16 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 UID Required, Must be maintained by the recipients. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties ATTACH Not Required CATEGORIES Required, If an alarm is specified COMMENT Not Required CREATED Not Required DESCRIPTION Not Required DTSTART Required, If an alarm is specified DURATION Required, If an alarm is specified LAST-MODIFIED Not Required RELATED-TO Not Required REPEAT Required, If an alarm is specified SUMMARY Not Required URL Not Required Freebusy Properties Freebusy component is excluded from this message type. Non-standard Properties X-token Not Required, but recipient may choose to ignore those non-standard properties, specified as Not Required. Dawson/Hopson/Mansour/Silverberg 17 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 3.2.3 TODO-REPLY The TODO-REPLY is used to by the attendees to reply to the originator of the to-do request with their status. The attendees can indicate their status is a TENTATIVE acceptance, that they have ACCEPTED the assignment, that they DECLINED the assignment or that they have COMPLETED the assignment. Once an attendee has replied to the request, they can subsequently reply with a different value. TODO-REPLY Calendar Properties COMMENT Not Required GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"TODO-REPLY" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties Event component is excluded from this message type. To-do Component Properties ATTACH Excluded ATTENDEE Required, Value is an RFC822 mailbox address for C&S capability. Must be the address of the recipient replying. CATEGORIES Excluded CLASS Excluded COMMENT Text value. Provides a comment from the recipient to the originator about the reply. For example, "I am too busy to accept this assignment." Dawson/Hopson/Mansour/Silverberg 18 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 CREATED Excluded COMPLETED Not Required DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Excluded EXDATE Not Required. Specifies the dates that are exceptions to the status update. EXRULE Not Required. Specifies the rule that defines the exceptions to the status update. LAST-MODIFIED Excluded LOCATION Excluded PRIORITY Excluded RELATED-TO Excluded REQUEST-STATUS Not Required. Any of the values defined in the table below. RDATE Excluded RRULE Excluded RESOURCES Excluded RESPONSE-SEQUENCE Required, If not zero. SEQUENCE Required, If not zero STATUS Excluded. Status for attendee must be specified in STATUS parameter of ATTENDEE property. Dawson/Hopson/Mansour/Silverberg 19 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 SUMMARY Excluded TRANSP Excluded URL Excluded UID Required, Must be the UID of the EVENT-REQUEST associate with the reply. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties Alarm component is excluded from this message type. Freebusy Properties Freebusy component is excluded from this message type. Non-Standard Properties X-token Not Required, but recipient may choose to ignore those non-standard properties, specified as Not Required. 3.2.4 TODO-CANCEL The TODO-CANCEL is used to by the originator of the to-do request to convey a cancellation notice of the to-do to the attendees. The message is only sent by the to-do OWNER or ORGANIZER to the recipients of the original to-do request. TODO-CANCEL Calendar Properties COMMENT Not Required GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"TODO-CANCEL" PROFILE-VERSION Required, Value must be "1.0". Dawson/Hopson/Mansour/Silverberg 20 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties Event component is excluded from this message type. To-do Component Properties ATTACH Excluded ATTENDEE Excluded CATEGORIES Excluded CLASS Excluded CREATED Excluded COMMENT Not Required, Text value. Provides a comment from the originator to the attendees concerning the cancellation notice. COMPLETED Excluded DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Excluded DTSTART Excluded EXDATE Excluded EXRULE Excluded LAST-MODIFIED Excluded LOCATION Excluded PRIORITY Excluded RELATED-TO Excluded Dawson/Hopson/Mansour/Silverberg 21 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 REQUEST-STATUS Excluded RDATE Excluded RRULE Excluded RESOURCES Excluded RESPONSE-SEQUENCE Excluded SEQUENCE Required, if not zero. Is not incremented by this action. STATUS Not Required, If present value must be "CANCELLED". SUMMARY Excluded TRANSP Excluded URL Not Required UID Required, Must be the UID of the original EVENT-REQUEST associated with the cancellation notice. Journal Component Properties Journal component is excluded from this message type. Alarm Properties Alarm component is excluded from this message type. Freebusy Protperties Freebusy component is excluded from this message type. Non-standard Properties X-token Not Required, But recipient may choose to ignore those non-standard properties, specified as optional. 3.2.5 Rescheduling or Changing a To-do When an owner/organizer desires to reschedule or change some detail of one of their existing to-do requests, they effect this change by conveying a new to-do request with the same UID and an incremented Dawson/Hopson/Mansour/Silverberg 22 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 sequence number. The receiving client must correlate the request to their existing to-dos and check the sequence number in order to realize that the request is actually a replacement for the existing to-do. Individual "A" sends a to-do request to "B" and "C". "B" accepts the to-do and "C" declines and includes text in the comments property proposing a more appropriate due date. "A" sends "B" and "C" another to-do request using the same UID and a sequence number one greater than the original request. "B" should infer that the to-do request message is actually a replacement for the existing to-do. Replacing a to-do request is predicated on using the same UID, incrementing the sequence number and replacing the changed calendar properties. TODO-REQUEST (replacing an existing to-do description) Calendar Properties COMMENT Not Required GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"TODO-REQUEST" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties COMMENT Not Required CREATED Not Required DAYLIGHT Not Required DTSTART Required DTEND Not Required RDATE Not Required, Either RDATE or RRULE may be specified, but not both. RRULE Not Required, Either RDATE or RRULE may be specified, but not both. TZNAME Not Required TZOFFSET Required Dawson/Hopson/Mansour/Silverberg 23 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 TZTRANS Not Required Event Component Properties Event component is excluded from this message type. To-do Component Properties ATTACH Not Required, "VALUE=URL" only. ATTENDEE Required, Value is an RFC822 mailbox address for C&S capability. STATUS parameter is either absent or has value "NEEDS ACTION". CATEGORIES Not Required CLASS Not Required COMMENT Not Required CREATED Not Required COMPLETED Excluded DESCRIPTION Required, Value may be NULL text. DUE Not Required, must be after or the same as the DTSTART date/time. DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Required EXDATE Not Required. EXRULE Not Required. LAST-MODIFIED Not Required LOCATION Not Required PRIORITY Not Required Dawson/Hopson/Mansour/Silverberg 24 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required RRULE Not Required RESOURCES Not Required RESPONSE-SEQUENCE Excluded SEQUENCE Must be greater than 0 and should be monotomically incremented for each request STATUS Not Required, Value only one of TENTATIVE | CONFIRMED | CANCELLED. This property is used by the originator to indicate the consensus for the to-do, not a status on any of the attendees. SUMMARY Not Required, May be NULL text. TRANSP Excluded URL Not Required UID Required, Must match the original meeting request which this request replaces Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties ATTACH Not Required CATEGORIES Required, If an alarm is specified CREATED Not Required DESCRIPTION Not Required DTSTART Required, If an alarm is specified Dawson/Hopson/Mansour/Silverberg 25 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 DURATION Required, If an alarm is specified LAST-MODIFIED Not Required RELATED-TO Not Required REPEAT Required, If an alarm is specified SUMMARY Not Required URL Not Required Freebusy Component Properties Freebusy component is excluded from this message type. Non-standard Properties X-token Not Required, but recipient may choose to ignore those non-standard properties, specified as Not Required. 3.2.6 TODO-RESEND The TODO-RESEND is used by attendees to request the latest version of a TODO-REQUEST. By issuing an TODO-RESEND, with the appropriate UID and optionally a RECURRENCE-ID, the organizer's CUA should respond with the latest version of the to-do. This message type is intended to be machine processed. TODO-RESEND Calendar Properties COMMENT Not Required GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"TODO-RESEND" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties Dawson/Hopson/Mansour/Silverberg 26 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 Timezone component is excluded from this message type. Event Component Properties Event component is excluded from this message type. To-do Component Properties ATTACH Excluded ATTENDEE Excluded CATEGORIES Excluded CLASS Excluded CREATED Excluded COMMENT Not Required, Text value. Provides a comment from the attendee to the organizer concerning the resend request. COMPLETED Excluded DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Excluded EXDATE Excluded EXRULE Excluded LAST-MODIFIED Excluded LOCATION Excluded PRIORITY Excluded RELATED-TO Excluded REQUEST-STATUS Excluded Dawson/Hopson/Mansour/Silverberg 27 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 RDATE Excluded RRULE Excluded RECURRENCE-ID Not Required. If the attendee wishes to receive an updated instance of a recurring to-do, then the RECURRENCE-ID can be included and only the specific instance will be returned. RESOURCES Excluded RESPONSE-SEQUENCE Excluded SEQUENCE Required, if not zero. Is not incremented by this action. STATUS Excluded SUMMARY Excluded TRANSP Excluded URL Excluded UID Required, Must be the UID of the original EVENT-REQUEST associated with the cancellation notice. Journal Component Properties Journal component is excluded from this message type. Alarm Properties Alarm component is excluded from this message type. Freebusy Protperties Freebusy component is excluded from this message type. Non-standard Properties X-token Not Required, But recipient may choose to ignore those non-standard properties, specified as optional. Dawson/Hopson/Mansour/Silverberg 28 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 3.3 Request Status Codes The following is a list of possible return status codes values: Short Longer Return Status Offending Data Return Description Status Code 200 Success. None. 201 Success, but fallback Property name and taken on one or more value may be property values. specified. 202 Success, invalid Property name may be property ignored. specified. 203 Success, invalid Property parameter property parameter name and value may be ignored. specified. 204 Success, unknown non- Non-standard property standard property name may be ignored. specified. 205 Success, unknown non- Property and non- standard property value standard value may be ignored. specified. 206 Success, invalid Calendar component calendar component sentinel (e.g., ignored. "BEGIN:ALARM") may be specified. 207 Success, request Original and forwarded to calendar forwarded RFC822 user. addresses may be specified. 208 Success, repeating event RRULE or RDATE ignored. Scheduled as a property name and single event. value may be specified. 209 Success, truncated end DTEND property value date/time to date may be specified. boundary. 210 Success, repeating to-do RRULE or RDATE ignored. Scheduled as a property name and Dawson/Hopson/Mansour/Silverberg 29 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 single to-do. value may be specified. 300 Invalid property name. Property name may be specified. 301 Invalid property value. Property name and value may be specified. 302 Invalid property Property parameter parameter. name and value may be specified. 303 Invalid property Property parameter parameter value. name and value may be specified. 304 Invalid calendar Calendar component component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 305 Invalid date or time. Date/time value(s) may be specified. 306 Invalid rule. Rule value may be specified. 307 Invalid calendar user. Attendee property value may be specified. 308 No authority. PROFILE and ATTENDEE property values may be specified. 309 Unsupported version. VERSION property name and value may be specified. 310 Request entity too None. large. 400 Event conflict. DTSTART and DTEND Date/time is busy. property name and values may be specified. 500 Request not supported. Profile property value may be specified. Dawson/Hopson/Mansour/Silverberg 30 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 501 Service unavailable. ATTENDEE property value may be specified. 502 Invalid calendar ATTENDEE property service. value may be specified. 503 No scheduling support ATTENDEE property for user. value may be specified. 4. Examples 4.1 Published To-Dos In the calendaring and scheduling context, publication refers to the one way transfer of to-do information. Consumers of published to-dos simply incorporate the to-do into a calendar. No reply is expected. Individual "A" publishes a to-do. Individual "B" reads the to-do and incorporates it into their calendar. To-dos can be published in several ways including: embedding the to-do as an object in a web page, e-mailing the to-do to a distribution list, and posting the to- do to a newsgroup. The table below illustrates the sequence of to-dos between the publisher and the consumers of a published to-do. Action Organizer Attendee Publish a to-do "A" sends or posts a TODO-PUBLISH message "B" reads the to- do publication Publish an updated "A" sends or posts a to-do TODO-PUBLISH message "B" reads the updated to-do publication Cancel a published "A" sends or posts a to-do toDO-CANCEL message "B" reads the canceled to-do Dawson/Hopson/Mansour/Silverberg 31 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 publication 4.1.1 A Minimal Published To-Do The iCalendar Object below describes a single to-do is due on October 1, 1997 at 20:00 UTC. This to-do contains the minimum set of properties for an iTIP to-do component. BEGIN:VCALENDAR PROFILE:TODO-PUBLISH PROFILE-VERSION:1.0 PRODID:-//ACME/DesktopCalendar//EN VERSION:2.0 BEGIN:VTODO DUE:19971001T200000Z SUMMARY:Book Report on Fiction Novel UID:0981234-1234234-2300 DTSTAMP:19970717T200000Z END:VTODO END:VCALENDAR 4.1.2 Changing A Published To-Do The iCalendar Object below describes an update to the to-do described in 4.1.1, the due date has been changed, a start time has been added, and the sequence number has been adjusted. BEGIN:VCALENDAR PROFILE:TODO-PUBLISH PROFILE-VERSION:1.0 VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VTODO DTSTART:19970901T210000Z DUE:19971005T200000Z SEQUENCE:2 UID:0981234-1234234-2300 SUMMARY:Book Report on Fiction Novel DTSTAMP:19970717T200000Z STATUS:NEEDS-ACTION END:VTODO END:VCALENDAR To identify the to-do the client uses the UID. The SEQUENCE property indicates that this is the second change to the to-do. To-dos with sequence numbers 0 and 1 are superseded by this to-do. The SEQUENCE property provides a reliable way to distinguish different versions of the same to-do. Each time a to-do is published, its sequence number is incremented. If a client receives a to-do with a sequence number 5 and finds it has the same to-do with sequence number 2, the to-do should be updated. However, if the client Dawson/Hopson/Mansour/Silverberg 32 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 received a to-do with sequence number 2 and finds it already has sequence number 5 of the same to-do, the to-do should not be updated. 4.1.3 Canceling A Published To-Do The iCalendar Object below cancels the to-do described in 4.1.1. This cancels the to-do with SEQUENCE numbers 0, 1, and 2. BEGIN:VCALENDAR PROFILE:TODO-CANCEL PROFILE-VERSION:1.0 VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VTODO COMMENT:As discussed in class, you are all off the hook! SEQUENCE:2 UID:0981234-1234234-2300 STATUS:CANCELLED DTSTAMP:19970717T200000Z END:VTODO END:VCALENDAR 4.1.4 A Rich Published To-Do This example describes the same to-do as in 4.1.1, but in much greater detail. BEGIN:VCALENDAR BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19970406T000000 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY TZNAME:CDT TZOFFSET:-0500 TTRANS:020000 END:VTIMEZONE BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19970101T000000 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY TZNAME:CST TZOFFSET:-0600 TTRANS:020000 END:VTIMEZONE PRODID:-//ACME/DesktopCalendar//EN PROFILE:TODO-PUBLISH PROFILE-VERSION:1.0 CALSCALE:GREGORIAN SOURCE:http://www.acmeu.edu/courses/eng-lit-101/Fall97-to-dos.or4 Dawson/Hopson/Mansour/Silverberg 33 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 NAME:English Literature 101 Course Calendar VERSION:2.0 BEGIN:VTODO ATTACH:http://www.midwaystadium.com/courses/eng-lit-101/ CATEGORIES:EDUCATION;COURSE-ASSIGNMENT CLASS:PRIVATE CREATED:19970415T194319Z DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book Report = 1=0A=0D= Fiction=0A=0D= Dr. Ling must approve the book you choose=0A=0D= book report structure can be found on:= http://www.acmeu.com/courses/eng-lit-101/bookreports.html DTSTART:19970901T210000Z DUE:19971005T200000Z COMPLETED:19971005T150000Z DTSTAMP:19970717T200000Z SEQUENCE:2 UID:0981234-1234234-2300 LAST-MODIFIED:19971005T132421Z RESOURCES:COMPUTER,PRINTER LOCATION;VALUE=URL:http://www.acmeu.com/campusmaps/haaghall.html PRIORITY:2 SEQUENCE:3 SUMMARY:Book Report on Fiction Novel UID:0981234-1234234-2300 STATUS:NEEDS-ACTION RELATED-TO:0981234-1234234-1400 BEGIN:VALARM DTSTART:19970910T190000Z REPEAT:2 DURATION:PT2H CATEGORIES:DISPLAY,AUDIO DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book report rough draft END:VALARM BEGIN:VALARM DTSTART:19970930T153000 CATEGORIES:DISPLAY,AUDIO DESCRIPTION:You should be reviewing your final book report draft. END:VALARM END:VTODO END:VCALENDAR The CLASS property is specified, though it is not really needed here. Since this is a published to-do, a program that displays it need not apply any content filtering based on the CLASS attribute. If this to- do is copied into a users calendar, the CLASS would be included as Dawson/Hopson/Mansour/Silverberg 34 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 part of the copy. The handling of the CLASS tag at that point is implementation specific. The RELATED-TO field contains the UID of a related calendar to-do or event. The handling of this property is application dependent. VTIMEZONE components are discussed in detail in iTIP Part 1. The sequence number 3 indicates that this to-do supersedes versions 0, 1, and 2. 4.2 Group To-Do Examples Group to-dos are distinguished from published to-dos in that there is interaction between the attendees with respect to the to-do. 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. The table below illustrates the message flow. Action Organizer Attendee Initiate a "A" sends TODO- to-do REQUEST message request to "B", "C", and "D" Accept the "B" sends TODO- to-do REPLY message to request "A" with its ATTENDEE/STATUS property parameter set to "ACCEPTED" Decline the "C" sends TODO- to-do REPLY message to request "A" with its ATTENDEE/STATUS property parameter set to "DECLINED" Tentatively "D" sends TODO- accept the REPLY message to to-do "A" with its request ATTENEE/STATUS property parameter set to "TENTATIVE" Confirm to- "A" sends TODO- Dawson/Hopson/Mansour/Silverberg 35 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 do status REQUEST message with to "B" and "C" attendees with current information for to-do. SEQUENCE property is "1". 4.2.1 A To-Do Request A sample to-do request that "A" sends to "B", "C", and "D". BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:TO-DO-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VTODO ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com DTSTART:19970701T100000-0700 DUE:19970722T100000-0700 SUMMARY:Create the requirements document UID:www.acme.com-873970198738777-00 SEQUENCE:0 DTSTAMP:19970717T200000Z STATUS:NEEDS-ACTION END:VTODO END:VCALENDAR Note that the conference room does not have a valid e-mail address. 4.2.2 A To-Do Reply Attendee "B" accepts the meeting. BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:TODO-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VTODO ATTENDEE;STATUS=ACCEPTED:B@acme.com UID:www.acme.com-873970198738777-00 COMMENT:I'll send you my input by e-mail SEQUENCE:0 RESPONSE-SEQUENCE:0 DTSTAMP:19970717T200000Z REQUEST-STATUS:0;Success END:VTODO Dawson/Hopson/Mansour/Silverberg 36 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 END:VCALENDAR "B" could have declined the meeting or indicated tentative acceptance by setting the ATTENDEE;STATUS parameter to DECLINED or TENTATIVE, respectively. 4.2.3 Update A To-do The to-do is moved to a different time. The combination of the UID (which remains the same) and the SEQUENCE (bumped to 1) properties indicate the update. BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:TODO-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VTO-DO ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com DTSTART:19970701T110000-0700 DUE:19970722T100000-0700 COMPLETED:19970720T090000-0700 DTSTAMP:19970717T200000Z STATUS:COMPLETED SUMMARY:Create the requirements document UID:www.acme.com-873970198738777 SEQUENCE:1 END:VTODO END:VCALENDAR 4.3 Recurring To-do and Time Zone Examples 4.3.1 A Recurring To-do That Spans Timezones This to-do describes a weekly status report. The attendees are each in a different timezone. BEGIN:VCALENDAR BEGIN:VTIMEZONE DAYLIGHT:TRUE DTSTART:19970406T000000 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY TZNAME:PDT TZOFFSET:-0700 TTRANS:020000 END:VTIMEZONE Dawson/Hopson/Mansour/Silverberg 37 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19970126T000000 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY TZNAME:PST TZOFFSET:-0800 TTRANS:020000 END:VTIMEZONE PRODID:-//ACME/DesktopCalendar//EN PROFILE:TODO-REQUEST VERSION:2.0 BEGIN:VTODO ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:sman@mcom.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:gb@mcom.fr ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:kimiko@mcom.jp DTSTART:19970701T140000 DUE:19970701T150000 RRULE:INTERVAL=20;WKST=SU;BYDAY=TU;FREQ=WEEKLY RDATE:19970910T140000 EXDATE:19970909T140000 EXDATE:19971028T150000 SUMMARY:Weekly Status Report UID:www.acme.com-873970198738777 SEQUENCE:0 DTSTAMP:19970601T200000Z STATUS:NEEDS-ACTION END:VTODO END:VCALENDAR Timezone components should appear in an iCalendar Object containing recurring to-dos. This is especially important if a recurring to-do has attendees in different timezones. There can be multiple VTIMEZONE components in an iCalendar Object. However, they must be used to define the same timezone. That is, there cannot be VTIMEZONE components describing both PST/PDT and EST/EDT at the component level in the same iCalendar Object. The first two components of this iCalendar Object are the timezone components. The DTStart date coincides with the first instance of the RRULE property. The recurring to-do is defined in a particular timezone, presumably that of the creator. The client for each attendee has the responsibility of determining the recurrence time in the attendee's timezone. The first instance of the to-do starts on Tuesday, July 1, 1997 at 2:00pm. Since no timezone is specified in the DTSTART property, the timezone component of PDT applies to the start and end times. Attendee gb@mcom.fr is in France where the local time on this date is Dawson/Hopson/Mansour/Silverberg 38 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 7 hours later than PDT or 21:00. Attendee kimiko@mcom.jp is in Japan where local time is 9 hours ahead of than UTC or Wednesday, July 2 at 07:00. The to-do repeats weekly on Tuesdays (in PST/PDT). The RRULE results in 20 instances. The last instance falls on Tuesday, November 11, 1997 2:00pm PST. The RDATE adds another instance: WED, 10-SEP- 1997 21:00 GMT. There are two exceptions to this recurring appointment. The first one is: TUE, 09-SEP-1997 21:00 GMT TUE, 09-SEP-1997 14:00 PDT WED, 10-SEP-1997 07:00 JDT and the second is: TUE, 28-OCT-1997 22:00 GMT TUE, 28-OCT-1997 14:00 PST WED, 29-OCT-1997 07:00 JST 4.3.2 Creating an Exception to a Recurring To-Do The following example illustrates a scenario where a to-do organizer changes an instance of an existing recurring to-do. In this case the organizer is changing the start and end time. Original Request: BEGIN:VCALENDAR PROFILE:TODO-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTODO CREATED:19970526T083000 UID:guid-1.host1.com-001 SEQUENCE:0 RRULE:BYMONTHDAY=1;FREQ=MONTHLY ATTENDEE;ROLE=ORGANIZER;STATUS=ACCEPTED:Sman@netscape.com ATTENDEE;RSVP=YES:fdawson@earthlink.net ATTENDEE;RSVP=YES:Deriks@Microsoft.com ATTENDEE;RSVP=YES:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:Merge document updates DTSTART:19970601T210000Z DUE:19970601T220000Z LOCATION:Conference Call DTSTAMP:19970601T200000Z STATUS:NEEDS-ACTION END:VTODO END:VCALENDAR Dawson/Hopson/Mansour/Silverberg 39 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 To-do Request to change a time and create an exception: BEGIN:VCALENDAR PROFILE:TODO-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTODO UID:guid-1.host1.com-001 SEQUENCE:1 RECURRENCE-ID:19970701T210000Z DTSTART:19970703T210000Z DUE:19970703T220000Z DTSTAMP:19970701T200000Z END:VTODO END:VCALENDAR 4.3.3 Modify Exception In this example the organizer has already created an exception and now wishes to make additional property modification. The organizer must use both the RECURRENCE-ID and UID to reference the exception. BEGIN:VCALENDAR PROFILE:TODO-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTODO UID:guid-1.host1.com-001 SEQUENCE:2 RECURRENCE-ID:19970701T210000Z ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com ATTENDEE;EXPECT=REQUEST:RHopson@dev.davinci.com DESCRIPTION:Emergency Meeting CLASS:Private DTSTAMP:19970701T200000Z STATUS:NEEDS-ACTION END:VTODO END:VCALENDAR This example changes the specific instance properties without changing the recurring meeting parent. 4.3.4 Cancel an Exception In the following example, the organizer has created an exception as in 4.3.2 and now wishes to cancel it. In this case a TODO-CANCEL is sent with the specific RECURRENCE-ID and UID of the exception. Dawson/Hopson/Mansour/Silverberg 40 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 BEGIN:VCALENDAR PROFILE:TODO-CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTODO UID:guid-1.host1.com-001 RECURRENCE-ID:19970701T210000Z SEQUENCE:2 DTSTAMP:19970701T200000Z STATUS:CANCELLED END:VTODO END:VCALENDAR 4.3.5 Cancel Recurring To-Do In this example the organizer wishes to cancel the entire recurring to-do and any child exceptions. BEGIN:VCALENDAR PROFILE:TODO-CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTODO UID:guid-1.host1.com-001 SEQUENCE:2 DTSTAMP:19970701T200000Z STATUS:CANCELLED END:VTODO END:VCALENDAR 4.3.6 Decline A Previously Accepted Exception In this example a recipient has accepted a TODO-REQUEST which is actually an exception. The recipient now wishes to decline after previously accepting Recipient initially accepts to-do request: BEGIN:VCALENDAR PROFILE:TODO-REPLY VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VTODO SEQUENCE:1 RESPONSE-SEQUENCE:1 UID:guid-1.host1.com-001 RECURRENCE-ID:19970701T210000Z ATTENDEE;STATUS=CONFIRMED:Deriks@Microsoft.com REQUEST-STATUS:0;Success DTSTAMP:19970701T200000Z RESPONSE-SEQUENCE:0 END:VTODO Dawson/Hopson/Mansour/Silverberg 41 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 END:VCALENDAR Recipient later wishes to decline the request to a recurring exception: BEGIN:VCALENDAR PROFILE:TODO-REPLY VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VTODO SEQUENCE:0 RESPONSE-SEQUENCE:1 UID:guid-1.host1.com RECURRENCE-ID:19970701T210000Z ATTENDEE;STATUS=Declined:Deriks@Microsoft.com REQUEST-STATUS:0;Success DTSTAMP:19970702T200000Z END:VTODO END:VCALENDAR 5. Application Protocol Fallbacks Applications that support iTIP are not required to support the entire protocol. The following describes how profiles and properties should "fallback" in applications that do not support the complete protocol. If a profile or property is not addressed in this section, it may be safely ignored. 5.1 ICalendar Profile Types Profile Fallback TODO-PUBLISH Required. TODO-CANCEL Required. TODO-REQUEST TODO-PUBLISH TODO-REPLY Required. 5.2 Calendar Components Component Fallback VALARM Reply with Not Supported. Dawson/Hopson/Mansour/Silverberg 42 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 VTIMEZONE Required if RRULE or RDATE is implemented; otherwise ignore and use local time. 5.3 Calendar Properties Property Fallback CALSCALE Ignore; assume GREGORIAN. GEO Ignore. PRODID Ignore. PROFILE Required as described in the Profiles section above. PROFILE- Assume "1.0". VERSION SOURCE Ignore NAME Ignore. VERSION Assume "2.0". 5.4 Component Properties Property Fallback ATTACH Ignore. ATTENDEE Required if TODO-REQUEST is not implemented; otherwise ignore. CATEGORIES Ignore. CLASS Ignore. COMMENT Ignore. COMPLETED Required. Dawson/Hopson/Mansour/Silverberg 43 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 CREATED Ignore. DAYLIGHT Required if VTIMEZONE is implemented; otherwise ignore. DESCRIPTION Required. DUE Required. DURATION Ignore. Reply with Not Supported. DTSTART Required. EXDATE Ignore. Reply with Not Supported. EXRULE Ignore. Reply with Not Supported. LAST- Ignore. MODIFIED LOCATION Ignore. PRIORITY Required. RELATED-TO Ignore. RDATE Ignore. If implemented, VTIMEZONE must also be implemented. RRULE Ignore. The first instance occurs on the DTStart property. RESOURCES Ignore. RESPONSE- Required. SEQUENCE SEQUENCE Required. STATUS Required. SUMMARY Ignore. TRANSP Required if FREEBUSY is implemented; otherwise Ignore. TZNAME Required if VTIMEZONE is implemented; otherwise Ignore. TZOFFSET Required if VTIMEZONE is implemented; otherwise Ignore. Dawson/Hopson/Mansour/Silverberg 44 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 TZTRANS Required if VTIMEZONE is implemented; otherwise Ignore. URL Ignore. UID Required. X- Ignore. 5.5 Latency Issues With a store-and-forward transport, it is possible for requests to arrive out of sequence. That is, an implementation may receive a TODO-CANCEL notification prior to receiving the original to-do request. This section discusses a few of these scenarios. 5.5.1 Cancelation of an Unknown To-do. When a TODO-CANCEL request is received before the original TODO- REQUEST the calendar will be unable to correlate the UID of the cancellation with an existing to-do. It is suggested that messages that cannot be correlated that also contain non-zero sequence numbers be held and not discarded. Implementations can age them out if no other messages arrive with the same UID and a lower sequence number. 5.6 Sequence Number Under some conditions, a CUA may receive requests and replies with the same SEQUENCE number. DTSTAMP is added to act as a tiebreaker when two items with the same SEQUENCE number are evaluated. Furthermore, the SEQUENCE number is only incremented when one or more of the following properties changes: DTSTART DTEND (for Events) LOCATION DUE 6. Security Considerations ITIP outlines 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 provides facilities for simple authentication using a clear text password, as well as any SASL mechanism [SASL]. SASL allows for integrity and privacy services to be negotiated. Dawson/Hopson/Mansour/Silverberg 45 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 Use of clear text password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties. 7. Acknowledgments A hearty thanks to the following individuals who have participated in the drafting, review and discussion of this memo: Anik Ganguly, Bruce Kahn, Leo Parker, John Rose, Vinod Seraphin, Richard Shusterman, Derik Stenerson, Kevin Tsurutome. 8. Bibliography [ID-DT] "Date and Time on the Internet", Internet-Draft, December 1996, http://www.imc.org/draft-newman-datetime. [ICAL] "Internet Calendaring and Scheduling Core Object Specification - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- drafts/draft-ietf-calsch-ical-02.txt. [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 00.txt. [ITIP-1] "iCalendar Transport-Independent Interoperability Protocol (iTIP) - Part 1: Scheduling Events and Busytime", Internet-Draft, July 1997, http://www.imc.org/draft-ietf-calsch-itip-part1-00.txt. [ITIP-2] "iCalendar Transport-Independent Interoperability Protocol (iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997, http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- yergeau-utf8-01.txt. [ISO8601] "Data elements and interchange formats - information interchange - Representation of dates and times", ISO 8601, 1996-06- 15, +1 (212) 642-4900 for ANSI Sales. [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions - Part One - Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996, http://www.imc.org/rfc2045.txt. [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions - Part Two - Media Types", RFC 2046, Innosoft, First Virtual, November 1996, http://www.imc.org/rfc2046.txt. [UNICODE] The Unicode Consortium, "The Unicode Standard -Version 2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described in section A-2. Dawson/Hopson/Mansour/Silverberg 46 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 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 MIME-VCARD, Electronic Business Card, format. The authors of this draft are: BEGIN:VCARD FN:Frank Dawson ORG:Lotus Development Corporation ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 3502;USA TEL;WORK;MSG:+1-919-676-9515 TEL;WORK;FAX:+1-919-676-9564 EMAIL;INTERNET:fdawson@earthlink.net URL:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD FN:Ross Hopson ORG:On Technology, Inc. ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St. Mall, Two Hannover Square;Raleigh;NC;27601 TEL;WORK;MSG:+1-919-890-4036 TEL;WORK;FAX:+1-919-890-4100 EMAIL;INTERNET:rhopson@on.com END:VCARD BEGIN:VCARD FN:Steve Mansour ORG:Netscape Communications Corporation ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain View;CA;94043;USA TEL;WORK;MSG:+1-415-937-2378 TEL;WORK;FAX:+1-415-428-4059 EMAIL;INTERNET:sman@netscape.com END:VCARD BEGIN:VCARD FN:Steve Silverberg ORG:Microsoft Corporation ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;98052-6399;USA TEL;WORK;MSG:+1-206-936-9277 TEL;WORK;FAX:+1-206-936-8019 EMAIL;INTERNET:stevesil@Exchange.Microsoft.com END:VCARD Dawson/Hopson/Mansour/Silverberg 47 Expires January 1998 Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997 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 FN:Anik Ganguly ORG:OnTime, Inc. ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern Highway;Southfield;MI;48075;USA TEL;WORK;MSG:+1-810-559-5955 TEL;WORK;FAX:+1-810-559-5034 EMAIL;INTERNET:anik@ontime.com END:VCARD Dawson/Hopson/Mansour/Silverberg 48 Expires January 1998