Network Working Group Steve Silverberg, Microsoft INTERNET-DRAFT Steve Mansour, Netscape Frank Dawson, Lotus Expires in six months from 18 July 1997 Ross Hopson, ON Technologies iCalendar Transport-Independent Interoperability Protocol (iTIP) Part One: Scheduling Events and BusyTime 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 busy time and the scheduling of events, to-dos, or journal entries on different calendaring and scheduling systems. These documents are based on earlier work documented in the iCalendar format. Because iCalendar dealt mainly with the format of calendaring information and said so little about the method for conveying scheduling semantics, these documents are largely orthogonal to (rather than a revision of) iCalendar. Part 1 specifies the messages for allowing searching busy time information and for scheduling events. Part 2 defines the messages for scheduling to-dos, or action items. Part 3 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). The breadth of this document is limited to exchanging calendar information only. It does not address issues related to tasks or journal Silverberg/Mansour/Dawson/Hopson 1 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 entries. Instead, the document outlines a model for calendar exchange that defines both static and dynamic event objects. Static event objects are used to transmit events from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic event objects are a superset of static event objects and will gracefully degrade to their static counterparts for clients that only support static appointment objects. Silverberg/Mansour/Dawson/Hopson 2 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Table of Contents: 1 INTRODUCTION.........................................................5 1.1 ITIP SCHEDULING TRANSACTIONS .....................................5 2 INTEROPERABILITY MODELS..............................................6 2.1 APPLICATION PROTOCOL .............................................6 2.1.1 Scheduling Transaction State ..................................7 2.2 ADVANCED CALENDARING CONCEPTS ....................................8 2.3 CALENDAR ROLES ...................................................8 2.4 DELEGATION .......................................................9 3 APPLICATION PROTOCOL ELEMENTS.......................................11 3.1 ITIP MESSAGE CONFORMANCE ........................................12 3.1.1 Restrictions on DTSTART and DTEND ............................12 3.2 SUMMARY OF APPLICATION PROTOCOL ELEMENTS ........................12 3.2.1 EVENT-PUBLISH ................................................12 3.2.2 EVENT-REQUEST ................................................16 3.2.3 EVENT-REPLY ..................................................20 3.2.4 EVENT-CANCEL .................................................24 3.2.5 EVENT-REQUEST for Replacing an Event .........................27 3.2.6 EVENT-COUNTER ................................................31 3.2.7 EVENT-DECLINECOUNTER .........................................35 3.2.8 EVENT-REQUEST for Delegation .................................38 3.2.9 BUSY-REQUEST .................................................46 3.2.10 BUSY-REPLY ..................................................50 3.2.11 EVENT-RESEND ................................................54 3.3 STATUS REPLIES ..................................................57 3.4 IMPLEMENTATION CONSIDERATIONS ...................................59 3.4.1 Working With Recurrence Instances ............................59 3.4.2 When To Resend An Event ......................................60 3.4.3 Timezones ....................................................64 3.4.4 Alarms .......................................................64 3.4.5 SUMMARY Property .............................................64 3.4.6 X-Tokens .....................................................64 4 EXAMPLES............................................................65 4.1 PUBLISHED EVENT EXAMPLES ........................................65 4.1.1 A Minimal Published Event ....................................66 4.1.2 Changing A Published Event ...................................66 4.1.3 Canceling A Published Event ..................................67 4.1.4 A Rich Published Event .......................................67 4.2 GROUP EVENT EXAMPLES ............................................68 4.2.1 A Group Event Request ........................................69 4.2.2 Reply To A Group Event Request ...............................70 4.2.3 Update An Event ..............................................70 4.2.4 Countering an Event Proposal .................................71 4.2.5 Delegate An Event ............................................73 4.2.6 Delegate Accepts the Meeting .................................75 Silverberg/Mansour/Dawson/Hopson 3 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 4.2.7 Delegate Declines the Meeting ................................76 4.2.8 Cancel A Group Event .........................................77 4.3 BUSY TIME EXAMPLES ..............................................78 4.3.1 Request Busy Time ............................................78 4.3.2 Reply To A Busy Time Request .................................79 4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ..........................79 4.4.1 A Recurring Event Spanning Timezones .........................79 4.4.2 Modify A Recurring Instance ..................................81 4.4.3 Cancel A Recurring Instance ..................................82 4.4.4 Cancel An Exception ..........................................82 4.4.5 Cancel Recurring Event .......................................83 4.4.6 Change All Future Instances ..................................83 4.4.7 Add A New Instance To A Recurring Event ......................83 4.4.8 Counter An Instance Of A Recurring Event .....................84 4.4.9 Error Reply To An EVENT-REQUEST ..............................85 5 APPLICATION PROTOCOL FALLBACKS......................................86 5.1 PROFILES ........................................................86 5.2 CALENDAR COMPONENTS .............................................86 5.3 CALENDAR PROPERTIES .............................................87 5.4 COMPONENT PROPERTIES ............................................87 5.5 LATENCY ISSUES ..................................................90 5.5.1 Cancelation of an Unknown Event. .............................90 5.5.2 Unexpected Reply from an Unknown Delegate ....................90 5.6 SEQUENCE NUMBER .................................................91 6 SECURITY CONSIDERATIONS.............................................92 7 ACKNOWLEDGMENTS.....................................................93 8 BIBLIOGRAPHY........................................................94 9 AUTHORS ADDRESSES...................................................95 APPENDIX A. TRANSPORT PROTOCOL CONSIDERATIONS.........................96 Silverberg/Mansour/Dawson/Hopson 4 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime 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 initial document specifies the messages for allowing searching for 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. Implemented as a whole, this document set will allow different calendaring and scheduling domains to interoperate; allowing for the search for available busy time information and scheduling events, to- dos, or daily journal entries. 1.1 iTIP Scheduling Transactions The profiles described in this document may be considered additions to [ICAL] and are designed specifically for the exchange of calendaring information between scheduling applications. Event Publication . Publish an event . Change a published event . Cancel a published event Group Events . Request an event to be scheduled on one or more recipients calendars; . Reply to an existing event request to confirm, decline, conform as tentative, or delegate the request; . Allow a recipient of an event to assign delegates to attend a meeting; . Allow the organizer of an event to cancel the event; . Allow the organizer of an event to replace the original event definition; . Allow an attendee the ability to negotiate event property changes . Allow attendee to request and receive meeting updates Free/Busy Time . Request busy time time data from one or more recipients; . Reply to a busy time request with busy time data; Recurring Events and Timezones . Support scheduling an event between individuals in different time zones; . Support for time zones; . Support for DST rules; . Create a recurring meeting request with exception dates Silverberg/Mansour/Dawson/Hopson 5 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 2 Interoperability Models There are two distinct protocols relevant to interoperability: an Application Protocol and a Transport Protocol. The Application Protocol defines the content of the iCalendar Objects sent between sender and receiver to accomplish the Scheduling Transactions listed in 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. The connection between Sender and Receiver in the diagram below refers to the Application Protocol. In particular, the iCalendar Objects passed from the Sender to the Receiver which conform to those presented in Section 2.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 can work with bindings for the store-and-forward transport, the real time transport, or both. Also note that iTIP could 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 centered around the organizer of the event. That is, the organizer of a request sends it out to one or more invitees. The attendees reply back to the organizer. The organizer maintains the status of the event. The data sources for the application protocol are the Calendar Users [ICMS]. Examples of these users are the organizer and attendees of an Silverberg/Mansour/Dawson/Hopson 6 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 iCalendar event. The data objects are the iCalendar Objects that are exchanged between Calendar Users. 2.1.1 Scheduling Transaction State The state of the event scheduling transaction is described by the STATUS and ATTENDEE properties in the event calendar component. The state of an event 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 event. When an organizer sends out the event request its 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. These changes in the attendee status for the event are effected by the attendee sending the organizer an EVENT-REPLY message. The status of the event is reflected by the STATUS property. The event STATUS property is controlled by the organizer. There is no default status. The organizer can either set the event status to TENTATIVE or CONFIRMED. The organizer can also set the status to CANCELLED by sending an EVENT-CANCEL message to the attendees. 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. +=======================+=====================+===================+ | Organizer | Attendee | Delegate | +=======================+=====================+===================+ | | | EVENT-PUBLISH ------------------------> | | Status=CONFIRMED | | | +=======================+=====================+===================+ | | | EVENT-REQUEST ------------------------> | | Status=CONFIRMED | TENTATIVE | | Attendee Status=NEEDS-ACTION | | | | <--------------------------------EVENT-REPLY | | Status=As specified in the EVENT-REQUEST message | | Attendee Status=ACCEPTED | DECLINED | TENTATIVE | | | +=======================+=====================+===================+ | | | EVENT-REQUEST ------------------------> | | Status=CONFIRMED | TENTATIVE | | Attendee Status=NEEDS-ACTION | | | | <--------------------------------EVENT-REPLY | | Attendee Status=DELEGATED | | | Silverberg/Mansour/Dawson/Hopson 7 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 | EVENT-DELEGATE----------------> | | Attendee Status=NEEDS-ACTION | | | | <------------------------------------------------EVENT-REPLY | | <----------------------EVENT-REPLY | | Attendee Status=ACCEPTED | DECLINED | TENTATIVE | | | +=======================+=====================+===================+ | | | EVENT-CANCEL ------------------------> | | Status=CANCELLED | | Attendee Status=As specified in the EVENT-REPLY | | | +=======================+=====================+===================+ | | | EVENT-REQUEST ------------------------> | | (A rescheduled or redefined event) | | Status=CONFIRMED | TENTATIVE | | Attendee Status=As defined in previous EVENT-REPLY | | message for this event | | | +=======================+=====================+===================+ 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 an event 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 events. The message format is designed to be used equally well with a MIME electronic messaging transport, real time protocols, and other Internet and non-Internet message 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 an event to change or cancel the original request. The elements of the protocol also include the notion of user roles. 2.3 Calendar Roles Roles are a behavior or set of activities performed by particular groups of users or agents at a given state of the application. This specification describes 4 roles that determine a range of actions and responsibilities specific to each role. When scheduling an appointment with 1 or more individuals, there are 2 roles: Organizer and attendee. The organizer sends the meeting request and receives responses from attendees. The organizer is implicitly, the owner of the meeting. Silverberg/Mansour/Dawson/Hopson 8 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 However, there are scenarios where the owner has a delegate who acts on the owner's behalf, as is the case when an assistant books a meeting. 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 contains this event. A delegate role is created when an attendee delegates an event or task to another CUA. Role Description Organi The organizer is the user that sends and manages zer the event _ meaning responses are directed to the organizer. In most cases the organizer is also the owner, but in cases where the owner delegates organizer responsibility to a delegate the organizer becomes a proxy for the owner. The organizer in this case would place the meeting on the calendar of the owner. Owner The owner usually controls direct manipulation of the event. The owner is usually the organizer but in some cases a delegate or proxy will act on behalf of the owner and organize the meeting and logistics. The organizer can make unilateral changes to the event while the attendees can only act through the organizer. Attend Attendees are those recipients who are invited to ees the meeting. When an attendee responds the status property is set to either accept, decline or tentative. A delegate may respond on behalf of an attendee. Delega A delegate is a proxy that acts on behalf of an te attendee. 2.4 Delegation The calendaring and scheduling model identifies three types of delegation. 1. When an owner delegates calendar management to an organizer who acts on the owner's behalf 2. When an attendee grants delegate status to another calendar user Silverberg/Mansour/Dawson/Hopson 9 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 who responds to requests on behalf of the attendee. 3. When an attendee delegates an event request to another calendar user who then becomes an attendee. This document discusses only item 3. Items 1 and 2 are described in the calendar access protocol (as described in [ICMS]). When an attendee delegates an Event-Request they are required to notify the organizer using an Event-Reply. This contains the necessary information for the organizer to discern that the request was delegated and the identity of the delegate. Section 3.2.8 describes the delegation process in detail. Silverberg/Mansour/Dawson/Hopson 10 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 following describes the various [ICAL] Profile Types supported in this specification. Profile Type Description EVENT-PUBLISH Post notification of an event. Used primarily as a method of advertising the existence of an event. EVENT-REQUEST Make a request for an event. This is an explicit invitation to one or more attendees. Event Requests are also used to update or change an existing event. Clients that cannot handle EVENT-REQUEST can degrade the event to view it as an EVENT-PUBLISH. EVENT-REPLY Reply to an event request. This includes "Accept", "Tentative", "Decline" and "Delegate". EVENT-CANCEL Cancel an existing event request. BUSY-REQUEST Request busy time data BUSY-REPLY Reply to a free/busy time request EVENT-COUNTER Counter EVENT-REQUEST with alternative properties EVENT- Decline counter-request by attendee DECLINECOUNTER EVENT-RESEND A request sent to an event organizer asking for the latest version of an event Silverberg/Mansour/Dawson/Hopson 11 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 to be resent to the requester. 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 events (where posting means to local calendar). Therefore, profiles such as EVENT-REQUEST will contain an exact superset of the EVENT-PUBLISH property set such that a client that supported EVENT-PUBLISH could still read an event 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. 3.1.1 Restrictions on DTSTART and DTEND DTStart must always be specified. Events containing DTEnd without a DTStart are not allowed. If the end time is known, the DTEnd parameter should be specified. The duration 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 EVENT-PUBLISH The EVENT-PUBLISH is somewhat unique in this document in that it has no interactivity associated with it. Instead, it is simply an event that can be added by a calendar user agent to a calendar as a static event. It requires and accepts no responses to the organizer. Its expected usage is for encapsulating an arbitrary event as an iCalendar object. EVENT-PUBLISH Calendar Properties GEO Not Required Silverberg/Mansour/Dawson/Hopson 12 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PRODID Required VERSION Required, Value must be "2.0". PROFILE Required, Value must be "EVENT- PUBLISH" 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 Silverberg/Mansour/Dawson/Hopson 13 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 ATTACH Not Required ATTENDEE Not Required CATEGORIES Not Required CLASS Not Required CREATED Not Required COMPLETED Excluded DESCRIPTION Required, Value may be NULL text. DUE Excluded DURATION Excluded DTEND Not Required DTSAMP Required DTSTART Required EXDATE Not Required EXRULE Not Required LAST-MODIFIED Not Required LOCATION Not Required PRIORITY Not Required Silverberg/Mansour/Dawson/Hopson 14 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required, See issues list. RRULE Not Required, See issues list. RESOURCES Not Required RESPONSE-SEQUENCE Excluded SEQUENCE Required, if not 0 STATUS Excluded SUMMARY Not Required, May be NULL text. TRANSP Excluded URL Not Required UID Required 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 Silverberg/Mansour/Dawson/Hopson 15 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime 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 Non-standard Properties Excluded-token Not Required, but recipient may choose to ignore those non-standard properties, specified as Not Required. 3.2.2 EVENT-REQUEST The EVENT-REQUEST is used to both describe an event and invite potential attendees. It uses the ICAL property set to describe the meeting in terms of date/time, location, recurrence, attendees etc. When an EVENT- REQUEST is received by a user or agent it should be responded to with an event reply. The table below describes the both the required and complete property set that make up an EVENT-REQUEST. EVENT-REQUEST Calendar Properties GEO Not Required PRODID Required VERSION Value must be "2.0". Silverberg/Mansour/Dawson/Hopson 16 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PROFILE Required,"EVENT-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 TZTRANS Not Required Event Component Properties ATTACH Not Required Silverberg/Mansour/Dawson/Hopson 17 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 CREATED Not Required COMPLETED Excluded DESCRIPTION Required, Value may be NULL text. DUE Excluded DURATION Excluded DTEND Not Required, Must be a date/time after DTSTART. May span date boundary. DTSTAMP Required DTSTART Required EXDATE Not Required, See issues list. EXRULE Not Required, See issues list. LAST-MODIFIED Not Required LOCATION Not Required Silverberg/Mansour/Dawson/Hopson 18 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PRIORITY Not Required RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required, See issues list. RRULE Not Required, See issues list. RESOURCES Not Required RESPONSE-SEQUENCE Excluded SEQUENCE Required, If not zero STATUS Not Required, Value only one of TENTATIVE | CONFIRMED. This property is used by the organizer to indicate the consensus for the meeting, not a status on any of the attendees. SUMMARY Not Required, May be NULL text. TRANSP Excluded URL Not Required UID Required, Must be maintained by the recipients. Alarm Component Properties ATTACH Not Required Silverberg/Mansour/Dawson/Hopson 19 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 CATEGORIES Required, If an alarm is specified 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 Non-standard Properties Excluded-token Not Required, but recipient may choose to ignore those non- standard properties, specified as Not Required. 3.2.3 EVENT-REPLY The Event-Reply is used to RSVP and to Delegate. EVENT-REPLY Silverberg/Mansour/Dawson/Hopson 20 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Calendar Properties GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"EVENT-REPLY" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties Timezone component is excluded from this message type. Event 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 Required comment from the attendee to the organizer about the reply. For example, "I can't travel this far for Required meeting." CREATED Excluded COMPLETED Excluded Silverberg/Mansour/Dawson/Hopson 21 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Excluded EXDATE Not Required. See issues list. Specifies the dates that are exceptions to the status update. EXRULE Not Required. See issues list. Specifies the rule that defines the exceptions to the status update. LAST-MODIFIED Excluded LOCATION Excluded PRIORITY Excluded RELATED-TO Excluded REQUEST-STATUS Any of the values defined in the table below in section 3.3. RDATE Excluded RRULE Excluded Silverberg/Mansour/Dawson/Hopson 22 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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. SUMMARY Excluded TRANSP Excluded URL Excluded UID Required, Must be the UID of the EVENT-REQUEST associate with the reply. To-do Component Properties To-do component is excluded from this message type. 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. Silverberg/Mansour/Dawson/Hopson 23 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Non-Standard Properties Excluded-token Not Required. But recipient may choose to ignore those non- standard properties, specified as Not Required. 3.2.4 EVENT-CANCEL This message type is used to send a cancellation notice of an existing event request to the attendees. The message is sent by the event OWNER or ORGANIZER to the recipients of the current event request. The OWNER and ORGANIZER are ROLE parameter values for the ATTENDEE property. EVENT-CANCEL Calendar Properties GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"EVENT-CANCEL" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties ATTACH Excluded ATTENDEE Excluded Silverberg/Mansour/Dawson/Hopson 24 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 CATEGORIES Excluded CLASS Excluded CREATED Excluded COMMENT Not Required, Text value. Provides Required comment from the organizer to the attendees concerning the cancellation notice. 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 Silverberg/Mansour/Dawson/Hopson 25 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 RELATED-TO Excluded REQUEST-STATUS Excluded RDATE Excluded RRULE Excluded RESOURCES Excluded RESPONSE-SEQUENCE Excluded SEQUENCE Excluded 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. To-do Component Properties To-do component is excluded from this message type. Journal Component Properties Journal component is excluded from this message type. Alarm Properties Silverberg/Mansour/Dawson/Hopson 26 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Alarm component is excluded from this message type. Freebusy Protperties Freebusy component is excluded from this message type. Non-standard Properties Excluded-token Not Required, But recipient may choose to ignore those non- standard properties, specified as optional. 3.2.5 EVENT-REQUEST for Replacing an Event When an organizer wishes to change an existing event in terms of time, location, description they may replace an existing meeting by sending a new request with the same UID and an appropriate response-sequence number (the number should be non-zero. The receiving client should correlate the request to an existing appointment and then check the sequence number to realize this request is actually a replacement for the existing meeting. Individual "A" sends a meeting request to "B" and "C". "B" accepts the meeting and "C" declines and includes text in the comments property proposing a more appropriate time. "A" sends "B" and "C" another meeting request using the same UID and a sequence number of 3 (e.g., the third revision of the original event). "B" should infer that the event request message is actually a replacement for the existing meeting. Replacing an event request is predicated on using the same UID, incrementing the sequence number and replacing the salient calendar properties. EVENT-REQUEST (replacing an existing meeting) Calendar Properties GEO Not Required PRODID Required Silverberg/Mansour/Dawson/Hopson 27 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 VERSION Value must be "2.0". PROFILE Required,"EVENT-REQUEST" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties COMMENT Not Required CREATED Not Required DAYLIGHT Not Required DTSTAMP 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 ATTACH Not Required, "VALUE=URL" only. Silverberg/Mansour/Dawson/Hopson 28 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 CREATED Not Required COMPLETED Excluded DESCRIPTION Required, Value may be NULL text. DUE Excluded DURATION Excluded DTEND Not Required, Must be a date/time after DTSTART. May span date boundary. DTSTAMP Required DTSTART Required EXDATE Not Required, See issues list. EXRULE Not Required, See issues list. LAST-MODIFIED Not Required LOCATION Not Required Silverberg/Mansour/Dawson/Hopson 29 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PRIORITY Not Required RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required, See issues list. RRULE Not Required, See issues list. RESOURCES Not Required RESPONSE-SEQUENCE Excluded SEQUENCE Required, if not zero STATUS Not Required, Value only one of TENTATIVE | CONFIRMED. This property is used by the organizer to indicate the consensus for the meeting, 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 Alarm Component Properties ATTACH Not Required Silverberg/Mansour/Dawson/Hopson 30 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 CATEGORIES Required, If an alarm is specified 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 Non-standard Properties Excluded-token Not Required, but recipient may choose to ignore those non- standard properties, specified as Not Required. 3.2.6 EVENT-COUNTER In the course of scheduling events an attendee may wish to modify event properties such as time, place, included documents etc. ITIP allows for a structured negotiation between attendee and organizer through the use of 2 messages: EVENT-COUNTER and EVENT-DECLINECOUNTER. The attendee uses an Event-Counter, essentially an Event-Request with the proposed modifications, to propose changes to the organizer. The organizer Silverberg/Mansour/Dawson/Hopson 31 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 accepts or rejects some or all of the proposed modifications by either sending a new Event-Request with an incremented sequence number and the same UID to all attendees or replying to the attendee with an EVENT- COUNTERDECLINE. The latter simply informs the attendee that their counter proposal was rejected. The EVENT-COUNTER message must include a complete description of the event. EVENT-COUNTER Calendar Properties GEO Not Required PRODID Required VERSION A, Value must be "2.0". PROFILE Required,"EVENT-COUNTER" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties CREATED Not Required DAYLIGHT Not Required DTSAMP 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 UID Not Required Event Component Properties Silverberg/Mansour/Dawson/Hopson 32 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 ATTACH Not Required, VALUE=URL only. ATTENDEE Required, Value is an RFC822 mailbox address for C&S capability. A TYPE=ROOM parameter value pair supported. Property can be used to propose other attendees. CATEGORIES Not Required CLASS Not Required COMMENT Not Required, Text value. Provides a comment from the recipient to the originator about the counter proposal. For example, "How about my place instead of yours". CREATED Required COMPLETED Excluded DESCRIPTION A, Value may be NULL text. DUE Excluded DURATION Excluded DTEND Required, Value is of the ISO 8601 complete representation, basic format of a UTC based date and time; unless specifying a loosely coupled date and time. DTSTAMP Required DTSTART Not Required, Value iNot Required of the INot RequiredO 8601 complete repreNot Requiredentation, baNot Requiredic format of a UTC baNot Requireded date and time; unleNot RequiredNot Required Not Requiredpecifying a looNot Requiredely coupled date and time. EXDATE Not Required, See issues list. Silverberg/Mansour/Dawson/Hopson 33 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 EXRULE Not Required, See issues list. LAST-MODIFIED Excluded LOCATION Not Required RNUM Excluded PRIORITY Excluded RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required, See issues list. RRULE Not Required, See issues list. RESOURCES Not Required RESPONSE-SEQUENCE Required, If not zero SEQUENCE Required, If not zero STATUS Excluded SUMMARY Not Required, May be NULL text. TRANSP Excluded URL Not Required UID Required, Must be the value of the UID of the EVENT-REQUEST associated with the counter proposal. To-do Component Properties To-do component is excluded from this message type. Journal Component Properties Journal component is excluded from this message type. Alarm Properties Alarm component is excluded from this message type. Silverberg/Mansour/Dawson/Hopson 34 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 optional. 3.2.7 EVENT-DECLINECOUNTER This message type is used by the organizer of an event request to decline a counter proposal. It is sent only to the issuer of the Event- Counter and requires no further action. Acceptance of a counter proposal message is accomplished when the ORGANIZER of the original event request sends an EVENT-REQUEST with the updated event description including the original UID and an incremented SEQUENCE NUMBER. EVENT-DECLINECOUNTER Calendar Properties GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"EVENT-DECLINECOUNTER" PROFILE-VERSION Required, Value must be "1.0". Timezone Properties Timezone component is excluded from this message type. Event Component Properties ATTACH Excluded Silverberg/Mansour/Dawson/Hopson 35 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 ATTENDEE Not Required, Value is an RFC822 mailbox address for C&S capability. Address corresponds to the originator (i.e., ATTENDEE value) of the counter proposal message. CATEGORIES Excluded CLASS Excluded COMMENT Not Required, Text value. Provides a comment from the originator to the recipient about the decline of the counter proposal. For example, "We are unable to change the meeting time or place". CREATED Excluded COMPLETED Excluded DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Excluded EXDATE Excluded EXRULE Excluded LAST-MODIFIED Excluded LOCATION Not Required PRIORITY Excluded RELATED-TO Not Required REQUEST-STATUS Not Required RDATE Excluded RRULE Excluded Silverberg/Mansour/Dawson/Hopson 36 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 RESOURCES Excluded RESPONSE-SEQUENCE Required SEQUENCE Required, Must be the same as that specified in the EVENT- COUNTER. STATUS Excluded SUMMARY Excluded TRANSP Excluded URL Excluded UID Required, Must be the value of the UID of the original EVENT- REQUEST referenced in the counter proposal. To-do Component Properties To-do component is excluded from this message type. 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 optional. Silverberg/Mansour/Dawson/Hopson 37 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 3.2.8 EVENT-REQUEST for Delegation EVENT-REQUEST messages may be delegated to another individual. The message is sent by one of the attendees of an existing event request to some other individual. The message type MAY only be sent by one of the attendees of an existing event request. The properties from the original event request MUST be included in the calendar component to assure that the delegated attendee has a complete specification of the delegated event. This MAY include a description that reflects numerous revisions of the original request. The message must also contain a new ATTENDEE property corresponding to the individual being delegated to. An EVENT-REPLY message is also sent from the Attendee delegating the request to the organizer of the event request; indicating that the original request is being delegated. The EVENT-REQUEST message must assign the values of the RSVP and EXPECT property parameters associated with the recipient delegating the request to the ATTENDEE property of the delegate. EVENT-REQUEST (delegation) Calendar Properties GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"EVENT-REQUEST" PROFILE-VERSION Required, Value must be "1.0". Timezone Component Properties COMMENT Not Required CREATED Not Required DAYLIGHT Not Required Silverberg/Mansour/Dawson/Hopson 38 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 UID Not Required Event Component Properties ATTACH Not Required, VALUE=URL only. Silverberg/Mansour/Dawson/Hopson 39 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 ATTENDEE Required, Value is an RFC822 mailbox address. Required new ATTENDEE property MUST be included; corresponding to the delegated individual. This property should include the DELEGATED-FROM property parameter. The ATTENDEE property must also have the same RSVP and EXPECT property parameter values as the recipient delegating the request. The STATUS parameter for this individual is either absent or has Required value of "NEEDS ACTION". The ATTENDEE property associated with the recipient delegating the request should include the DELEGATED-TO property parameter. CATEGORIES Not Required CLASS Not Required CREATED Not Required COMMENT Not Required, Text value. Provides Required comment from the organizer of the delegate message to the delegated attendee concerning the delegated event. COMPLETED Excluded DESCRIPTION Required, Value may be NULL text. DUE Excluded DURATION Excluded DTEND Not Required. Silverberg/Mansour/Dawson/Hopson 40 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 DTSTAMP Required DTSTART Required EXDATE Not Required, See issues list. EXRULE Not Required, See issues list. LAST-MODIFIED Not Required LOCATION Not Required PRIORITY Excluded RELATED-TO Not Required REQUEST-STATUS Excluded RDATE Not Required, See issues list. RRULE Not Required, See issues list. RESOURCES Not Required RESPONSE-SEQUENCE Excluded. SEQUENCE Required if not zero STATUS Not Required, Value only one of TENTATIVE | CONFIRMED. This property is used to convey the consensus for the meeting. I wonder if this should be set to delegated SUMMARY Not Required, May be Null text. Silverberg/Mansour/Dawson/Hopson 41 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 TRANSP Excluded URL Not Required UID Required, Must be the UID of the original EVENT-REQUEST. To-do Component Properties To-do component is excluded from this message type. 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 DURATION Required, If an alarm is specified LAST-MODIFIED Not Required RELATED-TO Not Required Silverberg/Mansour/Dawson/Hopson 42 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 Excluded-token Not Required, but recipient may choose to ignore those non- standard properties, specified as optional. The following is the EVENT-REPLY to the organizer from the delegator notifying the organizer that this attendee has delegated the item to another. EVENT-REPLY (From Delegator to Organizer) Calendar Properties GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"EVENT-REPLY" PROFILE-VERSION Required, Value must be "1.0". Silverberg/Mansour/Dawson/Hopson 43 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties ATTACH Excluded ATTENDEE Required, Value is an RFC822 mailbox address. Required capability. Must be the address of the recipient replying. CATEGORIES Excluded CLASS Excluded COMMENT Text value. Provides Required comment from the recipient to the originator about the reply. For example, "I can't travel this far for Required meeting." CREATED Excluded COMPLETED Excluded DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Required Silverberg/Mansour/Dawson/Hopson 44 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 DTSTART Excluded EXDATE Not Required, See issues list. Specifies the dates that are exceptions to the status update. EXRULE Not Required, See issues list. Specifies the rule that defines the exceptions to the status update. LAST-MODIFIED Excluded LOCATION Excluded PRIORITY Excluded RELATED-TO Excluded REQUEST-STATUS 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. Seems like this should be delegated Silverberg/Mansour/Dawson/Hopson 45 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 SUMMARY Excluded TRANSP Excluded URL Excluded UID Required, Must be the UID of the EVENT-REQUEST associate with the reply. To-do Component Properties To-do component is excluded from this message type. 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 Excluded-token Not Required, But recipient may choose to ignore those non- standard properties, specified as Not Required. 3.2.9 BUSY-REQUEST This design document only addresses the transfer of busy time information. Applications desiring free time information must infer this Silverberg/Mansour/Dawson/Hopson 46 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 from available busy time information. The Freebusy Calendar Component MUST only be used in order to provide busy time information. The Freebusy Calendar Component MAY only appear in the BUSY-REQUEST and BUSY-REPLY message types or in a network resource containing busy time data. The busy time periods within the iCalendar Object MAY be grouped into more than one Freebusy Calendar Component. This capability allows busy time periods to be grouped according to some common periodicity, such as a calendar week, month, or year. In this case, each FREEBUSY component needs to include the ATTENDEE, DTSTART and DTEND properties to define the free busy information in order that in might be unambiguous when stored separately. An iCalendar Object conforming to document MUST restrict the use of the FREEBUSY property for representing busy time information. The FREEBUSY property value MAY include a list of values, separated by the COMMA character (ASCII decimal 44). Alternately, multiple busy time periods MAY be specified with multiple instances of the FREEBUSY property. Both forms MUST be supported by implementations conforming to this document. Duplicate busy time periods SHOULD not be specified in an iCalendar Object. However, two different busy time periods may overlap. FREEBUSY properties SHOULD be sorted such that their values are in ascending order, based on the start time, and then the end time, with the earliest periods first. For example, today's busy time information SHOULD appear after yesterday's busy time information. And the busy time for this half hour SHOULD appear after the busy time for earlier today. Since events MAY span a day boundary, free busy time period MAY also span a day boundary. Individual "A" requests busy time from individuals "B", "C" and "D". Individual "B" and "C" replies with busy time data to individual "A". Individual "D" does not support busy time requests and does not reply with any data. If the transport binding supports exception messages, then a "unsupported capability" message is returned by individual "D" to individual "A". The following table illustrates the sequence of messages that would be exchanged between these individuals. This message only permits requests for busy time information. The message is sent from an organizer of a busy time request to one or more intended recipients (i.e., ROLE=ATTENDEE). BUSY-REQUEST Calendar Properties GEO Not Required Silverberg/Mansour/Dawson/Hopson 47 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"BUSY-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 TZTRANS Not Required UID Not Required Event Component Properties Silverberg/Mansour/Dawson/Hopson 48 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Event component is excluded from this message type. To-do Component Properties To-do component is excluded from this message type. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties Alarm component is excluded from this message type. FreeBusy Component Properties ATTENDEE Required, Value is an RFC822 mailbox address. Not Required capability. An instance must be specified for the organizer and the intended attendees of the request. COMMENT Excluded CREATED Excluded DURATION Excluded DTEND Required, This is the end of the busy time period being requested. DTSTART Required, This is the start of the busy time period being requested. FREEBUSY Excluded Silverberg/Mansour/Dawson/Hopson 49 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 LAST-MODIFIED Excluded RELATED-TO Excluded REQUEST-STATUS Excluded RESPONSE-SEQUENCE Excluded SEQUENCE Excluded UID Required, Must be referenced by the recipients in their FREEBUSY- REPLY message. URL Excluded Non-standard Properties Excluded-token Not Required, but recipient may choose to ignore those non- standard properties, specified as optional. 3.2.10 BUSY-REPLY The message is used to reply to an existing busy time request. The message is sent from a recipient of a busy time request back to the request ORGANIZER. If an ORGANIZER is not specified on the busy time request, then the message is sent to the OWNER. Busy time intervals are represented by individual instances of the FREEBUSY property. There is one occurrence of the property for each busy time interval. Duplicate busy time periods should not be returned. However, two different busy time periods may overlap. The FREEBUSY property value MAY include a list of values, separated by the COMA character (ASCII decimal 44). FREEBUSY properties SHOULD be sorted such that their values are in ascending order, from the most recent to past. For example, today's busy time information SHOULD appear after yesterday's busy time information. Silverberg/Mansour/Dawson/Hopson 50 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 And the busy time for this half hour SHOULD appear after the busy time for earlier today. Since events MAY span a day boundary, free busy time period MAY also span a day boundary. The busy time periods may be grouped into more than one FREEBUSY component. This capability allows busy time periods to be grouped according to some common periodicity, such as a calendar week, month, or year. In this case, each FREEBUSY component needs to include the ATTENDEE, DTSTART and DTEND properties. The ATTENDEE property must be specified in the busy time reply. The value is the fully qualified RFC 822 address of the recipient replying to the busy time request. BUSY-REPLY Calendar Properties GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"BUSY-REPLY" 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 Silverberg/Mansour/Dawson/Hopson 51 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 Not Required Event Component Properties Event component is excluded from this message type. To-do Component Properties To-do component is excluded from this message type. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties Alarm component is excluded from this message type. Freebusy Component Properties Silverberg/Mansour/Dawson/Hopson 52 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 ATTENDEE Required, Value is an RFC822 mailbox address. Required capability. Must be the address of the recipient replying. COMMENT Not Required, Text value. Provides Required comment from the organizer of the reply to the attendees concerning the busy time reply notice. CREATED Not Required DURATION Excluded DTEND Not Required, Value is the ISO 8601 complete representation, basic format of Required UTC based date and time. Represents the end of the busy time period defined by the FREEBUSY properties in the Freebusy component. DTSTART Not Required, Value is the ISO 8601 complete representation, basic format of Required UTC based date and time. Represents the start of the busy time period defined by the FREEBUSY properties in the Freebusy component. FREEBUSY Required, Values in the property must all be of the same property parameter type. Multiple instances of the property are permitted. Multiple instances of the property must be sorted in ascending order. Values between property instances may overlap. LAST-MODIFIED Not Required Silverberg/Mansour/Dawson/Hopson 53 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 RELATED-TO Not Required, Refers to Required related Freebusy component. REQUEST-STATUS Required, One of the values from the table below. Multiple instances of the property may be specified. RESPONSE-SEQUENCE Excluded SEQUENCE Excluded UID Required, Must be the UID of the BUSY-REQUEST associated with the reply. URL Not Required, Specifies the URL for the data containing iCalendar Object with busy time information. Non-standard Properties Excluded-token Not Required, Recipient may choose to ignore those non- standard properties, specified as optional. 3.2.11 EVENT-RESEND This message type is used by attendees to request the latest version of an EVENT-REQUEST. By issuing an EVENT-RESEND with the appropriate UID and optionally a RECURRENCE-ID, the organizer's CUA should respond with the latest version of the Event. This message type is intended to be machine processed. EVENT-RESEND Calendar Properties Silverberg/Mansour/Dawson/Hopson 54 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 GEO Not Required PRODID Required VERSION Required, Value must be "2.0". PROFILE Required,"EVENT-RESEND" PROFILE-VERSION Required, Value must be "1.0". Timezone Properties Timezone component is excluded from this message type. Event Component Properties ATTACH Excluded ATTENDEE Required CATEGORIES Excluded CLASS Excluded COMMENT Not Required, Text value. Provides a comment from the originator to the recipient about the decline of the counter proposal. For example, "We are unable to change the meeting time or place". CREATED Excluded COMPLETED Excluded DESCRIPTION Excluded DUE Excluded DURATION Excluded DTEND Excluded DTSTAMP Required DTSTART Excluded EXDATE Excluded EXRULE Excluded Silverberg/Mansour/Dawson/Hopson 55 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 LAST-MODIFIED Excluded LOCATION Excluded PRIORITY Excluded RELATED-TO Excluded REQUEST-STATUS Excluded RECURRENCE-ID Not Required, if the attendee wishes to receive an updated instance of a recurring event then the RECURRENCE-ID can be included and only the specific instance will be returned. RDATE Excluded RRULE Excluded 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, The Event associated with the UID represents the Event that will be returned To-do Component Properties To-do component is excluded from this message type. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties Silverberg/Mansour/Dawson/Hopson 56 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Alarm component is excluded from this message type. Freebusy Properties Freebusy component is excluded from this message type. Non-standard Properties X-token Excluded 3.3 Status Replies The REQUEST-STATUS property may include the following values: Short Longer Return Status Offending Data Return Description Status Code 200 Success. None. 201 Success, but fallback taken Property name and value on one or more property may be specified. values. 202 Success, invalid property Property name may be ignored. specified. 203 Success, invalid property Property parameter name parameter ignored. and value may be specified. 204 Success, unknown non- Non-standard property standard property ignored. name may be specified. 205 Success, unknown non- Property and non- standard property value standard value may be ignored. specified. Silverberg/Mansour/Dawson/Hopson 57 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 206 Success, invalid calendar Calendar component component ignored. sentinel (e.g., "BEGIN:ALARM") may be specified. 207 Success, request forwarded Original and forwarded to calendar user. RFC822 addresses may be specified. 208 Success, repeating event RRULE or RDATE property ignored. Scheduled as a name and value may be single event. specified. 209 Success, truncated end DTEND property value may date/time to date boundary. be specified. 210 Success, repeating to-do RRULE or RDATE property ignored. Scheduled as a name and value may be single to-do. specified. 300 Invalid property name. Property name may be specified. 301 Invalid property value. Property name and value may be specified. 302 Invalid property parameter. Property parameter name and value may be specified. 303 Invalid property parameter Property parameter name value. and value may be specified. 304 Invalid calendar component Calendar component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 305 Invalid date or time. Date/time value(s) may be specified. Silverberg/Mansour/Dawson/Hopson 58 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 large. None. 400 Event conflict. Date/time DTSTART and DTEND is busy. property name and values may be specified. 500 Request not supported. Profile property value may be specified. 501 Service unavailable. ATTENDEE property value may be specified. 502 Invalid calendar service. ATTENDEE property value may be specified. 503 No scheduling support for ATTENDEE property value user. may be specified. 3.4 Implementation Considerations 3.4.1 Working With Recurrence Instances ICalendar includes a recurrence grammar to represent recurring events. The benefit of such a grammar is the ability to represent a number of Silverberg/Mansour/Dawson/Hopson 59 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 events in a single object. However, while this simplifies creation of a recurring event, meeting instances may still need to be referenced. For instance, an attendee may decline the third instance of a recurring Friday event. Similarly, the Organizer may change the time or location to a single instance of the recurring event. Since implementations may elect to store recurring events as either a single event object or a collection of discreet, related event objects, the protocol is designed so that each recurring instance can be both referenced and versioned. Hence, implementations that choose to maintain per-instance properties (such as attendee status) may do so. However, the protocol does not require per-instance recognition unless the instance itself must be renegotiated. The scenarios for recurrence instance referencing are listed below. For purposes of simplification a change to an event refers to a "trigger property." That is, a property that has a substantive affect on the meeting itself such as start time, location, due date (for to-do components) and possibly description. Organizer initiated actions: . Organizer deletes or changes a single instance of a recurring event . Organizer makes changes that affect all future instances . Organizer makes changes that affect all previous instances . Organizer deletes or modifies a previously changed instance Attendee initiated actions: . Attendee changes status for a particular recurrence instance . Attendee sends Event-Counter for a particular recurrence instance An instance of a recurring event is assigned a unique identification, RECURRENCE-ID, when that instance must be renegotiated. Negotiation is necessary when the start time, end time, due date or location are modified. If the Organizer wishes to identify a specific recurrence instance it is done using the RECURRENCE-ID property. The property value is equal to the date/time of the instance. If the Organizer wishes to change the DTSTART, the original DTSTART value is used for RECURRENCE-ID and the new DTSTART and DTEND values reflect the change. If the Organizer wishes to add a new instance to the recurring event then an Event-Request is issued with an RDATE equal to the new instance date. It is recommended that the Organizer include the RECURRENCE-ID. Since the creation of a new event instance requires negotiation, the sequence number is also incremented. 3.4.2 When To Resend An Event The following table is used to determine when the change to a component or property should cause the event to be resent to all attendees. The Resend Event key is: . Resend _ The event must be resent . Resend Not Required _ An application may resend the event if it wants, but it is not required Silverberg/Mansour/Dawson/Hopson 60 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 . Do Not Resend _ An application must not resend the event . Excluded _ this property should not appear in the event. EVENT-REQUEST (when to resend) Calendar Properties GEO Resend Not Required PRODID Do Not Resend VERSION Do Not Resend PROFILE Do Not Resend PROFILE-VERSION Do Not Resend Timezone Component Properties COMMENT Do Not Resend CREATED Resend Not Required DAYLIGHT Resend DTSTART Resend DTEND Resend RDATE Resend RRULE Resend TZNAME Resend Not Required TZOFFSET Resend TZTRANS Resend UID Resend Not Required Event Component Properties ATTACH Resend ATTENDEE Resend CATEGORIES Resend Not Required CLASS Resend Not Required Silverberg/Mansour/Dawson/Hopson 61 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 CREATED Do Not Resend COMMENT Excluded COMPLETED Do Not Resend DESCRIPTION Resend DUE Excluded DURATION Excluded DTEND Resend DTSTART Resend EXDATE Resend EXRULE Resend LAST-MODIFIED Do Not Resend LOCATION Resend PRIORITY Excluded RELATED-TO Resend REQUEST-STATUS Excluded RDATE Resend RRULE Resend RESOURCES Resend RESPONSE-SEQUENCE Excluded SEQUENCE Resend if not zero STATUS Resend SUMMARY Resend TRANSP Excluded URL Resend UID Does not change once set To-do Component Properties Silverberg/Mansour/Dawson/Hopson 62 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 To-do component is excluded from this message type. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties ATTACH Resend CATEGORIES Resend CREATED Do Not Resend DESCRIPTION Resend DTSTART Resend DURATION Resend LAST-MODIFIED Do Not Resend RELATED-TO Resend REPEAT Resend SUMMARY Resend URL Resend Freebusy Component Properties Freebusy component is excluded from this message type. Non-standard Properties Excluded-token Resend Not Required, but recipient may choose to ignore those non-standard properties, specified as optional. Silverberg/Mansour/Dawson/Hopson 63 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 3.4.3 Timezones If a recurring event has any instance where DTStart and DTEnd fall on different sides of a timezone shift, the Timezone components are required. The threat of duplicate timezone definitions exists. Should an iCalendar Object contain multiple conflicting timezone components, the one with the latest DTSTART property supersedes the others. 3.4.4 Alarms Alarms are a contentious component. It is recommended that application software ask the user whether or not they want alarms included when they read the event. 3.4.5 SUMMARY Property The minimum support for the SUMMARY property in a recipient MUST be for a 255 byte value. Implementations MAY truncate longer length values. 3.4.6 X-Tokens To make iCalendar Objects extensible, new property types can be inserted into components. These properties are called X-Tokens as they are prefixed with "X-". A client is not required to make sense of X-Tokens. Clients are not required to save X-Tokens or use them in event replies. Silverberg/Mansour/Dawson/Hopson 64 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 4 Examples 4.1 Published Event Examples In the calendaring and scheduling context, publication refers to the one way transfer of event information. Consumers of published events simply incorporate the event into a calendar. No reply is expected. Individual "A" publishes an event. Individual "B" reads the event and incorporates it into their calendar. Events can be published in several ways including: embedding the event as an object in a web page, e-mailing the event to a distribution list, and posting the event to a newsgroup. The table below illustrates the sequence of events between the publisher and the consumers of a published event. Action Organizer Attendee Publish an event "A" sends or posts an EVENT-PUBLISH message "B" reads the event publication Publish an updated "A" sends or posts an event EVENT-PUBLISH message "B" reads the updated event publication Cancel a published "A" sends or posts an event EVENT-CANCEL message "B" reads the canceled event publication Silverberg/Mansour/Dawson/Hopson 65 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 4.1.1 A Minimal Published Event The iCalendar Object below describes a single event that begins on July 1, 1997 at 20:00 UTC. This event contains the minimum set of properties for an iTIP event component. BEGIN:VCALENDAR PROFILE:EVENT-PUBLISH PROFILE-VERSION:1.0 PRODID:-//ACME/DesktopCalendar//EN VERSION:2.0 BEGIN:VEVENT DTSTART:19970701T200000Z DTSTAMP:19970611T190000Z SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:0981234-1234234-23 END:VEVENT END:VCALENDAR 4.1.2 Changing A Published Event The iCalendar Object below describes an update to the event described in 4.1.1, the time has been changed, an end time has been added, and the sequence number has been adjusted. BEGIN:VCALENDAR PROFILE:EVENT-PUBLISH PROFILE-VERSION:1.0 VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VEVENT DTSTAMP:19970612T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z SEQUENCE:2 UID:0981234-1234234-23 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES END:VEVENT END:VCALENDAR The UID is used by the client to identify the event. The SEQUENCE property indicates that this is the second change to the event. Events with sequence numbers 0 and 1 are superseded by this event. The SEQUENCE property provides a reliable way to distinguish different versions of the same event. Each time an event is published, its sequence number is incremented. If a client receives an event with a sequence number 5 and finds it has the same event with sequence number 2, the event should be updated. However, if the client received an event with sequence number 2 and finds it already has sequence number 5 of the same event, the event should not be updated. Silverberg/Mansour/Dawson/Hopson 66 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 4.1.3 Canceling A Published Event The iCalendar Object below cancels the event described in 4.1.1. This cancels the event with SEQUENCE numbers 0, 1, and 2. BEGIN:VCALENDAR PROFILE:EVENT-CANCEL PROFILE-VERSION:1.0 VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VEVENT COMMENT:DUKES forfeit the game SEQUENCE:2 UID:0981234-1234234-23 DTSTAMP:19970613T190000Z STATUS:CANCELLED END:VEVENT END:VCALENDAR 4.1.4 A Rich Published Event This example describes the same event 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:EVENT-PUBLISH PROFILE-VERSION:1.0 CALSCALE:GREGORIAN SOURCE:http://www.midwaystadium.com/stadium-cal/1997-events.or4 NAME:1997 GAME SCHEDULE VERSION:2.0 BEGIN:VEVENT ATTACH:http://www.stadium.com/bigame.gif CATEGORIES:SPORTS EVENT;ENTERTAINMENT CLASS:PRIVATE Silverberg/Mansour/Dawson/Hopson 67 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 CREATED:19970415T194319Z DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:MIDWAY= STADIUM=0A=0D= Big time game. Must see.= Expected duration:2 hours DTEND:19970701T180000 DTSTART:19970702T160000 DTSTAMP:19970614T190000Z STATUS:CONFIRMED LAST-MODIFIED:19970416T162421Z LOCATION;VALUE=URL:http://www.midwaystadium.com/ PRIORITY:2 RESOURCES:SCOREBOARD SEQUENCE:3 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:0981234-1234234-23 RELATED-TO:0981234-1234234-14 BEGIN:VALARM DTSTART:19970701T190000Z REPEAT:2 DURATION:PT2H CATEGORIES:DISPLAY,AUDIO DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:It's almost game time END:VALARM BEGIN:VALARM DTSTART:19970701T153000 CATEGORIES:DISPLAY,AUDIO DESCRIPTION:You should leave now. Game starts in 30 min! END:VALARM END:VEVENT END:VCALENDAR The CLASS property is specified, though it is not really needed here. Since this is a published event, a program that displays it need not apply any content filtering based on the CLASS attribute. If this event is copied into a user's calendar, the CLASS would be included as 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 event. The handling of this property is application dependent. VTIMEZONE components are discussed in detail in [ICAL]. The sequence number 3 indicates that this event supersedes versions 0, 1, and 2. 4.2 Group Event Examples Group events are distinguished from published events in that they have attendees and that there is interaction between the attendees with respect to the event. Individual "A" requests a meeting between Silverberg/Mansour/Dawson/Hopson 68 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 individuals "A", "B", "C" and "D". Individual "B" confirms attendance to the meeting. Individual "C" declines attendance. Individual "D" tentatively confirms their attendance. This is sometimes referred to as "penciling-in" the event on a calendar. 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 meeting REQUEST message to "A" sends EVENT- request "B", "C", and "D" Accept the "B" sends EVENT-REPLY meeting message to "A" with request it's ATTENDEE/STATUS property parameter set to "ACCEPTED" Decline the "C" sends EVENT-REPLY meeting message to "A" with request it's ATTENDEE/STATUS property parameter set to "DECLINED" Tentatively "D" sends EVENT-REPLY accept the message to "A" with meeting it's ATTENEE/STATUS request property parameter set to "TENTATIVE" Confirm "A" sends EVENT- meeting status REQUEST message to with attendees "B" and "C" with current information for event. SEQUENCE property is "1". 4.2.1 A Group Event Request A sample meeting request that "A" sends to "B", "C", and "D". Silverberg/Mansour/Dawson/Hopson 69 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT 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 ATTENDEE;RSVP=NO;EXPECT=REQUIRE;TYPE=ROOM:The Big Conference Room DTSTAMP:19970611T190000Z DTSTART:19970701T100000-0700 DTEND:19970701T103000-0700 SUMMARY:Phone Conference UID:www.acme.com-873970198738777 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR Note that the conference room does not have a valid e-mail address. 4.2.2 Reply To A Group Event Request Attendee "B" accepts the meeting. BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;STATUS=ACCEPTED:B@acme.com UID:www.acme.com-873970198738777 SEQUENCE:0 RESPONSE-SEQUENCE:0 REQUEST-STATUS:200;Success DTSTAMP:19970612T190000Z END:VEVENT 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 An Event The event 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 Silverberg/Mansour/Dawson/Hopson 70 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PROFILE:EVENT-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT 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 ATTENDEE;RSVP=NO;EXPECT=REQUIRE;TYPE=ROOM:The Big Conference Room DTSTART:19970701T110000-0700 DTEND:19970701T113000-0700 SUMMARY:Phone Conference UID:www.acme.com-873970198738777 SEQUENCE:1 DTSTAMP:19970613T190000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.2.4 Countering an Event Proposal Attendee A sends EVENT-REQUEST to B and C. B makes a counter proposal to A to change the time and location. Attendee A sends EVENT-REQUEST: BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT 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 DTSTART:19970701T190000Z DTEND:19970701T200000Z SUMMARY:Discuss the Merits of the election results LOCATION:The Big Conference Room UID:www.acme.com-873970198738777 SEQUENCE:0 DTSTAMP:19970611T190000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR Attendee B sends EVENT-COUNTER to A requesting changes to time and place: BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-COUNTER PROFILE-VERSION:1.0 VERSION:2.0 Silverberg/Mansour/Dawson/Hopson 71 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 BEGIN:VEVENT 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 DTSTART:19970701T160000Z DTEND:19970701T190000Z DTSTAMP:19970612T190000Z SUMMARY:Discuss the Merits of the election results LOCATION:The Small Conference Room COMMENT:This time works much better and I think the big conference room is too big UID:www.acme.com-873970198738777 SEQUENCE:0 DTSTAMP:19970611T190000Z END:VEVENT END:VCALENDAR Attendee A accepts the changes from B BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT 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 DTSTAMP:19970613T190000Z DTSTART:19970701T160000Z DTEND:19970701T190000Z SUMMARY:Discuss the Merits of the election results - changed to suite B's schedule LOCATION:The Small Conference Room UID:www.acme.com-873970198738777 SEQUENCE:1 STATUS:CONFIRMED END:VEVENT END:VCALENDAR A rejects B's counter proposal BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-COUNTERDECLINE PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com COMMENT:Sorry, I cannot change this meeting time UID:www.acme.com-873970198738777 SEQUENCE:1 DTSTAMP:19970614T190000Z Silverberg/Mansour/Dawson/Hopson 72 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 END:VEVENT 4.2.5 Delegate An Event When delegating an event request to another calendar user, the delegator must both update the organizer with an Event-Reply and send an EVENT- REQUEST to the delegatee. There is currently no protocol limitation to delegation depth. That is, it is possible for the original delegate to delegate the meeting to someone else, and so on. When an Event-Request is delegated from one CUA to another there are a number of responsibilities required of the delegator. They must: . Send an Event-Reply to the organizer with their attendee/status property parameter set to "Delegated" . Include the delegate as an additional attendee with the "Delegated-From" property parameter set to the delegator . Set the response sequence equal to 0 . Include the original UID of the Event-Request The delegator must also send a copy of the original Event-Request to the delegate. The delegator modifies the request to include: . The ATTENDEE/STATUS property parameter for the delegator (sender in this case) is set to "DELEGATED" . ATTENDEE/DELEGATED-TO parameter is set to the address of the delegatee . An ATTENDEE property is added for delegatee As a rule, it is not required that the delegatee include the delegator in their Event-Reply. However, it is strongly advised since this will inform the delegator whether their proxy plans to attend the meeting. If the delegatee declines the meeting, the delegator may elect to try and delegate the Event-Request to another CUA. The process is the same. Action Organizer Attendee Initiate "A" sends EVENT- a REQUEST message meeting to "B" and "C" request Silverberg/Mansour/Dawson/Hopson 73 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Delegate "C" sends EVENT-REPLY message the to "A" with it's meeting ATTENDEE/STATUS property request. parameter set to "DELEGATED" "C" and an ATTENDEE property has delegate been added to the reply for "E" s the with a DELEGATED-FROM property meeting parameter set to address of to "E" "C". DELEGATED-TO property parameter for "B" set to address of "E". "C" sends EVENT-REQUEST message to "E" with the original meeting request information. The ATTENDEE/STATUS property parameter for "C" has been set to "DELEGATED" and the ATTENDEE/DELEGATED-TO parameter has been set to the address of "E". An ATTENDEE property has been added for "E" and the ATTENDEE/DELEGATED-FROM parameter has been set to the address of "C". Confirm "E" sends EVENT-REPLY message meeting to "A" and optionally "C", with attendan it's ATTENDEE/STATUS property ce parameter set to "ACCEPTED" Optional "A" sends EVENT- REQUEST message Redistri to "B" and "E" bute with current meeting information for details event. SEQUENCE and property is "1" status to attendee s Attendee "C" responds to meeting organizer "A" BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN Silverberg/Mansour/Dawson/Hopson 74 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PROFILE:EVENT-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED- TO=E@acme.com:C@acme.com UID:www.acme.com-873970198738777 SEQUENCE:0 RESPONSE-SEQUENCE:0 REQUEST-STATUS:200;Success DTSTAMP:19970611T190000Z END:VEVENT END:VCALENDAR Attendee "C" delegates presence at the meeting to "E". BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REQUEST PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;ROLE=Organizer;STATUS=ACCEPTED:A@acme.com ATTENDEE;ROLE=DELEGATE;RSVP=YES;EXPECT=REQUEST;DELEGATED- FROM=C@acme.com:E@acme.com ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED- TO=E@acme.com:C@acme.com DTSTART:19970701T110000-0700 DTEND:19970701T113000-0700 SUMMARY:Phone Conference UID:www.acme.com-873970198738777 SEQUENCE:0 STATUS:CONFIRMED DTSTAMP:19970611T190000Z END:VEVENT END:VCALENDAR 4.2.6 Delegate Accepts the Meeting To accept a delegated meeting, the delegate sends the following message to "A" and "C" BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;DELEGATED- FROM=C@acme.com:E@acme.com UID:www.acme.com-873970198738777 SEQUENCE:1 RESPONSE-SEQUENCE:0 Silverberg/Mansour/Dawson/Hopson 75 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 REQUEST-STATUS:200;Success DTSTAMP:19970614T190000Z END:VEVENT END:VCALENDAR 4.2.7 Delegate Declines the Meeting In this example the delegate declines the meeting request and sets the attendee status to declined. The organizer should resend the EVENT- REQUEST to "C" with the status of the delegate set to declined. This lets the delegator know that the delegate has declined and provides an opportunity to the delegator to either accept or delegate the request. Response from "E" to "A" and "C" BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;ROLE=ATTENDEE;STATUS=DECLINED;DELEGATED- FROM=C@acme.com:E@acme.com UID:www.acme.com-873970198738777 SEQUENCE:1 RESPONSE-SEQUENCE:0 REQUEST-STATUS:200;Success DTSTAMP:19970614T190000Z END:VEVENT END:VCALENDAR "A" resends the EVENT-REQUEST to "C". "A" may also wish to express the fact that the item was delegated in the COMMENT field BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT ATTENDEE;ROLE=ATTENDEE;STATUS=DECLINED;DELEGATED- FROM=C@acme.com:E@acme.com ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com UID:www.acme.com-873970198738777 SEQUENCE:2 REQUEST-STATUS:200;Success DTSTAMP:19970614T200000Z COMMENT:DELEGATE (ATTENDEE E@acme.com) DECLINED YOUR INVITATION END:VEVENT END:VCALENDAR Silverberg/Mansour/Dawson/Hopson 76 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 4.2.8 Cancel A Group Event Individual "A" requests a meeting between individuals "A", "B" and "C". Individual "B" declines attendance to the meeting. Individual "A" decides to cancel the meeting. The following table illustrates the sequence of messages that would be exchanged between these individuals. Messages related to a previously canceled event (SEQUENCE number is less than the SEQUENCE number of the EVENT-CANCEL message) or to-do must be ignored. Action Organizer Attendee Initiate a "A" sends EVENT- meeting request REQUEST message to "B" and "C" Decline the "B" sends EVENT- meeting request REPLY message to "A" with it's ATTENDEE/STATUS property parameter set to "DECLINED". "C" may or may not reply to the EVENT- REQUEST message. Cancel the "A" sends EVENT- meeting CANCEL message to "B" and "C" to cancel the meeting. SEQUENCE parameter is "1". The example shows how "A" cancels the event. BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-CANCEL PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT COMMENT:Mr. B cannot attend. I'll reschedule the meeting later. UID:www.acme.com-873970198738777 Silverberg/Mansour/Dawson/Hopson 77 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 SEQUENCE:0 DTSTAMP:19970613T190000Z STATUS:CANCELLED END:VEVENT END:VCALENDAR The organizer of a meeting can "uninvite" or remove attendees by sending an EVENT-CANCEL to only those attendees. 4.3 Busy Time Examples Individual "A" requests busy time from individuals "B", "C" and "D". Individual "B" and "C" replies with busy time data to individual "A". Individual "D" does not support busy time requests and does not reply with any data. The following table illustrates the sequence of messages that would be exchanged between these individuals. Action Organizer Attendee Initiate a busy time "A" sends BUSY- request REQUEST message to "B", "C" and "D" Reply to the busy time "B" and "C" sends request with busy time BUSY-REPLY data message to "A" with their busy time data. 4.3.1 Request Busy Time "A" sends a BUSY-REQUEST to "B", "C", and "D" for busy time BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:BUSY-REQUEST VERSION:2.0 PROFILE-VERSION:1.0 BEGIN:FREEBUSY ATTENDEE;ROLE=OWNER:A@acme.com ATTENDEE:B@acme.com ATTENDEE:C@acme.com ATTENDEE:D@acme.com Silverberg/Mansour/Dawson/Hopson 78 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 DTSTAMP:19970613T190000Z DTSTART:19970701T080000-0700 DTEND:19970701T200000-0700 UID:www.acme.com-873970198738777 END:VEVENT END:VCALENDAR 4.3.2 Reply To A Busy Time Request "B" sends a BUSY-REPLY to "A" BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN PROFILE:BUSY-REPLY VERSION:2.0 PROFILE-VERSION:1.0 BEGIN:FREEBUSY ATTENDEE:B@acme.com DTSTART:19970701T080000-0700 DTEND:19970701T200000-0700 UID:www.acme.com-873970198738777 FREEBUSY:19970701T090000-0700/PT1H,19970701T140000-0700/PT30H DTSTAMP:19970613T190030Z END:VEVENT END:VCALENDAR B is busy from 09:00 to 10:00 and from 14:00 to 14:30. 4.4 Recurring Event and Time Zone Examples 4.4.1 A Recurring Event Spanning Timezones This event describes a weekly phone conference. 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 BEGIN:VTIMEZONE DAYLIGHT:FALSE DTSTART:19970126T000000 RRULE;BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY TZNAME:PST TZOFFSET:-0800 TTRANS:020000 END:VTIMEZONE Silverberg/Mansour/Dawson/Hopson 79 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 PRODID:-//ACME/DesktopCalendar//EN PROFILE:EVENT-REQUEST VERSION:2.0 BEGIN:VEVENT 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 DTSTAMP:19970613T190030Z DTSTART:19970701T140000 DTEND:19970701T150000 RRULE:INTERVAL=20;WKST=SU;BYDAY=TU;FREQ=WEEKLY RDATE:19970910T140000 EXDATE:19970909T140000 EXDATE:19971028T150000 SUMMARY:Weekly Phone Conference UID:www.acme.com-873970198738777 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR Timezone components should appear in an iCalendar Object containing recurring events. This is especially important if a recurring event 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 meeting 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 repeating event 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 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 event 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: Silverberg/Mansour/Dawson/Hopson 80 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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.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. Note the use of RECURRENCE-ID and SEQUENCE-NUMBER in the second request. Original Request: BEGIN:VCALENDAR PROFILE:EVENT-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT CREATED:19970526T083000 UID:guid-1.host1.com SEQUENCE:0 RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z LOCATION:Conference Call DTSTAMP:19970526T083000 STATUS:CONFIRMED END:VEVENT END:VCALENDAR The event request below is to change a time and create an exception. This creates an exception on July 3rd. BEGIN:VCALENDAR PROFILE:EVENT-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT CREATED:19970526T083000 UID:guid-1.host1.com Silverberg/Mansour/Dawson/Hopson 81 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 RECURRENCE-ID:19970701T210000Z SEQUENCE:1 RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970703T210000Z DTEND:19970703T220000Z LOCATION:Conference Call DTSTAMP:19970626T093000 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4.3 Cancel A Recurring Instance In this example the Organizer of a recurring event wishes to delete an instance. This is referred to as an "exception" to the recurring event. BEGIN:VCALENDAR PROFILE:EVENT-CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1.host1.com RECURRENCE-ID:19970801T210000Z SEQUENCE:2 DTSTAMP:19970721T093000 STATUS:CANCELLED END:VEVENT END:VCALENDAR 4.4.4 Cancel An Exception In the following example, the organizer has created an exception and now wishes to cancel it. In this case an EVENT-CANCEL is sent with the specific RECURRENCE-ID, UID, and SEQUENCE of the exception. This same sequence can be used to decline a previously accepted modification to a recurring event. BEGIN:VCALENDAR PROFILE:EVENT-CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1.host1.com RECURRENCE-ID:19970801T210000Z SEQUENCE:2 DTSTAMP:19970721T103000 STATUS:CANCELLED Silverberg/Mansour/Dawson/Hopson 82 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 END:VEVENT END:VCALENDAR 4.4.5 Cancel Recurring Event In this example the organizer wishes to cancel the entire recurring event and any child exceptions. BEGIN:VCALENDAR PROFILE:EVENT-CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1.host1.com DTSTAMP:19970721T103000 SEQUENCE:2 STATUS:CANCELLED END:VEVENT END:VCALENDAR 4.4.6 Change All Future Instances This example changes the meeting location from a conference call to Seattle starting Sept 1 and extends to all future instances. BEGIN:VCALENDAR PROFILE:EVENT-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT CREATED:19970526T083000 UID:guid-1.host1.com RECURRENCE-ID;THISANDFUTURE:19970901T210000Z SEQUENCE:3 RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970901T210000Z DTEND:19970901T220000Z LOCATION:Building 32, Microsoft, Seattle, WA DTSTAMP:19970526T083000 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4.7 Add A New Instance To A Recurring Event This example adds a one-time additional Event instance to the recurring Event. Organizer adds a second July meeting on the 15th. Silverberg/Mansour/Dawson/Hopson 83 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 BEGIN:VCALENDAR PROFILE:EVENT-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT CREATED:19970526T083000 UID:guid-1.host1.com RECURRENCE-ID:19970715T210000Z SEQUENCE:4 RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z RDATE:19970715T210000Z/19970715T220000Z ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T210000Z DTEND:19970715T220000Z LOCATION:Conference Call DTSTAMP:19970629T093000 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 of the proposed second July meeting. BEGIN:VCALENDAR PROFILE:EVENT-COUNTER PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT CREATED:19970526T083000 UID:guid-1.host1.com RECURRENCE-ID:19970715T210000Z SEQUENCE:4 RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T220000Z DTEND:19970715T230000Z LOCATION:Conference Call COMMENT:Can we bump this by an hour? I have a conflict DTSTAMP:19970629T094000 Silverberg/Mansour/Dawson/Hopson 84 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 END:VEVENT END:VCALENDAR 4.4.9 Error Reply To An EVENT-REQUEST The following example illustrates a scenario where a meeting is proposed that contains a property that is not supported (in this case, RRULE). Original Request: BEGIN:VCALENDAR PROFILE:EVENT-REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT CREATED:19970526T083000 UID:guid-1.host1.com SEQUENCE:0 RRULE:BYMONTHDAY=1;FREQ=MONTHLY ATTENDEE;EXPECT=REQUEST:Sman@netscape.com ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z DTSTAMP:19970602T094000 LOCATION:Conference Call STATUS:CONFIRMED END:VEVENT END:VCALENDAR Response to indicate that RRULE is not supported: BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN PROFILE:EVENT-REPLY PROFILE-VERSION:1.0 VERSION:2.0 BEGIN:VEVENT REQUEST-STATUS:208;Repeating event ignored. Scheduled as a single event;RRULE UID:guid-1.host1.com SEQUENCE:0 RESPONSE-SEQUENCE:0 DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR Silverberg/Mansour/Dawson/Hopson 85 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 Profiles Profile Fallback EVENT-PUBLISH Required. EVENT-CANCEL Required. EVENT-REQUEST EVENT-PUBLISH EVENT-REPLY Required. EVENT-DELEGATE Reply with Not Supported. FREEBUSY-REQUEST Reply with Not Supported. FREEBUSY-REPLY Reply with Not Supported. EVENT-COUNTER Reply with Not Supported EVENT- Required if EVENT-COUNTER is implemented; COUNTERDECLINE otherwise reply with Not Supported. 5.2 Calendar Components Component Fallback Silverberg/Mansour/Dawson/Hopson 86 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 VFREEBUSY Reply with Not Supported. VALARM Reply with Not Supported. 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-VERSION Ignore. SOURCE Ignore NAME Ignore. VERSION Ignore. 5.4 Component Properties Silverberg/Mansour/Dawson/Hopson 87 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Property Fallback ATTACH Ignore. ATTENDEE Required if EVENT-REQUEST is not implemented; otherwise reply with Not Supported. CATEGORIES Required if in VALARM and VALARM is implemented, otherwise ignore. CLASS Ignore. COMMENT Ignore. COMPLETED Ignore. CREATED Ignore. DAYLIGHT Required if VTIMEZONE is implemented; otherwise Ignore. DESCRIPTION Required. DELEGATED-FROM Required if EVENT-DELEGATE is implemented; otherwise Ignore. DELEGATED-TO Required if EVENT-DELEGATE is implemented; otherwise Ignore. DUE Ignore. DURATION Reply with Not Supported. DTSTART Required. Silverberg/Mansour/Dawson/Hopson 88 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 DTEND Required. EXDATE Ignore. EXRULE Ignore. FREEBUSY Reply with Not Supported. LAST-MODIFIED Ignore. LOCATION Required. PRIORITY Ignore. RELATED-TO Ignore. RDATE Ignore. If implemented, VTIMEZONE must also be implemented. RRULE Ignore. The first instance occurs on the DTStart property. RECURRENCE-ID Required if RRULE is implemented; otherwise Ignore. REQUEST-STATUS Required. RESOURCES Ignore. SEQUENCE Required. STATUS Ignore. SUMMARY Ignore. Silverberg/Mansour/Dawson/Hopson 89 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 TRANSP Required if FREEBUSY is implemented; otherwise Ignore. TZNAME Required if VTIMEZONE is implemented; otherwise Ignore. TZOFFSET Required if VTIMEZONE is implemented; otherwise Ignore. 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 events to arrive out of sequence. That is, you may receive an EVENT-CANCEL notification prior to receiving the original event. This section discusses a few of these scenarios. 5.5.1 Cancelation of an Unknown Event. When an EVENT-CANCEL request is received before the original EVENT- REQUEST the calendar will be unable to correlate the UID of the cancellation with an existing event. 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.5.2 Unexpected Reply from an Unknown Delegate When an attendee delegates an item to another calendar user they must send an EVENT-REPLY to the organizer using the attendee properties to indicate the fact that the request was delegated and to whom the item was delegated. Hence it is possible for an organizer to receive an EVENT-REPLY from a calendar user 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 Silverberg/Mansour/Dawson/Hopson 90 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 hold it until the Event-Response is received from the delegator. If the version of the EVENT-REPLY is out of date the Organizer should treat the message as a STATUS-REQUEST and update the delegate with the correct version. 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 . LOCATION . DUE (for To-Do components) Silverberg/Mansour/Dawson/Hopson 91 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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. 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. Silverberg/Mansour/Dawson/Hopson 92 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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. Silverberg/Mansour/Dawson/Hopson 93 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 8 Bibliography [ICAL] "Internet Calendaring and Scheduling Core Object Specification - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- drafts/draft-ietf-calsch-ical-00.txt. [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-00.txt [ID-DT] "Date and Time on the Internet", Internet-Draft, December 1996, http://www.imc.org/draft-newman-datetime. [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. [ITIP-2] "iCalendar Transport-Independent Interoperability Protocol (iTIP) _ Part Two: Scheduling To-Dos", Internet-Draft, July 1997, http://www.imc.org/ietf-calsch-itip-part2-00.txt. [ITIP-3] "iCalendar Transport-Independent Interoperability Protocol (iTIP) - Part Three: Scheduling Journal Entries", Internet-Draft, July 1997, http://www.imc.org/ietf-calsch-itip-part3-00.txt. [VCARD] "vCard - The Electronic Business Card Exchange Format - Version 2.1", Versit Consortium, September 18, 1996, http://www.imc.org/pdi/vcard-21.doc. [RFC821] Postel, "Simple Mail Transfer Protocol", RFC 821, organization name, November 1996, http://www.imc.org/rfc2045. [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. [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. [UNICODE] The Unicode Consortium, "The Unicode Standard -Version 2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described in section A-2. [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. Silverberg/Mansour/Dawson/Hopson 94 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 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. Silverberg/Mansour/Dawson/Hopson 95 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 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 Appendix A. Transport Protocol Considerations Calendar and scheduling functions are accomplished entirely through iCalendar objects described in Section 2.1, Application Protocol. The responsibility of exchanging the iCalendar objects belongs to the transport. Binding documents for a real-time transport (iRIP) and a store-and-forward transport (iMIP) are planned by the calsched working group. Other transports bindings are possible as well. This section discusses some of the issues that must be addressed in an iTIP binding document. The relevant model elements include: . the User, the person sending the iCalendar Object, . the Sender, the device used to contact a receiving device, send commands, and receive replies, and . the Receiver, the device that accepts commands and sends replies. These elements are depicted below. The Sender and receiver can take on varying roles of CUA and CS as described in [ICMS]. +----------+ +----------+ +----+ | | | | |User|<->| Sender | iTIP | Receiver | +----+ | | Commands/Replies | | | |<====================>| | | | | | +--------+ | | | |<->|Calendar| +----------+ +----------+ +--------+ The transport protocol must include methods for categorizing the authenticity of the User, the Sender, and Receiver. The transport protocol must also includes method for categorizing the connection type. Note that secure connection technology such as Secure Socket Layer (SSL) authenticates the Sender and Receiver and provides secure communication between them, but does not authenticate the user initiating the transfer. Also, note that the digital certificate of a user does not authenticate the Sender nor does it mean that data transmitted between the Sender and Receiver is private. The basic steps which a Transport binding must addressed are listed below. Silverberg/Mansour/Dawson/Hopson 96 Expires January 1998 Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997 Transport Description IRIP notes IMIP notes Operational Phases CONNECT Establish May include No op communicati authentication on with the of the sender Receiver and receiver AUTHENTICAT Establish May be May include E the anonymous, the user's authenticit clear text digital y of the login and certificate user. password, or SASL [SASL] RECIPIENT Identify Identifies the Identifies the the Users whose message recipients calendar's recipients of the should receive iCalendar the iCalendar object objects ICALDATA Send an Sends an Sends an iCalendar iCalendar iCalendar Object to object object the Receiver DISCONNECT Terminate Disconnect No op the connection A valid binding document must: . Describe how it will handle each operational phase. . Provide errors returns for attempts to use unsupported options. Silverberg/Mansour/Dawson/Hopson 97 Expires January 1998