Network Working Group Frank Dawson, Lotus Internet Draft May 1, 1997 Expires November 1997 iCalendar Message-based Interoperability Protocol (iMIP) 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 document defines an iCalendar Message-based Interoperability Protocol (iMIP), intended to be used to convey calendaring and scheduling semantics between different applications. This document is also being offered as a specification for demonstrating industry- wide, calendaring and scheduling interoperability. The message-based protocol defined by this document is useful not only in traditional electronic messaging (e-mail) transports, but also is applicable for conveying calendaring and scheduling information across any reliable transport; including memory-based clipboards, drag/drop protocols, wireless pagers, and the Infra-red Data Association (IrDA) object transfer protocol. 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). This design document is heavily based on the prior work of the Versit Consortium's Personal Data Interchange (PDI) project team; including the vCard v2.1 and the vCalendar v1.0 specifications. More information about the PDI project and these documents can be found on the Internet Mail Consortium (IMC) website at http://www.imc.org/pdi. Dawson 1 Expires November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 In addition, this design document makes use of the work within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC website at http://www.imc.org, the IETF website at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Distribution of this document is unlimited. Comments and suggestions for improvement should be sent as MIME email to the author. Table of Contents 1. Intended Use........................................................3 1.1 Desktop Interoperablity ..........................................4 2. Message Based Architecture..........................................5 3. iCalendar Support...................................................6 3.1 Differences From iCalendar .......................................6 3.1.1 Character Set .................................................7 3.1.2 ATTENDEE Property .............................................7 3.1.3 DESCRIPTION Property ..........................................7 3.1.4 SUMMARY Property ..............................................8 3.1.5 PRODID Property ...............................................8 3.1.6 VERSION Property ..............................................8 3.1.7 PROFILE Property ..............................................8 3.1.8 PROFILE-VERSION Property ......................................9 3.1.9 UID Property ..................................................9 3.1.10 RELATED-TO Property ..........................................9 3.1.11 URL Property .................................................9 3.1.12 REQUEST-STATUS Property .....................................10 3.1.12.1 COMMENT Property ........................................13 3.2 Free and Busy Time ..............................................13 3.2.1 Freebusy Calendar Component ..................................14 3.2.2 FREEBUSY Property ............................................14 4. Supported Capability...............................................14 4.1 Request and reply to an event ...................................15 4.2 Cancel an event .................................................16 4.3 Request and reply to a to-do ....................................17 4.4 Negotiate an alternate event definition .........................18 4.5 Delegate an event to another individual .........................20 4.6 Request and reply for busy time .................................21 5. Message Profile Specifications.....................................22 6. Message Types......................................................24 6.1 EVENT-REQUEST ...................................................24 6.2 EVENT-REPLY .....................................................27 6.3 EVENT-CANCEL ....................................................32 6.4 EVENT-REPLACE ...................................................35 6.5 EVENT-COUNTER ...................................................38 6.6 EVENT-DECLINECOUNTER ............................................41 6.7 EVENT-DELEGATE ..................................................46 6.8 TODO-REQUEST ....................................................50 Dawson 2 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 6.9 TODO-REPLY ......................................................54 6.10 TODO-CANCEL ....................................................58 6.11 JOURNAL-REQUEST ................................................61 6.12 JOURNAL-REPLY ..................................................63 6.13 BUSY-REQUEST ...................................................66 6.14 BUSY-REPLY .....................................................69 7. MIME Message Format Binding........................................74 7.1 MIME Media Type .................................................74 7.2 Security ........................................................74 7.3 RFC 822 Addresses ...............................................74 7.4 Content Type ....................................................75 7.5 Content-Transfer-Encoding .......................................75 7.6 Content-Description .............................................76 7.7 To ..............................................................76 7.8 From ............................................................76 7.9 Cc and Bc .......................................................76 7.10 Reply-To .......................................................76 7.11 Subject ........................................................76 8. Alternate Plain-text Messages......................................76 8.1 EVENT-REQUEST, RSVP=YES .........................................77 8.2 EVENT-REQUEST, RSVP=NO ..........................................77 8.3 EVENT-REQUEST, EXPECT=REQUIRED ..................................78 8.4 EVENT-CANCEL ....................................................79 8.5 EVENT-REPLACE, RSVP=YES .........................................79 8.6 EVENT-DECLINECOUNTER ............................................80 8.7 EVENT-DELEGATE, RSVP=YES ........................................81 8.8 TODO-REQUEST, RSVP=YES ..........................................82 8.9 TODO-REQUEST, RSVP=NO ...........................................82 8.10 TODO-CANCEL ....................................................83 8.11 JOURNAL-REQUEST, RSVP=YES ......................................84 8.12 JOURNAL-REQUEST, RSVP=NO .......................................84 9. IrDA Binding.......................................................85 10. TCP LAN Protocol Binding..........................................85 11. SPX LAN Protocol Binding..........................................85 12. Desktop Interaction Requirements..................................85 12.1 Clipboard ......................................................85 12.2 Drag/Drop ......................................................85 12.3 File System ....................................................86 12.4 IrDa Communications ............................................86 13. Conformance.......................................................86 14. References........................................................86 15. Acknowledgements..................................................87 16. Author's Address..................................................87 17. Issues............................................................88 18. Resolutions.......................................................88 1. Intended Use This document defines a set of message types that provide a full set of inter-personal scheduling semantics. These capabilities include the following: Dawson 3 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 . Request that an event or to-do be scheduled on one or more recipients calendars; . Reply to an existing event or to-do request to confirm, decline, tentative, or delegate the request; . Allow a recipient of an event request to forward it to one or more delegated recipients; . Allow the originator of an event to cancels the event; . Allow the originator of an event to replace the original event definition, as when an event is rescheduled or the attendee information is updated; . Allow a recipient of an event request to send the originator a counter-proposal; . Allow the originator of an event request to decline a counter proposal from an attendee; . Request busy time data from one or more recipients; . Reply to a busy time request with busy time data; . Support Internet protocol access to C&S capability; . Support LAN protocol access to C&S capability; . Allow specification of a recurring event description with a recurrence grammar, a sequence of events, or a combination of the two. Recurrence grammar will allow Yearly-by-day-position, Monthly-by-days-of-week, Monthly-by-day-position, Weekly-by-days- of-week, Weekly-by-position, Daily-by-time; . Support scheduling a meeting between individuals in different time zones; . Support for time zones; . Support for DST rules; and . Attachment of files to an event or to-do request. In addition, the following real-time functions are supported: . Request a busy time URL from an LDAP server; and . Retrieve busy time from a busy time URL. 1.1 Desktop Interoperablity This document was not explicitly intended to address application interoperability at the desktop. However, in order to maximize the Dawson 4 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 largest possible interoperability between applications, the following recommendations are provided. Applications supporting this document SHOULD provide support for: . Drag/source of calendar data, rendered as an iCalendar Object, using both clipboard and file based drag/drop protocols; . Drop/target of an iCalendar Object using both clipboard and file based drag/drop protocol; . Clipboard/Copy of a calendar data rendered as an iCalendar Object; . Clipboard/Paste of a iCalendar Object from the clipboard; . File/Open of an iCalendar Object from the file system; . File/SaveAs of calendar data as an iCalendar Object to the file system;. . Ability to invoke the product with an iCalendar Object as an argument list item. . Send calendar data, rendered as an iCalendar Object, over the Win95/NT infra-red port; and . Receive an iCalendar Object from the infra-read port. 2. Message Based Architecture The calendaring and scheduling capability defined by this document is based on the exchange of messages between an organizer of an event or to-do and the attendees of the group event or to-do. For the most part, the message protocol emulates a "request" and "reply" form of communications. The message format is designed to be used with a MIME electronic messaging transport, but is equally applicable to other non-Internet message transports. The messages that define this inter-personal scheduling protocol consist of an iCalendar Object defined by [ICAL]. Depending on the transport used to convey the protocol, additional message header properties may be used to further encapsulate the iCalendar Object. For example, within a MIME [RFC2045] transport the [ICAL] object will be encapsulated within a [RFC 822] message entity. Other transports may not further encapsulate the iCalendar Object. This message-based protocol is based "request" messages that are send from an originator to one or more recipients. A recipient of a "request" message may "reply" to the request, in order to update their status as an attendee and may also return transaction/request status information. In the case of event requests, the recipient may alternatively respond to the request with a counter proposal. The Dawson 5 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 protocol also supports the ability for the originator of an event or to-do request to cancel the original request. The originator of a request may also replace the definition for the original request. When the updated request changes the date, time or location of the request, this effectively re-schedules the original request. The originator of a request is by default the OWNER of the request. Alternately, the originator may be the ORGANIZER of the request; acting on behalf of the OWNER. The recipients of the request are by default the ATTENDEES of the request. A recipient may delegate the request to one of more individuals; in which case they would be a DELEGATE of the request. The OWNER, ORGANIZER, ATTENDEE and DELEGATE are role definitions that an attendee may be assigned by the OWNER of the request. The message-based protocol defined by this specification involves an ORGANIZER/OWNER centric flow. Both the requests, cancellation, replacement, acceptance of counter proposals can be originated only from the ORGANIZER or OWNER of the request. 3. iCalendar Support The messages used by this protocol are formatted according to the IETF iCalendar specification [ICAL]. This document was selected as the basis for the message types because it is the focus on an ongoing effort to define an Internet calendaring and scheduling standard. This document enhances the base [ICAL] specification with a minimum of additional features. These include the following changes: . iCalendar default character is UTF-8; . Additional property parameter values for several properties; . Extension to the URL property to allow reference to a busy time data store; . Constraints on some property values; . Definition of a number of non-standard properties. The non- standard properties where defined instead of new properties in order to allow use of the currently available parser/generator code base. 3.1 Differences From iCalendar The basic capabilities defined by the [ICAL] document have utilized to define a primarily "request" and "reply" based scheduling protocol. In defining the protocol, some differences from the [ICAL] specification have been introduced. The following sections describe individual differences between the [ICAL] specification and this design document. In addition, any constraints on the iCalendar specification are defined. Dawson 6 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 3.1.1 Character Set The default character set for iCalendar Objects conforming to this specification is UTF-8. UTF-8 is the designation for a 8-bit form of UNICODE that preserves the encoding of US-ASCII data, but also provides for the inclusion of non-ASCII characters from the extended Latin alphabet or any other character block supported by [UNICODE]. This limitation will not impact existing applications that emit iCalendar objects, but will facilitate applications that conform to this design document to address current internationalization/national language requirements. 3.1.2 ATTENDEE Property The property parameters for this property have been extended to include newly defined property parameters DELEGATED-TO, to indicate the RFC 822 address of the individual that this attendee delegated the request to, and DELEGATED-FROM to indicate the RFC 822 address of the individual that this attendee received a delegated request from. NOTE: These property parameters should be included in the current [ICAL] document. The DELEGATED-TO property parameter value is an (RFC 822) address that represents the individual (e.g., "delegatee") that this request has been deletated to. The DELEGATED-FROM property parameter value is an (RFC 822) address that represents the individual (e.g., "delegator") from whom this request was delegated. A recipient delegated as request MUST inherit the RSVP and EXPECT values from the attendee that delegated the request to them. The following is an example of this property with "delegatee" and "delegator" information for an event: ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM= iamboss@host2.com:Henry Cabot ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO= hcabot@host2.com=iamboss(The Big Cheese)@host2.com ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe The EXPECT property parameter value of IMMEDIATE MUST not be used. This semantic is provided by the RSVP property parameter value of YES. 3.1.3 DESCRIPTION Property The minimum support for the DESCRIPTION property in a recipient MUST be for a 4095 byte value. Implementations MAY truncate longer length values. Dawson 7 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 3.1.4 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.1.5 PRODID Property This property identifies the product that generated the iCalendar object. This property MUST be included in an iCalendar object that conforms to this design document. The value for Lotus products should be based on an ISO 9070 formal public identifier text. The value for Lotus products should be of the form: prodid-value = ownerid ownerprefix textid ownerd = "-//" ;This specifies an unregistered owner identifier ownerprefix = compname "/" prodname textid = "//NONSGML" space version "//EN" ;This specifies the NONSGML data entity, type of public text ;class. The "EN" text tail specifies the natural language in ;which the public text was written. compname = 1*WORD ;This is a unique text corresponding to the company name prodname = 1*WORD ;This is a unique text corresponding to the product family name ;e.g., "Organizer" or "ccMail" version = ;e.g., "97 GS 19970314", "R5.0 19971216", "R8 19970214" ;These examples need to be replaced with formally selected text For example, the Lotus Organizer97 GS support for the iCalendar object might be specified by the following: -//Lotus/Organizer//NONSGML Organizer97 GS//EN 3.1.6 VERSION Property The VERSION property identifies the particular version of the iCalendar specification that the iCalendar object conforms to. The [ICAL] specification uses the "2.0" text for its unique identifier. This same value MUST be specified in iCalendar Objects conforming to this document. 3.1.7 PROFILE Property This property MUST be specified on any iCalendar Objects that conform to this document. The property defines the usage profile or method Dawson 8 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 being conveyed by the iCalendar object. The value of this property MUST be one of the values defined by this document. When included in a MIME message entity, the value of this property MUST be the same as the Content-Type profile parameter value. 3.1.8 PROFILE-VERSION Property This property specifies the version of the profile that the messages in the iCalendar object correspond with. For iCalendar messages that conform to this design document, the value MUST be "0.9". 3.1.9 UID Property Each event and to-do calendar entity MUST be identified with a persistent, globally unique identifier. This identifier is created by the calendar system that generates an iCalendar Object. The identifier is represented as a text value. It is found in the UID property within the iCalendar calendar component descriptions for the event or to-do. Any message type that refers to the original EVENT- REQUEST or TODO-REQUEST MUST use this same identifier as the value of their UID property. For example, if individual "B" sends an EVENT- COUNTER message to individual "A" (i.e., the OWNER and/or ORIGINATOR of the EVENT-REQUEST), the EVENT-COUNTER message must include the UID value from the original event request message. This is the method for correlating scheduling messages with the referenced event or to-do. The UID value for an instance of a recurrence rule is formatted such that it consists of the UID of the initial event or to-do, followed by the "/" SLASH character, followed by the date and time that the recurrence instance starts. This agreement will allow recurrence instances to uniquely identified. 3.1.10 RELATED-TO Property The UID value is also used by the RELATED-TO property in order to represent relationships among events and to-dos. For example, the parent relationship of an event to a series of action items (i.e., to-dos) may be show by the RELATED-TO property within the to-do descriptions. The value of the RELATED-TO property would be the UID of the parent event. Linkages between a sequence of events can also be show by including RELATED-TO properties in each item in the event- sequence, referencing back to the parent event. Backward traversal of the sequence is completed when a referenced event or to-do is found without a RELATED-TO property. 3.1.11 URL Property The property definition of the URL property has been extended to include the property parameter TYPE. The value BUSY may be specified to indicate that the URL specifies the location of busy time data associated with the originator of the message. For example, an originator for an EVENT-REQUEST message may specify this property parameter/value pair to specify the URL where the ATTENDEE might Dawson 9 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 search for busy time in order to construct a counter proposal. By using the busy time data specified by this URL, a recipient might determine an alternate free time for a counter proposal or a rescheduling of an event. Multiple occurrences of the URL property may indicate different resource locations. Busy time pointed to by a busy time URL must be an iCalendar Object. Editor's Note: Should there be additional constraints on the format of a busy file URL? 3.1.12 REQUEST-STATUS Property This newly defined property is identified by the property name REQUEST-STATUS. This property is used to return status information related to the processing of an associated iCalendar Object. The property MUST only be used in an EVENT-REPLY, EVENT-DECLINECOUNTER, TODO-REPLY, JOURNAL-REPLY or BUSY-REPLY message. The data type for this property is TEXT. The value consists of a short return status, a longer return status description, and optionally the offending data. The components of the value are separated by the SEMICOLON character (ASCII decimal 59). NOTE: These property parameters should be included in the base [ICAL] document. The property is defined by the following notation: rstatus = "REQUEST-STATUS" ":" statcode ";" statdesc [";" extdata] statcode = 3*DIGIT ;Numeric return status code statdesc = *WORD ;Textual status description extdata = *WORD ;Textual exception data. For example, the offending property ;name and value or complete property line. The following are some examples of this property: REQUEST-STATUS:0;Success REQUEST-STATUS:101;Invalid property value;DTSTART\:96-Apr-01 ;Note escapement of the colon character in property value. REQUEST-STATUS:201;Invalid Property Value;RRULE REQUEST-STATUS:301;Event conflict. Date/time is busy. REQUEST-STATUS:403;Invalid calendar user;ATTENDEE: jsmith@host.com Dawson 10 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 The following are valid values for the short return status and the longer return status description: Short Return Longer Return Status Description Status Value 0 Success 1XX Syntax value errors 2XX Semantic and value errors 3XX Scheduling errors 4XX Security related errors The following is a list of possible exception values: Short Return Longer Return Status Offending Data Status Description 0 Success. None. 10 Success, but fallback taken on one or more may be specified. Property name and value property values. 11 Success, invalid Property name may be property ignored. specified. 12 Success, invalid Property parameter name property parameter and value may be ignored. specified. 13 Success, unknown non- Non-standard property standard property name may be specified. ignored. 14 Success, unknown non- Property and non- standard property value standard value may be ignored. specified. 15 Success, invalid Calendar component calendar component sentinel (e.g., ignored. "BEGIN:ALARM") may be specified. Dawson 11 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 16 Success, request Original and forwarded forwarded to calendar RFC822 addresses may be user. specified. 17 Success, repeating event RRULE or RDATE property ignored. Scheduled as a name and value may be single event. specified. 18 Success, truncated end DTEND property value may date/time to date be specified. boundary. 19 Success, repeating to-do RRULE or RDATE property ignored. Scheduled as a name and value may be single to-do. specified. 100 Invalid property name. Property name may be specified. 101 Invalid property value. Property name and value may be specified. 102 Invalid property Property parameter name parameter. and value may be specified. 103 Invalid property Property parameter name parameter value. and value may be specified. 104 Invalid calendar Calendar component component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 201 Invalid date or time. Date/time value(s) may be specified. 202 Invalid rule. Rule value may be specified. 203 Request not supported. Profile property value may be specified. 204 Invalid calendar user. Attendee property value may be specified. 301 Event conflict. DTSTART and DTEND Date/time is busy. property name and values may be specified. 302 Request not supported. PROFILE property value Dawson 12 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 may be specified. 401 Service unavailable. ATTENDEE property value may be specified. 402 Invalid calendar ATTENDEE property value service. may be specified. 403 Invalid calendar user. ATTENDEE property value may be specified. 404 No scheduling support ATTENDEE property value for user. may be specified. 405 No authority. PROFILE and ATTENDEE property values may be specified. 3.1.12.1 COMMENT Property This newly defined property is identified by the property name COMMENT. The property is used to pass a comment text within the calendar component. The property may use the ENCODING property parameter to reset the default encoding to QUOTED-PRINTABLE in order to include formatting characters within the comment text. For example, the property can be used within an EVENT-REPLY to indicate to the OWNER of an event request why an ATTENDEE is declining an invitation. NOTE: These property parameters should be included in the base [ICAL] document. The minimum support MUST be for a 4095 byte value. Implementations MAY truncate longer length values. The following is an example of this property. COMMENT:The meeting really needs to include both ourselves and the customer. We can't hold this meeting without them. As a matter of fact, the venue for the meeting ought to be at their site. - - Frank 3.2 Free and Busy Time The [ICAL] specification provides support for representing free or busy time data. This document only supports the request and replies for busy-time information. Dawson 13 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 3.2.1 Freebusy Calendar Component This design document only addresses the transfer of busy time information. Applications desiring free time information must infer this 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. 3.2.2 FREEBUSY Property An iCalendar Object conforming to document MUST restrict the use of the BUSYTIME 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 BUSYTIME 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 before yesterday's busy time information. And the busy time for this half hour SHOULD appear before the busy time for earlier today. Since events MAY span a day boundary, free busy time period MAY also span a day boundary. 4. Supported Capability The message types defined by this usage profile provides for the scheduling functions that allow: . An originator to request that an event be scheduled between the originator and one or more recipients (EVENT-REQUEST); . A recipient of an event request to reply to the originator of the request (EVENT-REPLY); Dawson 14 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 . An originator of an existing event request to send a cancellation notice to the attendees (EVENT-CANCEL); . An originator of an existing event request to reschedule the event (EVENT-REPLACE); . An originator of an existing event request to send the attendees an updated event description and attendee statuses (also the EVENT-REPLACE); . A recipient of an event request to delegate the request to another recipient (EVENT-DELEGATE);A recipient of an event request to send a counter proposal to the originator of the request (EVENT-COUNTER); . An originator of an existing event request to decline a counter proposal from a recipient (EVENT-DECLINECOUNTER); . An originator to request an action item or to-do to be assigned to one or more recipients (TODO-REQUEST); . A recipient of a to-do request to reply to the originator of the request (TODO-REPLY); . An originator of an existing to-do request to send a cancellation notice to the attendees (TODO-CANCEL); . An originator to request that a journal entry be appended to one or more recipients (JOURNAL-REQUEST); . A recipient of a journal request to reply to the originator of the request (JOURNAL-REPLY); . Originator to request busy time from one or more recipients (BUSY-REQUEST); . A recipient of a busy time request to reply to the originator of the request with busy time intervals (BUSY-REPLY). The following scenarios describe how these scheduling functions are supported by this message protocol. 4.1 Request and reply to an event Individual "A" requests a meeting between 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 sometime 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. Dawson 15 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Action Originator Recipient Initiate a meeting "A" sends EVENT-REQUEST request message to "B" and "C" Accept the meeting "B" sends EVENT-REPLY request message to "A" with it's ATTENDEE/STATUS property parameter set to "ACCEPTED" Decline the meeting "C" sends EVENT-REPLY request message to "A" with it's ATTENDEE/STATUS property parameter set to "DECLINED" Tentatively accept the "D" sends EVENT-REPLY meeting request message to "A" with it's ATTENEE/STATUS property parameter set to "TENTATIVE" Confirm meeting status "A" sends EVENT-REPLACE with attendees message to "B" and "C" with current information for event. SEQUENCE property is "1". 4.2 Cancel an 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 or to-do must be ignored. Dawson 16 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Action Originator Recipient Initiate a meeting "A" sends EVENT-REQUEST request message to "B" and "C" Decline the meeting "B" sends EVENT-REPLY request 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 meeting "A" sends EVENT-CANCEL message to "B" and "C" to cancel the meeting. SEQUENCE parameter is "1". The cancelation of a to-do is achieved in a manner similar to this. 4.3 Request and reply to a to-do Individual "A" assigns a to-do to individual "B". Individual "B" accepts the to-do. Subsequently, individual "B" replies to individual "A" that the to-do is completed. The following table illustrates the sequence of messages that would be exchanged between these individuals. The request and reply of a journal entry operates similar to this also. Dawson 17 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Action Originator Recipient Assign a to-do "A" sends TODO-REQUEST message to "B". Accept the to-do "B" sends TODO-REPLY message to "A" with it's ATTENDEE/STATUS property parameter set to "ACCEPTED" Reply when to-do is "B" sends TODO-REPLY completed message to "A" with it's ATTENDEE/STATUS property parameter set to "COMPLETED". RESPONSE-SEQUENCE property is "1" A similar set of messages could have been exchanged to assign a to-do to a group of individuals. 4.4 Negotiate an alternate event definition Individual "A" requests a meeting between individuals "A", "B" and "C". Individual "B" confirms attendance to the meeting. Individual "C" sends individual "A" a counter proposal for the meeting. Individual "A" accepts the counter proposal. Individual "C" confirms attendance to the meeting. Individual "B" accepts the modified meeting request. Individual "A" distributes the revised meeting details and attendees status. The following table illustrates the sequence of messages that would be exchanged between these individuals. Action Originator Recipient Initiate a meeting "A" sends EVENT-REQUEST request message to "B" and "C" Accept the meeting "B" sends EVENT-REPLY request message to "A" with Dawson 18 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 it's ATTENDEE/STATUS property parameter set to "ACCEPTED" Counter proposal for "C" sends EVENT-COUNTER the meeting request message to "A" signaling a request to revise some detail about the request Accept the counter "A" sends EVENT-REPLACE proposal message to "B" and "C". SEQUENCE parameter is "1". The STATUS parameter on all ATTENDEE properties MUST be reset to "NEEDS ACTION". Confirm revised meeting "C" sends EVENT-REPLY request message to "A" with it's ATTENDEE/STATUS property parameter set to "ACCEPTED". RESPONSE-SEQUENCE parameter is "0" and SEQUENCE parameter is "1". "B" sends EVENT-REPLY message to "A" with it's ATTENDEE/STATUS property parameter set to "ACCEPTED". RESPONSE-SEQUENCE parameter is "0" and SEQUENCE parameter is "1". Confirm meeting details "A" sends a second and status to attendees EVENT-REPLACE message to "B" and "C" with current information for event. SEQUENCE property is "2". Dawson 19 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Individual "A" could have declined the counter proposal for the meeting request with the EVENT-DECLINE-COUNTER message. Individual "B" could have declined attendance at the meeting with the EVENT- REPLY message or delegated the original meeting request with a combination of the EVENT-REPLY to the originator and the EVENT- DELEGATE to the delegated individual (e.g., Individual "D", sometimes called "delegatee".). 4.5 Delegate an event to another individual Individual "A" requests a meeting between individuals "A" and "B". Individual "B" delegates attendance to the meeting to individual "C". Individual "C" confirms attendance to the meeting. Individual "A" distributes the revised meeting details and attendee status. The following table illustrates the sequence of messages that would be exchanged between these individuals. Action Originator Recipient Initiate a meeting "A" sends EVENT-REQUEST request message to "B" and "C" Delegate the meeting "B" sends EVENT-REPLY request message to "A" with it's ATTENDEE/STATUS property parameter set to "DELEGATED" and an ATTENDEE property has been added to the reply for "C" with a DELEGATED-FROM property parmater set to address of "B". DELEGATED-TO property parameter for B set to address of "C". "B" sends EVENT- DELEGATE message to "C" with the original meeting request information. The ATTENDEE/STATUS property parameter for "B" has been set to "DELEGATED" and the ATTENDEE/DELEGATED-TO parameter has been set Dawson 20 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 to the address of "C". An ATTENDEE property has been added for "C" and the ATTENDEE/DELEGATED-FROM parameter has been set to the address of "B". Confirm meeting "C" sends EVENT-REPLY attendance message to "A" and "B" with it's ATTENDEE/STATUS property parameter set to "ACCEPTED" Redistribute meeting "A" sends EVENT-REPLACE details and status to message to "B" and "C" attendees with current information for event. SEQUENCE property is "1" Individual "C" could have declined the delegated proposal for the meeting request with the EVENT-REPLY message being sent to both "A" and "B". 4.6 Request and reply for busy time 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. Action Originator Recipient Initiate a busy time "A" sends BUSY-REQUEST request message to "B", "C" and "D" Dawson 21 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Reply to the busy time "B" and "C" sends BUSY- request with busy time REPLY message to "A" data with their busy time data. (Assuming transport "D" sends an exception supports exchange of message (i.e., 302) to exception messages) "A" Reply that busy time requests is an unsupported capability. 5. Message Profile Specifications This section specifies the individual message formats defined by this design document. It is heavily based on the [ICAL] and [ID-CSP] documents. The message formats also borrow from the on-going discussions within the IETF Calendaring and Scheduling Working Group. Each individual message format is identified by the value of the PROFILE calendar property. If a [ICAL] defined property is not specified in an individual message format, then it is not allowed in the message type. Each message type provides support for a specific scheduling function. Taken as a whole, these message types provide support for a robust level of calendaring and scheduling functionality. These message types are summarized in the following table. Only the following message types are supported by this usage profile. Profile Parameter Description Value EVENT-REQUEST Make a request for an event EVENT-REPLY Reply to an event request EVENT-CANCEL Cancel an existing event request Dawson 22 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 EVENT-REPLACE Replace the current event request with a complete set of properties EVENT-DELEGATE Delegate an existing event request EVENT-COUNTER Make a counter proposal to the event request EVENT-DECLINECOUNTER Decline the counter proposal to the event request TODO-REQUEST Assign a to-do TODO-REPLY Reply to a to-do assignment TODO-CANCEL Cancel an existing to- do request. JOURNAL-REQUEST Request that a a journal entry gets appended to a calendar date. JOURNAL-REPLY Reply to a journal request. BUSY-REQUEST Request free or busy time data BUSY-REPLY Reply to a free/busy time request Dawson 23 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 6. Message Types This design document is meant to serve as the basis for implementing a message-based scheduling function within calendaring and scheduling products. In order to meet this goal, a common set of message-based scheduling semantics or functionality needs to be defined. The messages defined in this section provide such a set of semantics. The message definitions do not include a binding to the MIME email transport. This information is provided in a subsequent section of this document. In the following tables, the properties are classified as either ALWAYS (i.e., "A"), EXCLUDED (i.e., "X") or SOMETIMES (i.e., "S"). Additionally, the values for the properties may be constrained; as indicated in the descriptive text for that property. Properties classified as ALWAYS MUST appear within instances of the message type. Properties classified as EXCLUDED MUST NOT appear within instances of the message type. Properties classified as SOMETIMES MAY appear within instances of the message type. Implementations conforming to this document MUST be able to parse, and store for possible forwarding, all properties classified as ALWAYS and SOMETIMES.. 6.1 EVENT-REQUEST This message type is used to request a new event with a one or more people. The message is sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of an event request to one or more intended recipients (i.e., ROLE=ATTENDEE). The originator MUST be either the OWNER or ORGANIZER of the event. This message MUST not be used to reschedule an event. The EVENT- REPLACE or a sequence of the EVENT-CANCEL followed by the EVENT- REQUEST profile types MUST be used by the originator to change or reschedule this event. If an Alarm is specified in an EVENT-REQUEST, it is only specified as a suggestion. A recipient may ignore the Alarm component entirely. A recipient is not obligated to use any information defined in the Alarm component. However, the recipient should forward all alarm information in a delegated request. EVENT-REQUEST Calendar Properties GEO S PRODID A Dawson 24 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 VERSION A, Value must be "2.0". PROFILE A,"EVENT-REQUEST" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties COMMENT X CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S Event Component Properties ATTACH S, "VALUE=URL" only. ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. STATUS parameter is either absent or has value "NEEDS ACTION". CATEGORIES S CLASS S CREATED S COMPLETED X DESCRIPTION A, Value may be NULL text. Dawson 25 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 DUE X DURATION X DTEND A, Must be a date/time after DTSTART. May span date boundary. DTSTART A EXDATE S, See issues list. EXRULE S, See issues list. LAST-MODIFIED S LOCATION S PRIORITY X RELATED-TO S REQUEST-REPLY X RDATE S, See issues list. RRULE S, See issues list. RESOURCES S RESPONSE- X SEQUENCE SEQUENCE A, If not zero STATUS S, Value only one of TENTATIVE | ACCEPTED. This property is used by the originator to indicate the consensus for the meeting, not a status on any of the attendees. SUMMARY S, May be NULL text. TRANSP X URL S UID A, Must be maintained by the recipients. To-do Component Properties Dawson 26 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 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 S CATEGORIES A, If an alarm is specified CREATED S DESCRIPTION S DTSTART A, If an alarm is specified DURATION A, If an alarm is specified LAST-MODIFIED S RELATED-TO S REPEAT A, If an alarm is specified SUMMARY S URL S Freebusy Component Properties Freebusy component is excluded from this message type. Non-standard Properties X-token S, but recipient may choose to ignore those non-standard properties, specified as optional. 6.2 EVENT-REPLY The message is used to RSVP to an existing event request. The message is sent from a recipient of an event request back to the event ORGANIZER. If an ORGANIZER is not specified on the request, then the message is sent to the OWNER. The message is only used to change the Dawson 27 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 attendee's status from NEEDS ACTION, the default, to either ACCEPTED, DECLINED, TENTATIVE, or DELEGATED. The message may also be used by an attendee to later change their status back to some other value. Recipients may end up sending numerous EVENT-REPLY messages to change their attendance status from one value to another. Individual reply messages will have a RESPONSE-SEQUENCE property with a value that is incremented for each reply sequence. The first reply has a RESPONSE- SEQUENCE value of "0"; the second a value of "1", etc. This message type is not used to make a counter proposal to an event request. This would be accomplished by sending an EVENT-COUNTER message to the ORGANIZER of the original event. If an ORGANIZER is not specified on the request, then the message is sent to the OWNER. The UID of the original event request is used as the primary key for the event that is being replied to. An EVENT-REPLY to a recurring event can confirm, tentatively confirm or decline the whole event request or individual instances of a recurrence sequence. EVENT-REPLY Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-REPLY" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties ATTACH X ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. Must be the address of the recipient replying. CATEGORIES X Dawson 28 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 CLASS X COMMENT Text value. Provides a comment from the recipient to the originator about the reply. For example, "I can't travel this far for a meeting." CREATED X COMPLETED X DESCRIPTION X DUE X DURATION X DTEND X DTSTART X EXDATE S, See issues list. Specifies the dates that are exceptions to the status update. EXRULE S, See issues list. Specifies the rule that defines the exceptions to the status update. LAST-MODIFIED X LOCATION X PRIORITY X RELATED-TO X REQUEST- Any of the values defined in STATUS the table below. RDATE X RRULE X RESOURCES X RESPONSE- A, If not zero. SEQUENCE SEQUENCE A, If not zero Dawson 29 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 STATUS X Status for attendee must be specified in STATUS parameter of ATTENDEE property. SUMMARY X TRANSP X URL X UID A, 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 X-token S, But recipient may choose to ignore those non-standard properties, specified as optional. The REQUEST-STATUS property may include the following values: Short Return Longer Return Status Offending Data Status Description 0 Success. None. Dawson 30 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 10 Success, but fallback Property name and value taken on one or more may be specified. property values. 11 Success, invalid Property name may be property ignored. specified. 12 Success, invalid Property parameter name property parameter and value may be ignored. specified. 13 Success, unknown non- Non-standard property standard property name may be specified. ignored. 14 Success, unknown non- standard property value standard value may be Property and non- ignored. specified. 15 Success, invalid Calendar component calendar component sentinel (e.g., ignored. "BEGIN:ALARM") may be specified. 16 Success, request Original and forwarded forwarded to calendar RFC822 addresses may be user. specified. 17 Success, repeating event RRULE or RDATE property ignored. Scheduled as a name and value may be single event. specified. 18 Success, truncated end DTEND property value may date/time to date be specified. boundary. 100 Invalid property name. Property name may be specified. 101 Invalid property value. Property name and value may be specified. 102 Invalid property Property parameter name parameter. and value may be specified. 103 Invalid property Property parameter name parameter value. and value may be specified. 104 Invalid calendar Calendar component component sequence. sentinel may be Dawson 31 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 specified (e.g., BEGIN:TIMEZONE). 201 Invalid date or time. Date/time value(s) may be specified. 202 Invalid rule. Rule value may be specified. 203 Request not supported. Profile property value may be specified. 204 Invalid calendar user. Attendee property value may be specified. 301 Event conflict. DTSTART and DTEND Date/time is busy. property name and values may be specified. 302 Request not supported. PROFILE property value may be specified. 401 Service unavailable. ATTENDEE property value may be specified. 402 Invalid calendar ATTENDEE property value service. may be specified. 403 Invalid calendar user. ATTENDEE property value may be specified. 404 No scheduling support ATTENDEE property value for user. may be specified. 405 No authority. PROFILE and ATTENDEE property values may be specified. 6.3 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 original event request. The OWNER and ORGANIZER are ROLE parameter values for the ATTENDEE property. EVENT-CANCEL Dawson 32 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-CANCEL" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties ATTACH X ATTENDEE X CATEGORIES X CLASS X CREATED X COMMENT S, Text value. Provides a comment from the originator to the attendees concerning the cancellation notice. COMPLETED X DESCRIPTION X DUE X DURATION X DTEND X DTSTART X EXDATE X EXRULE X LAST-MODIFIED X Dawson 33 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 LOCATION X PRIORITY X RELATED-TO X REQUEST- X STATUS RDATE X RRULE X RESOURCES X RESPONSE- X SEQUENCE SEQUENCE A if not zero STATUS X SUMMARY X TRANSP X URL S UID A, 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 Alarm component is excluded from this message type. Freebusy Properties Freebusy component is excluded from this message type. Dawson 34 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Non-standard Properties X-token S, But recipient may choose to ignore those non-standard properties, specified as optional. 6.4 EVENT-REPLACE This message type is used reschedule an existing event or to provide attendees with an up-to-date description of the event. The message is sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of an event request to one or more intended recipients. The OWNER and ORGANIZER are ROLE parameter values for the ATTENDEE property. The originator MUST be either the OWNER or ORGANIZER of the event. EVENT-REPLACE Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-REPLACE" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. Dawson 35 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 TZNAME S TZOFFSET A TZTRANS S UID S Event Component Properties ATTACH S, URL only. ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. If used to reschedule an event, then the STATUS parameter must either be absent or has a value of "NEEDS ACTION". CATEGORIES S CLASS S COMMENT X CREATED S COMPLETED X DESCRIPTION A, Value may be NULL text. DUE X DURATION X DTEND A, 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. DTSTART A, 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. EXDATE S, See issues list. EXRULE S, See issues list. LAST-MODIFIED S Dawson 36 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 LOCATION S PRIORITY X RELATED-TO O REQUEST- X STATUS RDATE S, See issues list. RRULE S, See issues list. RESOURCES S RESPONSE- X SEQUENCE SEQUENCE A if not zero STATUS S, Value only one of TENTATIVE | ACCEPTED. This property is used by the originator to indicate the consensus for the meeting. SUMMARY S, May be NULL text. TRANSP X URL S UID A, 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 S CATEGORIES A, If an alarm is specified CREATED S Dawson 37 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 DESCRIPTION S DTSTART A, If an alarm is specified DURATION A, If an alarm is specified LAST-MODIFIED S RELATED-TO S REPEAT A, If an alarm is specified SUMMARY S URL S Freebusy Component Properties Freebusy component is excluded from this message type. Non-standard Properties X-token S, but recipient may choose to ignore those non-standard properties, specified as optional. 6.5 EVENT-COUNTER This message type is used by a recipient of an event request to issue a counter-proposal to the event. The message is sent from a recipient of an existing event request to the OWNER and/or ORGANIZER of the original event request. The OWNER and ORGANIZER are ROLE parameter values for the ATTENDEE property. Alternative counter proposals are not supported. That is, multiple VEVENT calendar components similar to that allowed in the EVENT-REPLY are not allowed in this message type. The EVENT-COUNTER message must include a complete description of the event. EVENT-COUNTER Calendar Properties Dawson 38 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-COUNTER" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S Event Component Properties ATTACH S, VALUE=URL only. ATTENDEE A, 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 S CLASS S COMMENT A, Text value. Provides a comment from the recipient to Dawson 39 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 the originator about the counter proposal. For example, "How about my place instead of yours". CREATED X COMPLETED X DESCRIPTION A, Value may be NULL text. DUE X DURATION X DTEND A, 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. DTSTART S, 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. EXDATE S, See issues list. EXRULE S, See issues list. LAST-MODIFIED X LOCATION S RNUM X PRIORITY X RELATED-TO S REQUEST- X STATUS RDATE S, See issues list. RRULE S, See issues list. RESOURCES S RESPONSE- A, If not zero SEQUENCE Dawson 40 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 SEQUENCE A, If not zero STATUS X SUMMARY S, May be NULL text. TRANSP X URL S UID A, 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. Freebusy Properties Freebusy component is excluded from this message type. Non-standard Properties X-token S, But recipient may choose to ignore those non-standard properties, specified as optional. 6.6 EVENT-DECLINECOUNTER This message type is used by the originator of an event request to decline a counter proposal. The message is sent from the OWNER and/or ORGANIZER of the original event request to the originator of the EVENT-COUNTER message. This originator of the counter proposal message should be one of the ATTENDEE in the original event request. Dawson 41 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Acceptance of a counter proposal message is accomplished by the OWNER and/or ORGANIZER of the original event request sending out an EVENT- REPLACE message with the updated event description. EVENT-DECLINECOUNTER Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-DECLINECOUNTER" PROFILE- A, Value must be "0.9". VERSION Timezone Properties Timezone component is excluded from this message type. Event Component Properties ATTACH X ATTENDEE S, 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 X CLASS X COMMENT S, 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 X COMPLETED X Dawson 42 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 DESCRIPTION X DUE X DURATION X DTEND X DTSTART X EXDATE X EXRULE X LAST-MODIFIED X LOCATION S PRIORITY X RELATED-TO S REQUEST- S, One of the values from the STATUS table below. RDATE X RRULE X RESOURCES X RESPONSE- A, Must be the same as that SEQUENCE specified in the EVENT- COUNTER. SEQUENCE A, Must be the same as that specified in the EVENT- COUNTER. STATUS X SUMMARY X TRANSP X URL S UID A, Must be the value of the UID of the original EVENT- REQUEST referenced in the counter proposal. Dawson 43 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 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 S, but recipient may choose to ignore those non-standard properties, specified as optional. The REQUEST-STATUS property may include the following values: Short Return Longer Return Status Offending Data Status Description 0 Success. None. 10 Success, but fallback Property name and value taken on one or more may be specified. property values. 11 Success, invalid Property name may be property ignored. specified. 12 Success, invalid Property parameter name property parameter and value may be ignored. specified. 13 Success, unknown non- Non-standard property standard property name may be specified. Dawson 44 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 ignored. 14 Success, unknown non- Property and non- standard property value standard value may be ignored. specified. 15 Success, invalid calendar component sentinel (e.g., Calendar component ignored. "BEGIN:ALARM") may be specified. 16 Success, request forwarded to calendar RFC822 addresses may be Original and forwarded user. specified. 17 Success, repeating event RRULE or RDATE property ignored. Scheduled as a name and value may be single event. specified. 18 Success, truncated end DTEND property value may date/time to date be specified. boundary. 100 Invalid property name. Property name may be specified. 101 Invalid property value. Property name and value may be specified. 102 Invalid property Property parameter name parameter. and value may be specified. 103 Invalid property Property parameter name parameter value. and value may be specified. 104 Invalid calendar Calendar component component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 201 Invalid date or time. Date/time value(s) may be specified. 202 Invalid rule. Rule value may be specified. 203 Request not supported. Profile property value may be specified. 204 Invalid calendar user. Attendee property value Dawson 45 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 may be specified. 301 Event conflict. DTSTART and DTEND Date/time is busy. property name and values may be specified. 302 Request not supported. PROFILE property value may be specified. 401 Service unavailable. ATTENDEE property value may be specified. 402 Invalid calendar ATTENDEE property value service. may be specified. 403 Invalid calendar user. ATTENDEE property value may be specified. 404 No scheduling support ATTENDEE property value for user. may be specified. 405 No authority. PROFILE and ATTENDEE property values may be specified. 6.7 EVENT-DELEGATE This message type is used to delegate an event request to an 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 recipient delegating the request to the originator of the event request; indicating that the original request is being delegated. The EVENT-DELEGATE 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. Dawson 46 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 EVENT-DELEGATE Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-DELEGATE" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S Event Component Properties ATTACH S, VALUE=URL only. ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. A 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 Dawson 47 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 same RSVP and EXPECT property parameter values as the recipient delegating the request. The STATUS parameter for this individual is either absent or has a value of "NEEDS ACTION". The ATTENDEE property associated with the recipient delegating the request should include the DELEGATED-TO property parameter. CATEGORIES S CLASS S CREATED S COMMENT S, Text value. Provides a comment from the originator of the delegate message to the delegated individual concerning the delegated event. COMPLETED X DESCRIPTION A, Value may be NULL text. DUE X DURATION X DTEND A, 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. DTSTART A, 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. EXDATE S, See issues list. EXRULE S, See issues list. LAST-MODIFIED S Dawson 48 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 LOCATION S PRIORITY X RELATED-TO S REQUEST- X STATUS RDATE S, See issues list. RRULE S, See issues list. RESOURCES S RESPONSE- X, This message not to be used SEQUENCE for "rescheduling" an event. SEQUENCE A if not zero STATUS S, Value only one of TENTATIVE | ACCEPTED. This property is used to convey the consensus for the meeting. SUMMARY S, May be Null text. TRANSP X URL S UID A, 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 S CATEGORIES A, If an alarm is specified CREATED S Dawson 49 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 DESCRIPTION S DTSTART A, If an alarm is specified DURATION A, If an alarm is specified LAST-MODIFIED S RELATED-TO S REPEAT A, If an alarm is specified SUMMARY S URL S Freebusy Component Properties Freebusy component is excluded from this message type. Non-standard Properties X-token S, but recipient may choose to ignore those non-standard properties, specified as optional. 6.8 TODO-REQUEST This message type is used to send an assignment of a to-do or action item to one or more recipients. The message is sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of a to-do request to one or more intended recipients (ROLE=ATTENDEE). The OWNER and OGANIZER are ROLE parameter values for the ATTENDEE property. A to-do may be defined as a recurring action item. This usage profile does not provide support the capability to redefine a to-do, other than by canceling and assigning a newly defined to-do. TODO-REQUEST Calendar Properties GEO S Dawson 50 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 PRODID A VERSION A, Value must be "2.0". PROFILE A,"TODO-REQUEST" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S Event Component Properties Event component is excluded from this message type. To-do Component Properties ATTACH S, VALUE=URL only. ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. STATUS parameter is either absent or has a value "NEED ACTION". CATEGORIES S CLASS S Dawson 51 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 COMMENT S CREATED S COMPLETED X DESCRIPTION A, Value may be NULL text. DUE A, Value is of the ISO 8601 complete representation, basic format of a UTC based date and time. This is the date and time that the to-do is to be completed; unless specifying a loosely coupled date and time. DURATION X DTEND X DTSTART A, Value is of the ISO 8601 complete representation, basic format of a UTC based date and time. This is the date that the to-do is to first appear on the calendar; unless specifying a loosely coupled date and time. EXDATE S, See issues list. EXRULE S, See issues list. LAST-MODIFIED S LOCATION X PRIORITY A, Value must be a numeric character representing an integer. "0" indicates not set. "1", "2", "3" indicate high, medium, and low priority, respectively. RELATED-TO S REQUEST- X STATUS RDATE S, See issues list. RRULE S, See issues list. Dawson 52 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 RESOURCES S RESPONSE- X, This message is not used SEQUENCE for "redefining" a to-do. SEQUENCE A if not zero STATUS X SUMMARY S, May be Null text. TRANSP X URL S UID A, Must be maintained by the recipient. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties ATTACH S CATEGORIES A, If an alarm is specified CREATED S DESCRIPTION S DTSTART A, If an alarm is specified DURATION A, If an alarm is specified LAST-MODIFIED S RELATED-TO S REPEAT A, If an alarm is specified SUMMARY S URL S Freebusy Component Properties Freebusy component is excluded from this message type. Dawson 53 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Non-standard Properties X-token S, but recipient may choose to ignore those non-standard properties, specified as optional. 6.9 TODO-REPLY This message type is used to reply to a to-do assignment in order to update the status and possibly the completion date of the to-do. The message is sent from a recipient of a to-do request back to the to-do ORGANIZER. If an ORGANIZER is not specified on the request, then the message is sent to the OWNER. This profile is ONLY USED to reply to an to-do request; in order to ACCEPT or DECLINE a to-do. It is also be used by the recipient of a TODO-REQUEST in order to confirm completion of the to-do (i.e., ATTENDEE;STATUS=COMPLETED:.., COMPLETED=date and time of completion). TODO-REPLY Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"TODO-REPLY" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties Event component is excluded from this message type. To-do Component Properties Dawson 54 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 ATTACH X ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. STATUS parameter MUST be either ACCEPT or DECLINE or COMPLETED. CATEGORIES X CLASS X COMMENT S, Text value. Provides a comment from the originator of the reply to the attendees concerning the to-do reply notice. CREATED X COMPLETED A, if a TODO-REPLY to indicate completion of a task. Value is of the ISO 8601 complete representation, basic format of a UTC based date and time. This is the time the task was completed. DESCRIPTION X DUE X DURATION X DTEND X DTSTART X EXDATE X EXRULE X LAST-MODIFIED X LOCATION X PRIORITY X RELATED-TO X REQUEST- A, One of the value from the STATUS table below. Dawson 55 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 RDATE X RRULE X RESOURCES X RESPONSE- A if not zero SEQUENCE SEQUENCE A if not zero STATUS S, Value may only be NEEDS ACTION or COMPLETED. This property is used to confirm to the originator the status of the to-do. SUMMARY X TRANSP X URL S UID A, Must be the UID of the TODO-REQUEST associated with the reply. Journal Component Properties Journal component is excluded from this message type. Alarm Component Properties Alarm component is excluded from this message type. Freebusy Component Properties Freebusy component is excluded from this messge type Non-standard Properties X-token S, Recipient may choose to ignore those non-standard properties, specified as optional. The REQUEST-STATUS property may include the following values: Dawson 56 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Short Return Longer Return Status Offending Data Status Description 0 Success. None. 10 Success, but fallback taken on one or more may be specified. Property name and value property values. 11 Success, invalid Property name may be property ignored. specified. 12 Success, invalid Property parameter name property parameter and value may be ignored. specified. 13 Success, unknown non- Non-standard property standard property name may be specified. ignored. 14 Success, unknown non- standard property value standard value may be Property and non- ignored. specified. 15 Success, invalid Calendar component calendar component sentinel (e.g., ignored. "BEGIN:ALARM") may be specified. 16 Success, request Original and forwarded forwarded to calendar RFC822 addresses may be user. specified. 18 Success, truncated end DTEND property value may date/time to date be specified. boundary. 19 Success, repeating to-do RRULE or RDATE property ignored. Scheduled as a name and value may be single to-do. specified. 100 Invalid property name. Property name may be specified. 101 Invalid property value. Property name and value may be specified. 102 Invalid property Property parameter name parameter. and value may be specified. Dawson 57 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 103 Invalid property Property parameter name parameter value. and value may be specified. 104 Invalid calendar Calendar component component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 201 Invalid date or time. Date/time value(s) may be specified. 202 Invalid rule. Rule value may be specified. 203 Request not supported. Profile property value may be specified. 204 Invalid calendar user. Attendee property value may be specified. 302 Request not supported. PROFILE property value may be specified. 401 Service unavailable. ATTENDEE property value may be specified. 402 Invalid calendar ATTENDEE property value service. may be specified. 403 Invalid calendar user. ATTENDEE property value may be specified. 404 No scheduling support ATTENDEE property value for user. may be specified. 405 No authority. PROFILE and ATTENDEE property values may be specified. 6.10 TODO-CANCEL This message type is used to send a cancellation notice for an existing to-do request to the attendees. The message is sent by the to-do OWNER or ORGANIZER to the recipients of the original event request. The OWNER and ORGANIZER are ROLE parameter values for the ATTENDEE property. Dawson 58 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 TODO-CANCEL Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"EVENT-CANCEL" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties Timezone component is excluded from this message type. Event Component Properties Event component is excluded from this message type. To-do Component Properties ATTACH X ATTENDEE X CATEGORIES X CLASS X COMMENT S, Text value. Provides a comment from the originator of the reply to the attendees concerning the to-do reply notice. CREATED X COMPLETED X DESCRIPTION X DUE X DURATION X DTEND X Dawson 59 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 DTSTART X EXDATE X EXRULE X LAST-MODIFIED X LOCATION X PRIORITY X RELATED-TO X REQUEST- X STATUS RDATE X RRULE X RESOURCES X RESPONSE- X SEQUENCE SEQUENCE X STATUS X SUMMARY X TRANSP X URL S UID A, Must be the UID of the TODO-REQUEST associated with the cancelation notice. Journal Component Properties Journal component is excluded from this message type. Alarm Properties Alarm component is excluded from this message type. Freebusy Properties Dawson 60 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Freebusy component is excluded from this message type. Non-standard Properties X-token S, But recipient may choose to ignore those non-standard properties, specified as optional. 6.11 JOURNAL-REQUEST This message type is used to send a request to append a journal entry to one or more recipients. The message is sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of a journal request to one or more intended recipients (ROLE=ATTENDEE). The OWNER and OGANIZER are ROLE parameter values for the ATTENDEE property. A journal may note be defined as recurring. This usage profile does not provide support the capability to cancel or redefine a journal entry. JOURNAL-REQUEST Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"TODO-REQUEST" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S Dawson 61 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S 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 ATTACH S ATTENDEE A CATEGORIES S CLASS S CREATED S DESCRIPTION A DTSTART A LAST-MODIFIED S RELATED-TO S RESPONSE S RESPONSE- S SEQUENCE UID A URL S Dawson 62 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Alarm Component Properties Alarm component is excluded from this message type. Freebusy Component Properties Freebusy component is excluded from this message type. Non-standard Properties X-token S, but recipient may choose to ignore those non-standard properties, specified as optional. 6.12 JOURNAL-REPLY This message type is used to reply to a journal request in order to update the recipient's acceptance of the request. The message is sent from a recipient of a journal request back to the to-do ORGANIZER. If an ORGANIZER is not specified on the request, then the message is sent to the OWNER. This profile is ONLY USED to reply to journal request; in order to ACCEPT or DECLINE it. JOURNAL-REPLY Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"TODO-REPLY" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties Timezone component is excluded from this message type. Dawson 63 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 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 ATTACH X ATTENDEE A CATEGORIES X CLASS S DESCRIPTION A DTSTART X LAST-MODIFIED X RELATED-TO X RESPONSE S RESPONSE- S SEQUENCE UID A URL X Alarm Component Properties Alarm component is excluded from this message type. Freebusy Component Properties Freebusy component is excluded from this messge type Non-standard Properties X-token S, Recipient may choose to ignore those non-standard properties, specified as Dawson 64 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 optional. The REQUEST-STATUS property may include the following values: Short Return Longer Return Status Offending Data Status Description 0 Success. None. 10 Success, but fallback Property name and value taken on one or more may be specified. property values. 11 Success, invalid Property name may be property ignored. specified. 12 Success, invalid Property parameter name property parameter and value may be ignored. specified. 13 Success, unknown non- Non-standard property standard property name may be specified. ignored. 14 Success, unknown non- Property and non- standard property value standard value may be ignored. specified. 15 Success, invalid Calendar component calendar component sentinel (e.g., ignored. "BEGIN:ALARM") may be specified. 16 Success, request Original and forwarded forwarded to calendar RFC822 addresses may be user. specified. 100 Invalid property name. Property name may be specified. 101 Invalid property value. Property name and value may be specified. 102 Invalid property Property parameter name parameter. and value may be specified. Dawson 65 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 103 Invalid property Property parameter name parameter value. and value may be specified. 104 Invalid calendar Calendar component component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 201 Invalid date or time. Date/time value(s) may be specified. 202 Invalid rule. Rule value may be specified. 203 Request not supported. Profile property value may be specified. 204 Invalid calendar user. Attendee property value may be specified. 302 Request not supported. PROFILE property value may be specified. 401 Service unavailable. ATTENDEE property value may be specified. 402 Invalid calendar ATTENDEE property value service. may be specified. 403 Invalid calendar user. ATTENDEE property value may be specified. 404 No scheduling support ATTENDEE property value for user. may be specified. 405 No authority. PROFILE and ATTENDEE property values may be specified. 6.13 BUSY-REQUEST This message type is used to request a busy time from one or more people. This message only permits requests for busy time information. The message is sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of an free/busy time request to one or more intended recipients (i.e., ROLE=ATTENDEE). Dawson 66 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 BUSY-REQUEST Calendar Properties GEO S PRODID A VERSION A, Value must be "2.0". PROFILE A,"BUSY-REQUEST" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S 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 Dawson 67 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 from this message type. Alarm Component Properties Alarm component is excluded from this message type. FreeBusy Component Properties ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. An instance must be specified for the originator and the intended recipients of the request. COMMENT X CREATED X DURATION X DTEND A, This is the end of the busy time period being requested. DTSTART A, This is the start of the busy time period being requested. FREEBUSY X LAST-MODIFIED X RELATED-TO X REQUEST- X STATUS RESPONSE- X, The value will always be SEQUENCE zero. SEQUENCE X, the value will always be zero UID A, Must be referenced by the recipients in their FREEBUSY- REPLY message. URL X Non-standard Properties Dawson 68 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 X-token S, but recipient may choose to ignore those non-standard properties, specified as optional. 6.14 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 before yesterday's busy time information. And the busy time for this half hour SHOULD appear before 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 S PRODID A Dawson 69 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 VERSION A, Value must be "2.0". PROFILE A,"BUSY-REPLY" PROFILE- A, Value must be "0.9". VERSION Timezone Component Properties CREATED S DAYLIGHT S DTSTART A DTEND S RDATE S, Either RDATE or RRULE may be specified, but not both. RRULE S, Either RDATE or RRULE may be specified, but not both. TZNAME S TZOFFSET A TZTRANS S UID S 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 Dawson 70 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 ATTENDEE A, Value is an RFC822 mailbox address for C&S capability. Must be the address of the recipient replying. COMMENT S, Text value. Provides a comment from the originator of the reply to the recipient concerning the busytime reply notice. CREATED S DURATION X DTEND S, Value is the ISO 8601 complete representation, basic format of a UTC based date and time. Represents the end of the busy time period defined by the BUSYTIME properties in the Freebusy component. DTSTART S, Value is the ISO 8601 complete representation, basic format of a UTC based date and time. Represents the start of the busy time period defined by the BUSYTIME properties in the Freebusy component. FREEBUSY A, 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 S RELATED-TO S, Refers to a related Freebusy component. REQUEST- A, One of the values from the STATUS table below. Multiple instances of the property may be specified. RESPONSE- X, Will always be zero. Dawson 71 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 SEQUENCE SEQUENCE X, Will always be zero UID A, Must be the UID of the BUSY-REQUEST associated with the reply. URL S, Specifies the URL for HTTP access to a "VCS" file containing iCalendar Object with busy time information. Non-standard Properties X-token S, Recipient may choose to ignore those non-standard properties, specified as optional. The REQUEST-STATUS property may include the following values: Short Return Longer Return Status Offending Data Status Description 0 Success. None. 10 Success, but fallback Property name and value taken on one or more may be specified. property values. 11 Success, invalid Property name may be property ignored. specified. 12 Success, invalid Property parameter name property parameter and value may be ignored. specified. 13 Success, unknown non- Non-standard property standard property name may be specified. ignored. 14 Success, unknown non- Property and non- standard property value standard value may be ignored. specified. 15 Success, invalid Calendar component Dawson 72 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 calendar component sentinel (e.g., ignored. "BEGIN:ALARM") may be specified. 16 Success, request Original and forwarded forwarded to calendar RFC822 addresses may be user. specified. 18 Success, truncated end date/time to date be specified. DTEND property value may boundary. 100 Invalid property name. Property name may be specified. 101 Invalid property value. Property name and value may be specified. 102 Invalid property Property parameter name parameter. and value may be specified. 103 Invalid property Property parameter name parameter value. and value may be specified. 104 Invalid calendar Calendar component component sequence. sentinel may be specified (e.g., BEGIN:TIMEZONE). 201 Invalid date or time. Date/time value(s) may be specified. 203 Invalid request. Profile property value may be specified. 204 Invalid calendar user. Attendee property value may be specified. 302 Request not supported. PROFILE property value may be specified. 401 Service unavailable. ATTENDEE property value may be specified. 402 Invalid calendar ATTENDEE property value service. may be specified. 403 Invalid calendar user. ATTENDEE property value may be specified. Dawson 73 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 404 No scheduling support ATTENDEE property value for user. may be specified. 405 No authority. PROFILE and ATTENDEE property values may be specified. 7. MIME Message Format Binding The iMIP is applicable to many transports; including vendor-specific electronic messaging formats, standards based electronic messaging formats such as the IETF SMTP/MIME, file system, common memory exchange such as a clipboard, drag/drop protocols, Infra-red Data Association (IrDA) object exchange, wireless pagers, etc. This section defines the message binding to the MIME electronic mail transport. 7.1 MIME Media Type A MIME entity containing content information formatted according to this design document will be referenced as a "text/calendar" content type. It is assumed that this content type will be transported through a MIME electronic mail transport. 7.2 Security When transported over SMIME, these messages should utilize the SMIME signature to prevent spoofing. 7.3 RFC 822 Addresses The calendar address specified within the ATTENDEE property in a iCalendar object MUST be a fully qualified, RFC 822 address for the corresponding OWNER, ORGANIZER or ATTENDEE of the event or to-do. The address MUST be the RFC 822 address for the calendaring and scheduling mail box for the attendee. This may or may not be the same mail box that the individual uses for interpersonal messaging (i.e., email). The proper RFC 822 address will need to be identified and put into the ATTENDEE property by the calendaring and scheduling service. This information can not be assumed to be set by the electronic messaging MTA. A UA using MIME messages conforming to this design document may have different RFC 822 addresses for their electronic mail post office and the mail box used for calendaring and scheduling. In such cases, the addresses in the MIME header fields (e.g., To, From, Cc, Bc, Reply- to, etc.) may be different than the RFC 822 addresses specified in the ATTENDEE properties within the iCalendar object. Dawson 74 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 7.4 Content Type A MIME body part containing content information that conforms with this design document MUST have a Content-Type value of "text/calendar". The content type header field MUST also include the type parameter "profile". The parameter value MUST be one of the message types defined by this profile. The value MUST also be the same as the value of the PROFILE calendar property within the iCalendar object. This means that if a MIME message contains multiple iCalendar objects, then they must be further encapsulated with a "multipart/mixed" MIME entity. This will allow each of the iCalendar objects to be encapsulated within their own "text/calendar" MIME entity. If the iMIP based message is not an immediate child of the root MIME message entity, then it should be assumed to be a part of a forwarded message. It may be ignored. The Content-Type CHARSET parameter MUST also appear in any MIME entity encapsulating a iCalendar object conforming to this design document. The CHARSET parameter value MUST be "UTF-8" in order to override the default of "US-ASCII". The following is an example of this header field with a value that indicates an event request message. CONTENT-TYPE:text/calendar; profile=event-request; charset=UTF-8 The "text/calendar" may be included as a MIME entity within either a "multipart/mixed" or "multipart/alternative" multi-part MIME message. This will allow the scheduling message type to be included in a MIME message with other content information (i.e., multipart/mixed) or included in a MIME message with a clear-text, human-readable form of the scheduling message (i.e., multipart/alternative). In order to permit the information in the scheduling message to be understood by MIME user agents (UA) that do not support the text/calendar content type, scheduling messages should be sent with an alternative, human-readable form of the information. [Editor's Note: An example is needed here.] 7.5 Content-Transfer-Encoding The new Content-Transfer-Encoding header field was added in [RFC2045]. This header field specifies the encoding used to transform the content information into the MIME canonical content format. All MIME entities formatted according to this design document must be "8bit". This is to allow transfer of UTF-8 character set encoded iCalendar objects. The [RFC2045] default is "7bit". Hence, each MIME entity encapsulating a iCalendar object must include this header Dawson 75 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 field. The following is an example of how this header field must appear. CONTENT-TRANSFER-ENCODING:8bit 7.6 Content-Description The Content-Description header field is used to provide a human- readable explanation to the MIME entity. This is a useful field to record the fact that the content information is a iCalendar object. A MIME entities formatted according to this design document that includes this header field SHOULD have it's value prefixed with the text "X-iCAL:". 7.7 To Any of the attendees addressed by the iCalendar object, that are also addressable with Internet SMTP addresses, should have their RFC 822 addresses included in the TO header field. An attendee that is included in the iCalendar object but not in the TO header field is still a valid attendee to the event or to-do. 7.8 From The originator of the iCalendar object should have their address in the value of the To header field. This may not be possible for iCalendar objects reflected from a mailing list. 7.9 Cc and Bc Event or to-do attendees may be specified in the CC header field. This does not imply any special or limited role for the attendee. 7.10 Reply-To The RFC 822 address of the originator of the iMIP MIME message should be specified as the value of the REPLY-TO header field. This will allow an electronic mail reply to the originator from the recipients of the iCalendar object. 7.11 Subject The SUBJECT header field SHOULD be prefixed with the text "X-iCAL:" in order to allow the message to be detected as a iMIP by legacy systems. A MIME UA written to conform to this design document will use the Content-Type value and Profile parameter value as a primary means of detection. 8. Alternate Plain-text Messages Some intended attendees for events or to-dos may be using a traditional, plain-text email user agent. They may not being using a calendaring and scheduling application that supports the iCalendar Dawson 76 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Object. In such cases, a plain-text rendering of the iCalendar Object message would allow minimal support for some of the scheduling features defined by this document. The following formats are intended to be used to for this purpose. These alternative messages may be sent in a "multipart/alternative" MIME media type. 8.1 EVENT-REQUEST, RSVP=YES The following is an alternative, plain-text message for an EVENT- REQUEST message, where a reply is requested. The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. is inviting you to a meeting as described below the line. Please put an "XXX" on the appropriate line below (and fill in any other necessary information) and then reply with this message to . _____ ACCEPT: I will attend this meeting. _____ DECLINE: I will not attend this meeting. _____ TENTATIVE: I do not now know whether I will attend this meeting. _____ DELEGATE: I will not attend this meeting -- I am inviting the following delegate and sending this message to him/her: _______________________ _____ PROPOSE ANOTHER TIME: I would like to attend this meeting but propose moving it to the following date and time: Date: ___________ Time: ___________ Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Start Date/Time: End Date/Time: Recurring Date(s): <"None" or substitute recurring dates/times> Location: Description: Invitees: 8.2 EVENT-REQUEST, RSVP=NO The following is an alternative, plain-text message for an EVENT- REQUEST message, where a reply is NOT requested. The SUBJECT property Dawson 77 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 value SHOULD be the same as the event summary or the first 255 character of the event description. is inviting you to a meeting as described below the line. There is no need to reply to this message, but please come to the meeting if you can. Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Start Date/Time: End Date/Time: Recurring Date(s): <"None" or substitute recurring dates/times> Location: Description: Invitees: 8.3 EVENT-REQUEST, EXPECT=REQUIRED The following is an alternative, plain-text message for an EVENT- REQUEST message, where the attendee's attendance is required. This alternative message can also be used when the attendee's reply is requested (i.e., RSVP=YES). The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. is inviting you to a meeting as described below the line. Your attendance is required in order for this meeting to take place. Please put an "XXX" on the appropriate line below (and fill in any other necessary information) and then reply with this message to . _____ ACCEPT: I will attend this meeting. _____ DECLINE: I will not attend this meeting. _____ TENTATIVE: I do not now know whether I will attend this meeting. _____ DELEGATE: I will not attend this meeting -- I am inviting the following delegate and sending this message to him/her: _______________________ _____ PROPOSE ANOTHER TIME: I would like to attend this meeting but propose moving it to the following date and time: Date: ___________ Time: ___________ Dawson 78 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Start Date/Time: End Date/Time: Recurring Date(s): <"None" or substitute recurring dates/times> Location: Description: Invitees: 8.4 EVENT-CANCEL The following is an alternative, plain-text message for an EVENT- CANCEL message. The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. is canceling the meeting described below the line. Please remove it from your personal calendar. There is no need to reply to this message. Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Start Date/Time: End Date/Time: Location: Description: Invitees: 8.5 EVENT-REPLACE, RSVP=YES The following is an alternative, plain-text message for an EVENT- REPLACE message, where a reply is requested. The SUBJECT property Dawson 79 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 value SHOULD be the same as the event summary or the first 255 character of the event description. has changed the characteristics of this meeting. The meeting details are described below this line. Please put an "XXX" on the appropriate line below (and fill in any other necessary information) and then reply with this message to . _____ ACCEPT: I will attend this meeting. _____ DECLINE: I will not attend this meeting. _____ TENTATIVE: I do not now know whether I will attend this meeting. _____ DELEGATE: I will not attend this meeting -- I am inviting the following delegate and sending this message to him/her: _______________________ _____ PROPOSE ANOTHER TIME: I would like to attend this meeting but propose moving it to the following date and time: Date: ___________ Time: ___________ Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Original Start Date/Time: Original End Date/Time: Original Recurring Date(s): <"None" or substitute recurring dates/times> NEW Start Date/Time: NEW End Date/Time: NEW Recurring Date(s): <"None" or substitute recurring dates/times> NEW Location: NEW Description: Invitees: 8.6 EVENT-DECLINECOUNTER The following is an alternative, plain-text message for an EVENT- DECLINECOUNTER. The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. has declined your proposed change to the date and/or time for this meeting. Your proposed changes are detailed below the line. Dawson 80 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Start Date and Time: End Date and Time: Location: Description: Invitees: 8.7 EVENT-DELEGATE, RSVP=YES The following is an alternative, plain-text message for an EVENT- DELEGATE message, where a reply is requested. The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. has requested that you be their delegate at a meeting as described below the line. Please put an "XXX" on the appropriate line below (and fill in any other necessary information) and then reply with this message to and . _____ ACCEPT: I will attend this meeting. _____ DECLINE: I will not attend this meeting. _____ TENTATIVE: I do not now know whether I will attend this meeting. _____ DELEGATE: I will not attend this meeting -- I am inviting the following delegate and sending this message to him/her: _______________________ _____ PROPOSE ANOTHER TIME: I would like to attend this meeting but propose moving it to the following date and time: Date: ___________ Time: ___________ Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: Meeting Summary: Start Date/Time: End Date/Time: Dawson 81 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Location: Description: Invitees: 8.8 TODO-REQUEST, RSVP=YES The following is an alternative, plain-text message for an TODO- REQUEST message, where a reply is requested. The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. is requesting you to do the task(s) as described below the line. Please put an "XXX" on the appropriate line below (and fill in any other necessary information) and then reply with this message to . _____ ACCEPT: I will do this task. _____ DECLINE: I will not do this task. _____ DELEGATE: I will not do this task -- I am delegating the task and sending this message to him/her: _______________________ Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: To-do Summary: Start Date/Time: Due Date/Time: Recurring Due Date(s): <"None" or substitute recurring dates/times> Priority: Description: Invitees: 8.9 TODO-REQUEST, RSVP=NO The following is an alternative, plain-text message for an TODO- REQUEST message, where a reply is NOT requested. The SUBJECT property value SHOULD be the same as the event summary or the first 255 character of the event description. Dawson 82 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 is requesting you to do the task(s) as described below the line. Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Event ID: To-do Summary: Start Date/Time: Due Date/Time: Recurring Due Date(s): <"None" or substitute recurring dates/times> Priority: Description: Invitees: 8.10 TODO-CANCEL The following is an alternative, plain-text message for an TODO- CANCEL message. The SUBJECT property value SHOULD be the same as the todo summary or the first 255 character of the to-do description. is canceling the to-do described below the line. Please remove it from your personal calendar. There is no need to reply to this message. Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ To-do ID: To-do Summary: Start Date/Time: End Date/Time: Location: Description: Invitees: Dawson 83 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 8.11 JOURNAL-REQUEST, RSVP=YES The following is an alternative, plain-text message for an JOURNAL- REQUEST message, where a reply is requested. The SUBJECT property value SHOULD be the first 255 character of the event description. is requesting you add the journal entry as described below the line. Please put an "XXX" on the appropriate line below (and fill in any other necessary information) and then reply with this message to . _____ ACCEPT: I will do this journal entry. _____ DECLINE: I will not do this journal entry. _____ DELEGATE: I will not do this journal entry -- I am delegating the journal entry and sending this message to him/her: _______________________ Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Journal ID: Journal Summary: Start Date/Time: Description: 8.12 JOURNAL-REQUEST, RSVP=NO The following is an alternative, plain-text message for an JOURNAL- REQUEST message, where a reply is NOT requested. The SUBJECT property value SHOULD be the first 255 character of the event description. is requesting you add the journal entry as described below the line. Attached Files: DO NOT MODIFY ANYTHING BELOW THIS LINE _____________________________________________________________________ Journal ID: Journal Summary: Start Date/Time: Dawson 84 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 Description: 9. IrDA Binding TBD. Initial text to be provided by Frank Dawson 10. TCP LAN Protocol Binding TBD. Initial text to be provided by John Rose 11. SPX LAN Protocol Binding TBD. Initial text to be provided by John Rose 12. Desktop Interaction Requirements This section defines the minimal UI function client products MUST support in order to conform to this design document. 12.1 Clipboard Applications conforming to this design document MUST provide the Edit-Copy or Edit-CopySpecial menu option and a smarticon to permit the end-user to copy a selected event or to-do to the operating system clipboard as a iCalendar object. The iCalendar object MUST be copied to the clipboard both as a iCalendar identifiable clipboard object and as a formatted-text clipboard object. This will allow copying of the iCalendar object to simple applications that just support formatted text clipboard objects. Applications conforming to this design document also MUST provide Edit-Paste or Edit-PasteSpecial menu option and a smarticon to permit the end-user to paste a clipboard based iCalendar object into the application. If the application does not find a iCalendar tagged object on the clipboard, it MUST try to find the iCalendar object in a simple formatted-text object on the clipboard. This will allow the application to interoperate with simple applications that support formatted-text clipboard representation of iCalendar objects but not yet support iCalendar tagged clipboard objects. 12.2 Drag/Drop Applications conforming to this design document that runs in an environment with drag/drop MUST provide drag/source protocol support for the rendering an event or to-do as a iCalendar. Dawson 85 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 In addition, an application conforming to this design document that runs in an environment with drag/drop MUST provide drop/target protocol support for the import of a iCalendar object. If the operating system environment supports both a clipboard and file system based drag/drop protocol, then both of these modes MUST be supported for both drag/source and drag/target. 12.3 File System Applications conforming to this design document MUST provide the File-SaveAs menu option and a smarticon to permit the end-user to export a selected event or to-do into the file system as a iCalendar object. The default file type MUST be "VCS". File systems that do not reply on file extensions may need alternative default extensions. Applications also MUST provide the File-Open menu option and a smarticon to permit the end-user to import a selected iCalendar object into the application. 12.4 IrDa Communications Applications conforming to this design document SHOULD provide both the File-Send menu option and a iCalendar send smarticon to permit the end-user to "beam" a selected event or to-do over an operational IrDA communications port. The iCalendar "send" icon is available in a number of sizes and color densities from the http://www.imc.org/pdi web site. 13. Conformance Applications conforming to this design document must meet the following minimum requirements: . Conform to the minimum requirements defined by the [ICAL] specification; . Also comply with the Mandatory requirements defined by this design document; . and optionally comply with any Optional requirements defined by this design document. 14. References [ID-CSP] "MIME Calendaring and Scheduling Content Type Profile", Internet-Draft, November 26, 1996, ftp://ftp.ietf.org/internet- drafts/draft-ietf-calsch-csp-00.txt or http://www.imc.org/draft-ietf- calsch-csp. [ID-DT] "Date and Time on the Internet", Internet-Draft, December 1996, http://www.imc.org/draft-newman-datetime. Dawson 86 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 [ICAL] "Internet Calendaring and Scheduling Core Object Specification - iCalendar", Internet-Draft, February 3, 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-00.txt. [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- yergeau-utf8-01.txt. [ISO8601] "Data elements and interchange formats - information interchange - Representation of dates and times", ISO 8601, 1996-06- 15, +1 (212) 642-4900 for ANSI Sales. [VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format - Version 1.0", Versit Consortium, September 18, 1996, http://www.imc.org/pdi/vcal-10.doc. [VCARD] "vCard - The Electronic Business Card Exchange Format - Version 2.1", Versit Consortium, September 18, 1996, http://www.imc.org/pdi/vcard-21.doc. [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. 15. Acknowledgements The following individuals have made significant contributions to this document: John Banks-Binici, Polly Brown, Doug Conmy, Susan Esher, Arvind Goyal, Ryan Jansen, Bruce Kahn, Leo Parker, John Rose, Vinod Seraphin, Gail Strait. 16. Author's Address The following address information is provided in a vCard v2.1, Electronic Business Card, format. BEGIN:VCARD ORG:Lotus Development Corporation FN:Frank Dawson Dawson 87 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive; Raleigh;NC;27613-3502;USA TEL;WORK;PREF;MSG:+1-919-676-9515 TEL;WORK;MSG:+1-617-693-8728 TEL;WORK;FAX:+1-919-676-9564 EMAIL;INTERNET;PREF:Frank_Dawson@lotus.com EMAIL;INTERNET:fdawson@earthlink.net URL;HOME:http://home.earthlink.net/~fdawson END:VCARD 17. Issues The following discussion relates to open design issues remained open when this version of the design document was completed. 1. Need to resolve how to specify correct ATTENDEE values within a given product. A message may be transferred through a transport gateway. The address formats and content may be changed prior to recipient. In such cases, how is the recipient going to be able to reply to the originator? How is the originator going to be able to insert the ATTENDEE values into the message such that they are useful to the recipient? 2. Request to UI for a human readable, "pretty" message counterpart to each of the messages. This needs to include a section with a text "response form" (e.g., check this box to provide a confirm reply). 3. Binding to MIME multipart/alternative, multipart/related, and what to do for single body part. 4. Do we allow a recipient to offer a counter proposal (i.e., EVENT- COUNTER) to an EVENT-REQUEST that describes a recurring event? 5. Need a LAN binding for both TCP, AppleTalk, and SPX protocols (to be provided by John Rose/cc:Mail and John Cabot/Iris). 6. Do we need a ROOM value for ATTENDEE;TYPE parameter. 7. Should we be using a common vCard/iCalendar parser code base. 18. Resolutions 1. Implementation MUST be able to receive any message defined by this design document. Implementations MAY provide behaviors for a subset of the range of capabilities defined by this document (e.g., Might not put alarms in EVENT-REQUEST or Might ignore alarm properties in received EVENT-REQUEST messages). Implementations MUST not reject a message because of minimal support for the event or to-do description. 2. ATTENDEE property values MUST be a fully qualified, RFC 822 address. Dawson 88 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 3. Group scheduled to-dos MUST be supported. Both the TODO-REQUEST and TODO-REPLY message types MUST be supported. 4. Implementations that do not support SUMMARY property MUST append the value to the DESCRIPTION property value. 5. Implementations MUST store values for optional properties that they don't support. However, they may not act on these values. Optional, non-standard properties may be ignored by implementations that do not support the function. 6. Implementations SHOULD include a text prefix of "X-iCAL:" in the Subject and Content-Description MIME header fields in order to allow legacy SMTP recipient to better handle text/calendar MIME message types. 7. There are minimum length requirements for some properties by recipients of messages. For instance, a minimum of 4094 bytes MUST be supported by recipient for text values for the DESCRIPTION and COMMENT properties. A minimum of 254 bytes MUST be supported by recipients for text values for the SUMMARY property. Additional requirements for other properties may be identified later. Recipients MAY truncate longer property values. 8. The C&S message is formatted as two alternative representations, if the message transport supports multiple part body parts. The initial body part is a pretty text equivalent of the C&S information. The second body part in the message is the interoperable message format defined by this design document. 9. Any attachments to the event or to-do request are passed as secondary attachments. Their content identifiers are specified as the value for the associated ATTACH property. This assumes a multiple body part capability in the message transport. If this is not the case, then the attachments are send as independent messages. They message identifiers are specified as the value for the associated ATTACH property. 10. For Internet mapping of messages, the ATTENDEE value needs to be the Internet RFC822 address for the mail box that receives C&S messages. For most people, this is the same as email address. This value DOES NOT include any comment texts, as specified in RFC 822. 11. Person schema needs to provide flexibility for specifying a different email address for C&S. It should also specify a URL for busy time lookup. 12. Allow event description (i.e., DTSTART, DTEND) to span day- boundary. The fallback for recipients that do not support this is to truncate the event description to the day-boundary (i.e., "T240000" is the DTEND time component of the date/time value). The remainder of the event duration is lost. Dawson 89 Expired November 1997 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) May 1, 1997 13. The EVENT-REQUEST may include additional BEGIN/END:ALTERNATE calendar components that are the 1st, 2nd, 3rd, etc alternative times. The alternative ALTERNATE descriptions MUST reference the primary VEVENT with the REPLY-TO property containing the UID of the primary VEVENT. ATTENDESS reply with a REPLY message to only one event description. 14. Local time will be interpreted by a recipient as being relative to their timezone. Date and time values in the DTSTART, DTEND, DUE, COMPLETED properties SHOULD be represented as a UTC date/time value unless they intent is that they be "floating" values. 15. All iCalendar objects MUST use UTF-8 as the default character set. Dawson 90 Expired November 1997